The only unfortunate thing about Microsoft Azure DevOps is that they chose to use "DevOps" in the name, the latest and greatest buzzword right now. The rest of the news on Azure DevOps is almost exclusively good.
I decided around March of 2018 to move NML from our existing development cloud solutions to Azure DevOps. It has turned out to be one of the most impactful and positive changes we have made this year, and I hope to shine some light on why in this article.
NML has always relied heavily on cloud platforms for most of our software needs. It is a cost-effective way to operate a small to medium business, especially in the software industry. At the beginning of 2019, the cloud services we used looked as follows:
NML is almost exclusively a Microsoft stack service provider, but we embarked on our cloud journey long before Microsoft had an offering like Azure DevOps in place. As such, we developed our business along the Atlassian line of cloud products.
The Atlassian suite served us well enough, but it would be a bald-faced lie to say I am a fan of any of the Atlassian cloud platforms. Octopus Deploy was a much later addition as our builds and releases were generally done on Jetbrains TeamCity.
My biggest grievance with the Atlassian suite of products is that they are just too complicated to manage. You almost need a doctorate just to open the administration sections. Take note of the plural: "sections"! With enough time and anti-depressants, one could usually eventually navigate your way to what you wanted, but you have to set aside at least 2 days to get anything done. And you have to go through that every time since there is virtually no way you can remember what you did previously over a length of time.
Each platform requires you to have different licenses, which can make it quite an expensive proposition. That is to say, you have to pay for Jira and ServiceDesk and Confluence and Bitbucket and TeamCity and Octopus Deploy all separately!
You have wildly different user experiences when working across all these different systems. It is a rather huge barrier to entry for newcomers. You have to have different introduction sessions to cover each and the poor soul that has to keep up with each platform's particular nuances had no chance to get it right.
Identity management is a complete nightmare. In an age where there is a potentially fatal security incident around every corner, identity management is critical. Each user on each platform needs a different account. In fairness, Atlassian does have a single identity across its platforms, which helps some. But even there you have different user experiences, between Bitbucket and the Jira suite for instance.
Lastly, it is a huge drain on effectiveness to hop between platforms while carrying out one's duties. As a developer, you need to view your story and tasks on Jira. Additional info might be in Confluence. You have to pull your source code and view pull requests on Bitbucket. Builds on TeamCity and deployments on Octopus deploy. Every time you have to switch to a different system, there is a certain level of context switching that goes along with it. I have yet to experience positive context switching in my career.
Our current state of affairs looks as follows:
As you can see, it is a much shorter list and we are without a doubt better off on each of the pain points.
DevOps is much, much easier to configure than Atlassian. It is not nearly as configurable, though. That said, I have not missed a single one of those extra configuration options.
Somehow, Azure DevOps has the balance just right, and my experience is that when I am looking for a configuration to achieve something the way Jira does it, it is more as a result of my ignorance on how DevOps approaches the problem.
Azure DevOps has a pretty simple licensing model and it will suffice to say here that we are paying tens of thousands of Rands less per month. There is not even a comparison to the cost differential. The simple reason is that we only need to pay one license for all the features we need.
There are additional costs one needs to be aware of, for instance reserving pipeline hosts, but that is more than covered by the savings on TeamCity and VM licensing alone.
Our ecosystem has reduced by 3 platforms. Almost all the work a newcomer will do upon joining will be exclusively limited to Azure DevOps. We have therefore removed a huge hurdle to team integration for new joiners.
Azure DevOps offers a single user experience to
The remaining cloud services, except for Jira ServiceDesk, use Microsoft identities associated with NML. In other words, you only need to log in once. Additionally, we can enforce best security practices like multi-factor authentication, role-based access control (RBAC), etc across the whole business on our most critical platforms. It is incredibly useful to be able to manage all user access to your various platforms from a single place, Azure Active Directory.
This is only anecdotal, but I strongly believe our teams' effectiveness has improved. We now have seamless integration and tracking from stories to commits to releases. Also, nobody on the team needs to hop between various platforms or interfaces to perform their work from start to finish.
The above items are just the pain points Azure DevOps helped us with. Here are some more wonderful features that make it worthwhile:
The builds and release in Azure DevOps it super easy to configure and maintain. They have extensive support for various build types and release platforms. For example, one of our most used builds pipelines relies on Jekyll, a distinctly non-Microsoft solution. We also generate beautiful release notes by leveraging the integrated nature of stories and commits.
Testers and the testing effort is part of the project delivery with Azure DevOps. It has been a complete life-saver for us in establishing a working test regime that can verifiably assure quality delivery.
The pull request system is sublime. You can automatically run CI builds and require it passes for new pull requests, require a minimum number of approvers, require a work item to justify the pull request, etc, all as part of a repository branch policy.
Our experience on Azure DevOps has been overwhelmingly positive. I put this down in large to the fact that we are a Microsoft stack company and are already comfortable with and pretty well embedded in the Microsoft scene. However, I think Azure DevOps has a much broader reach than a Microsoft context, and can very easily work for any technology stack.