Microsoft VSTS is dead. Long live Azure DevOps!

New Thinking 20 March 2019 Michael Harrod

On 10 September 2018, Microsoft announced that their cloud-based developer collaboration tool, Visual Studio Team Services (VSTS), would be ambitiously rebranded as ‘Azure DevOps’.

Recognising the universal appeal of ‘DevOps’, this name change also roughly coincided with my return to the world of Microsoft source control and was my first taste of their CI/CD pipeline solution. In this article, I want to share the circuitous path that finally led me back here and offer some thoughts on Azure DevOps.

Why am I so late back to the party?

My first experience collaborating with other developers was in a very small team back in 2000 (just in time to enter the dotcom bubble as it was in the process of bursting), using archaic tools such as Visual Basic 6.0.

In order to work together on the same project without accidentally overwriting and breaking each other’s work, we used a Version Control System (VCS) – and that system happened to be a thing called Microsoft Visual SourceSafe. Compared to using no VCS, Visual SourceSafe was an improvement and did indeed allow us to collaborate and deliver software together. However, I gradually learned that compared to virtually any other VCS available at the time, it was a liability.

I won’t go into painful detail – others have already covered this, such as the brilliant Jeff Atwood in his article Source Control: Anything But Source Safe. But, to summarise my experience, I seemed to spend more time dealing with intermittent data corruption problems and grappling with awkward, sluggish tools than I did actually writing code to provide value to our customers. That’s the real goal, isn’t it?

“I was so traumatised by early experiences with Visual SourceSafe that, for a very long time, I couldn’t bring myself to go anywhere near a product from Microsoft that purported to offer source control functionality”

Fast forward to 2009. I once again joined a small team and was given the opportunity to set out some new software development practices. I did my research and, at the time, Subversion ticked all of our boxes. It was lightweight, reliable, inexpensive (i.e. free) and enjoyed great community support online.

By 2012, we had covered a lot of ground in web app development using more modern tools such as .NET C#, but our deployments were gradually turning to spaghetti. They relied on a series of poorly-documented manual steps that could be skipped or changed based on the whim of the client and the release engineer’s desire to get to bed.

We identified the glaring need for a CI/CD pipeline so we could build, test and deliver our software reliably and continuously. For a great rundown on CI/CD (Continuous Integration / Continuous Delivery) pipelines, take a look at Nigel Charman’s article Continuously Delivering Better Value.

Once again, I did the research and TeamCity, the CI/CD tool from JetBrains, ticked these new boxes. I was delighted with the progress we were making. We could onboard new team members with ease and manual production deployments that previously took several hours with unpredictable results were soon running like clockwork and completing in minutes.

However, our software delivery utopia wasn’t without its minor issues:

  • We had a (gradually ageing) TeamCity server that needed occasional attention such as patching
  • Newer versions of development frameworks were becoming available which needed upgrades to TeamCity or associated software to properly use. Developers started requesting the ability to use these new frameworks but we had a bottleneck (i.e. me), reluctant to dedicate serious time to upgrading servers and troubleshooting new issues for what were often minor improvements or developer conveniences
  • Our peers in the industry began praising the improved flexibility of Distributed Version Control Systems (DVCS) such as Git and we were eager to leverage this

I was so traumatised by early experiences with Visual SourceSafe that, for a very long time, I couldn’t bring myself to go anywhere near a product from Microsoft that purported to offer source control functionality. In 2018, the situation changed.

Azure DevOps from the trenches

I joined a new team on a software ‘rapid delivery’ engagement and was privileged to be alongside some of the best practitioners of DevOps, Agile and QA working in the country.

When I joined the project, Microsoft VSTS for its CI/CD and VCS features was already well established. We were using SCRUM to manage the flow of work and Atlassian Jira as the tool for tracking work items.

The rebranding to Azure DevOps occurred just as we were winding up the engagement and was met with some cynicism. We go to lengths to help our clients understand that DevOps is largely about culture, trust and the way people work together in a technical setting, not just about shopping for the right tool. In blatantly labelling their offering as ‘Azure DevOps’, I do think that Microsoft has undone some of our work of trying to prevent people from conflating a culture that requires dedication to establish with a product you can simply buy off the shelf.

Branding issue aside, this project gave me a great opportunity to consider how we used Azure DevOps as a team for an intensive five-month engagement and contrast it with some of my past experiences. I offer my impressions below.

  • For someone accustomed to self-hosted VCS and CI/CD, Azure DevOps was a relief. We were no longer responsible for the upkeep of the underlying CI/CD and VCS environment itself. Maintenance and upgrade duties now sit with Microsoft and we are free to focus on the areas where we can add differentiating value
  • In moving from a self-hosted environment to the cloud, one trade off is that your source code is no longer on infrastructure you have exclusive control over. The benefits are numerous, but it’s important to be conscious that this model can increase the risk of leaking confidential information due to inadvertent or malicious actions

Benefits of Azure DevOps Repos

  • The implementation of Git, known as Azure DevOps Repos, adds a new whole level of versatility for management of source control compared to something like Subversion. Particular benefits are:
    • The Pull Request process builds peer review into your culture
    • The ability to commit (and potentially rollback) in-progress changes to a local repository before pushing them to the server gives developers much more freedom to work safely and ensure the integrity of the source code on the server
    • Migrating the contents of a repository from one location to another is now a simple process using standard Git features
    • In stark contrast to my very early experiences combining Visual SourceSafe with an integrated development environment (IDE), we found Git’s integration with Visual Studio to be very reliable
  • There is a quite granular security model available for managing permissions and the integration with Azure Active Directory was very effective. This degree of control does mean you will need to dedicate some time to understanding your security requirements and how to configure Azure DevOps accordingly

Working around extensions

  • There is a rich marketplace of extensions available. If there’s a feature you really need that’s not a part of the core functionality, in our experience, someone’s probably already written an extension to do this. Be aware that it’s easy to gradually build a dependence on third-party tools with patchy support. We had a frustrating experience installing an extension to help us automate updates to some XML configuration files. It worked perfectly with simple files but later failed when we tried using it with more complex ones. We discovered this was a known bug that, to their credit, the author had already fixed. Unfortunately, we were unable to access the ‘fixed’ version, even after contacting the extension author who confirmed it had been published and carrying out the steps we understood were necessary to upgrade the extension in our environment. We had to abandon the use of this extension and find a workaround. When key parts of your solution have a fuzzy definition of exactly who is responsible, this is the type of pitfall you may encounter

2767 devops inblog ad nov18 04

  • When using Azure DevOps Pipelines to deploy applications or provision infrastructure to Microsoft Azure, we found the experience to be simple, flexible and reliable. This comes as no surprise because Pipelines is effectively the onramp to Microsoft’s multi-billion dollar Azure environment for their favourite community – developers
  • On that note, if you’re not at least investigating Infrastructure as Code (IaC) right now, then you need to be. We leveraged Azure Resource Manager (ARM) to provision and configure infrastructure such as web applications and databases inside our Azure environment using simple JSON templates and tasks triggered directly from Pipelines. The beauty of this approach is that the templates are stored and tracked by Azure DevOps Repos and automatically deployed to Azure. At a glance, we can see the exact configurations deployed to our various environments (e.g. DEV, TEST, PROD) and have a detailed log of any infrastructure changes made, when, by whom and with what result

Get on board with Azure DevOps Boards

  • The work item tracking functionality, known as Azure DevOps Boards, is something we didn’t make heavy use of due to Jira having already been selected. But, if I was starting another project today with Azure DevOps, I would seriously evaluate Boards for work item tracking due to the rich traceability you get. For example, if an error occurs as a result of a change, you can easily link it back to, not only the code responsible, but the work item itself that motivated the change. Knowing the intent and context surrounding a code change puts you a whole lot further ahead if you are trying to debug an issue related to it
  • Unless you are already committed to something like Atlassian Confluence, the Wiki functionality in Azure DevOps is a simple and clean way to store and browse documentation. We only made very superficial use of this but it should meet most needs for small, technically-focused teams

Filling the pipeline

  • As the workload on our Pipeline increased due to the addition of new automated tests and deployment tasks, we started to find that wait times were getting out of hand. To clear the bottleneck, we arranged for additional parallel jobs to be set up so we could have multiple pipeline tasks running simultaneously. This reduced the wait times back to a few minutes, which is a reasonable time for a developer to wait for the outcome of their most recent code commit
  • The pricing model is very attractive at the low end, but be aware that the costs can start to mount up as you need to add more users or parallel build jobs. In particular, the decision to buy additional parallel build jobs can be an interesting trade off. There is usually scope to significantly optimise the performance of your pipeline and defer the need to buy more capacity, but bear in mind the process of optimising can itself be lengthy. You may choose to accept an incremental increase in ongoing cost to get an immediate performance boost through additional parallel jobs, but consider whether investing in early optimisation will result in a long-term gain by reducing the ongoing costs

What next?

There’s plenty more to Azure DevOps than I’ve covered here, such as Test Plans, Artifacts or the ability to host your own on-premises Azure DevOps Server. I’ve concentrated on the features we used to deliver our project and I hope this has been useful.

The key takeaway I’d like to leave you with is this...

The DevOps landscape has changed and so has Microsoft. They’re demonstrating a very real commitment here. I would encourage you to take a fresh look at Azure DevOps, particularly if you have been a long-time Microsoft CI/CD and VCS sceptic, like me!