My experiences with Visual Studio Team Services so far
I can’t remember the exact date when I started using Visual Studio Team Services, but it was somewhere in 2014 when it was called “Visual Studio Online”. First, the only features it had was some work item tracking, version control and build services based on XAML.
So two and a half years from from now, Visual Studio Team Services evolved into a product that can be used to orchestrate a deployment pipeline from front till back and take care of your complete Application Lifecycle. Here are some features of VSTS that pop out for me:
One of the best features of VSTS is that it’s the SaaS solution of TFS. Remember the old days where you had to plan server capacity for installing TFS to make sure you didn’t run into performance issues once you started to work with it? Gone are those days. You just pay per user and that’s it. I don’t know or care on how many servers it runs, as long as I can do my work. Of course, when building or releasing, you need build agents to do that work. You can use hosted agent provided by Microsoft or use private agents if you have special needs in your build process. Either way, you can easily scale up or down, so if you need more computing power, just adjust the number of agents. When you need to use private agents, having those as virtual machines in the cloud also gives you the freedom and scalability you want. It’s hard for me to find a good reason to use TFS nowadays, except when dealing with regulatory issues when working for government of banks that don’t allow you to use the SaaS solution.
Flexible build and release definitions
In the old days (read: more than half a year ago), there were XAML build definitions that were hard to customize. In order to do so, you needed to edit them in Visual Studio as a workflow. Usability wasn’t something that applied to this situation. Luckily, XAML build definitions are replaced by a intuitive system where you can build and edit your own build definitions in your browser. The same applies for creating and managing release definitions. When Microsoft bought Release Management, it was a clunky and separate product but nowadays it’s fully integrated in VSTS and TFS and a pleasure to use.
If you miss functionality or want to extend the product, you can go to the marketplace to share or download extensions. There are extensions that add new build and release steps that you can use, but also extensions to ease exploratory testing, create reports or integrate with other products like Slack. Extensions can either be free or paid.
Speed of development
One big advantage of having a SaaS solution is that you’re always working on the latest version. Microsoft works hard on adding new functionality to it and releasing it early and often. So if you find that something doesn’t work that well yet or isn’t there, chances are that they are already working on it. Luckily, they are very transparent and have their road map published. Downside of this speed of development is that VSTS sometimes doesn’t feel that mature yet and that you need to implement other practices when some functionality is changed. An example of this is how they deal with release agents: in the beginning, they had to be installed on the target server. Now it’s best practice to use a different machine and use something like WinRM to deploy to the target server (has to do with multiple-server deployment scenarios). In the near future, this is going to be changed and then the agents again need to be installed on the target server. I understand why they do it but it will require some extra work to be done.
I’m looking forward to all the new developments and I’m glad that there is a solid solution for your Application Lifecycle for .NET and non .NET projects.