How to incrementally adopt VSTS for devops automation

VSTS has fantastic devops-enabling features, but one of the common issues when planning to adopt it is how to plan the large migration of work and project plans from other tools.  The good news is that you don’t have to change anything about where you are tracking your work or projects in order to make use of builds, packaging, or automated deployments.  If you track your work in Jira, your code in GitHub, then you’ll want to configure VSTS like the following:


If my VSTS does not look like yours, you’ll want to turn on the new navigation features by selecting your profile picture in the top right corner.


With this configuration, you’ll be able to:

  • Configure continuous integration builds
  • Run unit tests & component-level integration tests
  • Package versioned release candidates
  • Architect release candidate packages in the onboard Nuget server
  • Create releases for a particular build
  • Map the progression of pre-production environments as well as production
  • Deploy release candidates
  • Run full-system tests against deployed instances of your builds
  • Trend statistics about your tests
  • Integrate static code analysis into your devops pipeline
  • Configure and run load tests

Many teams have systems to track projects and existing source code repositories in place.  When bringing online devops methods, it may be appropriate to focus the VSTS project on just the capabilities needed at the moment.