I have had the incredible opportunity to work with Microsoft employees and contractors over the last 8 weeks on an evaluation of Release Management (RA) vNext and attend the 2015 Connect() conference in New York. So I wanted to share some of my opinions on VSTS, RA and Microsoft direction for other’s benefit.
We formed a new group at work whose charter is to assist all the development teams in working toward CD. One of the first goals for this group was to evaluate and select a release orchestration product that would meet the needs of all development groups. As we are one of the few groups to use release pipelines, we were invited to participate in the evaluation.
We reviewed all the big and a few of the smaller release products out there. I volunteered to work with Microsoft and lead the evaluation of RM.
Release Management for Visual Studio 2013/2015
Before we started this evaluation I had never looked at Microsoft release management offerings. All I knew was they had bought a product called InRelease from InCycle and had rebranded it back in the 2013 timeframe. I had also heard there was a Release Management vNext in the works.
The older solution is a seperate server product that has limited integration with TFS and a client application for interacting with the server.
My first stop for the latest RM news was Channel9, where I found many videos from a guy named Donovan Brown. I quickly realized RM vNext was a completely new product and very different from Release Management for VS 2013. After comparing the two and discussing the future of these products it was very clear we should not implement RM for VS 2013/2015 which was the currently available release solution.
They did update the RM for VS client to 2015 but it appears this product is not the go forward solution for release from Microsoft.
Release Management vNext
The new release solution is built within VSTS and mimics many aspects of the newer build system within VSTS which was announce early last year (2015). RM vNext was announced as a public preview back in November and is slated to release in Update 2 for TFS 2015.
We worked with a Microsoft contractor to setup a POC build/release orchestration within VSTS that demonstrated the key functionality we were looking for in a release orchestration product. After a couple weeks of experience with the product I am really impressed with what Microsoft has developed in less than a year. Here are some of the biggest pros for the product:
- Integrated testing (unit, integration, feature, UI, performance)
- Automated promotion
- Manual gates – Some of our steps are still manual, stakeholder UAT for example
- Best of bread integrations – Integration with non-Microsoft products (Chef, SonarQube, Docker, etc)
- Clear visibility of what is deployed where
- Extensibilty with an open source community
- Cross platform support – Java, iOS, Android, etc
- Agile product with a fast cadence – 3 weeks for VSTS, quarterly for TFS
- Scripting tasks (linux and Windows)
- FREE for up to 5 users and all MSDN subscribers
- Agents can be hosted in VSTS or you can add your own (even on-prem agents for on on-prem deployments)
- Encrypted variables – great for sensitive values like passwords
They definitely have an impressive list of built in tasks and are adding more everyday with all the source on GitHub. There are a lot of Azure related tasks which makes sense given this is all in VSTS first. It will be even better a year from now to have all kinds of tasks for specific/niche use cases that were developed by Microsoft, other vendors and the community. Until then they provide scripting tasks where you can execute any command line command/script. When asked about unsupported tasks Donovans mantra is
“Anything you can do from a commandline, you can do from our release system.”
Obviously, with a service this new there are bound to be shortcomings as well. Here are some of the missing components we identified:
- Lack of template-based management – RM does have templates but they are only useful for defining new release definitions
- Lack of pipeline to pipeline dependencies
- Limited reporting – deploy success/failures/timing, by group, etc
- Only available in Preview in VSTS, coming to TFS in coming months
Honestly these are likely only problems for larger organizations. For example, most companies won’t have 40+ pipelines or the needed complexity of depending pipeline on other pipelines. Most companies probably don’t host their own instance of TFS anymore either.
In the end we decided it wasn’t quite ready for our enterprise and our specific use cases but we will be watching it closely as new capabilities are added in future updates. I will definitely be using this for personal hobby projects and promoting it to others as a viable option in most situations.
In my opinion, RM vNext is an excellent or good choice in a couple of scenarios:
No brainer if you …
- Use Visual Studio Team Services (formerly Visual Studio Online) for source control and builds
- Have less than 6 developers or most of your staff already has MSDN licenses
- Use best-of-bread tools
Still a good option if you …
- Use TFS and can wait for TFS 2015 Update 2
- Are willing to write your own tasks/plugins for unsupported tools
If you are interested in learning more about RM check out the following links:
- VSTS DevOps Overview at Connect() 2015
- Release Management Updates at Connect() 2015
- Cross Platform builds w/VSTS
- TFS/VSTS TImelines – Jan 2016 Update
Good luck on your CD journey. Let me know if this post was helpful or you would like more specifics.