In my last post I commenced my journey to integrate our old deployment process with the new shiny VSTS Release Management system. The whole story was about leveraging processes that were already working for us and the flow looked something like this:
The previous step in the process involved getting TeamCity to grab the build output from VSTS and deploy it using our old deployment PowerShell. With this working, my next goal was to be able to trigger the whole process from Release Management so I could either pick the build I wanted to deploy or trigger it from a successful build in VSTS.
I thought, this is going to be mad easy.
Alas, it turned out to be a little more difficult…
My team recently migrated to Visual Studio Team Services and as a result we have a goal to consolidate our deployment processes using the powerful Release Management framework. While this is the goal, for the moment I was interested in somehow getting our current build process in Team City to work along side our shiny new ALM provider.
Visual Studio Team Services and TeamCity. You would think they would go together like chocolate and lobster but with some work I was able to achieve a little unity…
My current role has me involved in several projects utilising the Microsoft Dyanamics AX framework. As part of my work I wanted to use Team Foundation Server to automate a build procedure that wasn’t specifically .NET and would require a custom build template to pull it off. I originally wrote our build templates for other projects using Team Foundation Server 2005. We had never bothered to upgrade them to the Windows Workflow style build templates but had rather utilised upgrade templates to get them to work. I had done a small amount of work with the new style of build templates but I needed to know more so I started doing some serious research on what had changed.