It’s been a while between posts but the latest focal point for my attention has been HockeyApp. In this multi-part series I will detail my exposure to the framework and identify the solutions to any challenges I faced along the way. As HockeyApp currently doesn’t quite have the coverage across all application types (Android, IOS, Win81, WinRT, UWP, etc) there are some unique obstacles that need to be overcome depending on your application architecture.
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…