10 key takeaways from Visual Studio Team Services (VSTS)

We love a good tool at DevOpsGuys, whether it be something for building software, releasing software or a combination of the two. One such tool that has been on the market for a while now is Microsoft’s Visual Studio Team Services (VSTS for short). Originally starting it’s life as an on-premise solution (TFS), and later moving to a SaaS offering (named Visual Studio Online at first), VSTS has grown in popularity over the last couple of years, and many clients we speak too are interesting in using it and want to know more.

Learning is a key part of our DNA at DevOpsGuys, and we like to regularly arrange training and coaching sessions so the team get the chance to learn about new tools that they might not get to use every day. So, as part of our DevOps gold partnership we have with Microsoft, we arranged a day for our delivery team to spend some time with Giles from the VSTS team, and learn a little more about what it has to offer, and certainly how it shapes up against other tools that we use.

DevOpsGuys team learning VSTS

Rather the provide a full blown review, or listing every feature, we decided to list our collective top 10 takeaways we took from the session:

1. VSTS is an example of tooling convergence done properly

The feature set of VSTS covers source control, issue tracking, continuous integration and release management (with more features to come in the future). While all of these components fully interact with each other as you would expect, what surprised me is how well Microsoft have embraced support for 3rd party components as well. External git repositories and non-Microsoft build tools slot into VSTS seamlessly, in a way that we would not have thought possible 5 years ago.

2. Workflow customisation is top-notch

The level of customisation present really shows that Microsoft have worked closely with Dev and QA engineers. Adding templates to work item fields and creating new fields is a breeze in VSTS. The kanban board customisation options are very broad, allowing you to style different sets of cards as you wish, and you can even change the amount of detail present at a glance within each task card. Work in progress limits are unfortunately not enforced, but VSTS does warn you if you’re working on too much at once.

3. The features shown were intuitive, and easy to use

We were really impressed with how often VSTS is updated (the team at Microsoft work to a 3 week release cadence – you can check out what they release at https://www.visualstudio.com/en-us/articles/news/features-timeline) and that they actually listen to their user suggestions, even if they don’t make it into the final product. if you’ve got an idea head over to https://visualstudio.uservoice.com/forums/121579-visual-studio-ide and submit away!

4. Build is for Build, Orchestration is done by release manager

The big mindset change from other CI / CD systems is that the build area should just be used to build, unit test, package and publish artefacts. The orchestration of the pipeline should be done in the release area of VSTS. You can build work-flows that enable CD, these work-flows can be complex if needed and allow for Manual Intervention and pre and post deployment checks.

5. Focus is on extensible features

It was interesting to hear that the VSTS team are moving towards delivering, where it makes sense, new features as extensions rather than integrated into the build. The marketplace for extensions is extremely easy to navigate, install extensions, and allows submissions from the community. The ease with which plugins can be created due to the exposed rest API (in JavaScript or Node for example) was fantastic, and we certainly preferred it to plugin development in Jenkins.

6. A solid tool that can be used end to end

Rather than having to swap between tools to manage all aspects of a project, due to the great feature set and the extensions available, VSTS can be used as an end to end solution straight out of the box if need be. A great example of this is not having to worry about spinning up build agents (due to hosted being available). We can certainly see ourselves using this in the future, however the only real missing feature at present is a wiki (similar to Confluence) but they mentioned this is in preview at the moment and will be released very soon.

7. Fantastic Git integration

Integration with Git and the ability to associate work items with git branches makes the whole experience more intuitive. Branches can be created directly from work items via the GUI or command line, or via a commit by using a #workID syntax.

8. Intelligent processes and controls

Mapping work items to builds and using intelligent process controls to automatically determine the next stage of the pipeline is a very powerful feature.

9. Simple to setup and use dashboards

We love (and promote the use of) information radiators wherever we can. The dash boarding in VSTS was really simple to setup and looked awesome, with loads of extensions available. Not only was it great in the tool, but the ability to extract the metrics out of VSTS to visualise in a tool such as Power BI gives you the power to bring together infrastructure metrics with build metrics in one place. The new pipeline feature that is coming soon will make the visualisation in VSTS even better (https://blogs.msdn.microsoft.com/devops/2017/05/26/new-release-definition-editor-in-team-services/).

10. Unlimited private Git repositories

One stand out feature was the ability to have unlimited git repositories with a free account. Microsoft say themselves they are not out to compete with GitHub (they are one of their biggest contributors), but we see this as a massive win to organisations that don’t want to open source any of their code but don’t want to end up paying a lot of money.

In summary, VSTS is a rapidly maturing tool. The flexibility it offers around the features you can use means it is suitable not only for technical teams (such as development or operations), but also for marketing or sales teams. It has everything you need if you want to run it as a full, end to end tool, but equally it works perfectly if you want to run it alongside existing tool sets, such as Jenkins, GitHub or Octopus Deploy, and it will seamlessly integrate with many others too.

Share this:

Readers Comments (2)

  • Hi,
    Would you say that VSTS is mature enough to replace Jira, Jenkins/TeamCity and Octopus Deploy trios? What does it need to have to be able to achieve this?
    I only know VSTS so I am biased but I think it already is in many large organisations. I have shown VSTS to large Public organisations and they are blown away by the look and feel and feature set.

    • Good question

      If you don’t have any of these tools then VSTS is a great way to get up and running with all of the things you mention. I.e. Source Control, Work Management, Build Automation and Release management. It’s maturing very quickly and it has improved significantly since we wrote the original Blog you’re responding to.

      If you’re already using the tools you mention then here are my thoughts:

      TeamCity / Jenkins. For build automation VSTS is up there with those tools. It supports all OS’s and all languages so you can easily create builds. Whilst I wouldn’t say that there is a clear leader in these tools they are all very good and you won’t be disappointed if you pick any of them. As point 4 in the blog notes, the VSTS build / Release process is a little different than if you were using TeamCity and Octopus Deploy, and you will need to adjust your mindset if you have complex pipelines built using these tools.

      Jira. The work management aspects of VSTS are clean and well thought out, however it doesn’t quite have the flexibility of Jira. This isn’t necessarily a bad thing, but you should be aware that you will need to change some of your processes to fit the tool. You also need to think about what features of Jira you’re using as not all functionality is available. For example if your operations team are using Jira Service Desk, VSTS doesn’t have this functionality, and you’ll need to integrate your service desk with VSTS. Another thing to think about, if someone is using Jira they are likely to be using Confluence. The Wiki in VSTS doesn’t really compare to Confluence at the moment but the VSTS team are aware of that and I expect it to improve rapidly.

      Octopus Deploy. This may be a personal bias, but I prefer Octopus to VSTS. The UI is more intuitive and using nuget packages as deployment units feel cleaner than using MSDeploy. The way environments are defined and configured also feels more natural in Octopus than VSTS. The good news is that you can easily integrate Octopus in to your VSTS pipeline and have the best of both worlds!

      Like any tool-set if you’re thinking of migrating, it’s not just about the functionality, but the details of how you use that functionality. Your processes and workflow will probably need to change to adapt to the way the new tooling is designed to work.

      You also need to take in to account the effort required to migrate. If you already have a lot of release pipelines then you’re going to need to spend time and effort in recreating them in VSTS. If your teams are using Jira and they have customised their workflows from the out of the box functionality, then this will also need to be replicated in VSTS.

Leave a comment

Your email address will not be published. Required fields are marked *

*

View our privacy policy