Skip to main content

Azure DevOps

What is it?​

Azure DevOps ('ADO'), is a suite of tools offered by Microsoft. It is a standalone software-as-a-service product which happens to use the same branding as the Azure cloud platform. ADO offers a developer tool suite that covers everything from code repositories, project and issue management, CI/CD pipelines, an Artifact store and wiki functionality in one place. While ADO has the advantage of providing a comprehensive set of tools under one subscription, there are more established and arguably better alternatives for each constituent tool available individually. Overall we do not recommend ADO as a default choice, though it is a usable option for some projects, particularly if using other Microsoft products or for simpler use cases.

How do you use it?​

After signing up with an Office 365 account, you are free to use all of the tools under the free plan. There is also a CLI extension. Agile project plans and boards, repositories and wikis are setup through the UI and CI/CD pipelines are configured through YAML files stored alongside source code in each code repository defining Tasks, Stages and Pipelines.

Who is it for?​

ADO is a natural choice for Azure users, but also integrates with other cloud providers. It is best suited to teams which do not already have equivalent tool in place. It can provide a great "time-to-value" ratio when starting a new project from scratch, but its lack of maturity can become a hindrance and time sink as the work progresses and more advanced requirements are uncovered.

When should you use it?​

If you're using Azure, or if you don't have an established development toolchain.

Why should you use it?​

The most compelling reason to choose ADO instead of alternatives is the simplicity of having many of your tools in one place.

Are there any common gotchas?​

  • Wiki functionality is in Markdown, but lacks some of the complex collaborative working functionality (in-line commenting, multi-editing) present in alternatives such as Confluence. Documentation
  • Wiki functionality is permissioned in the same way as the related code base, so adheres to reviewer requirements and branching strategy of the code base. This is not obvious in the GUI. Documentation
  • Pipeline development can be slow. Provisioning agents sometimes takes a while, and there's no way to test changes to pipeline files without actually running them. This can lead to slow development times when creating pipelines.
  • "Build" and "Release" pipelines are considered separate entities in the tool, but can be defined in the same YAML file.
  • The ADO API itself makes use of some undocumented APIs — an example is the "Contributions" API.
  • There doesn't seem to be any layer caching for container jobs, which makes them slow to start. By comparison, this feature has been present in other CI/CD systems for some time.
  • There seems to be a delay before Microsoft-hosted agent jobs start to wait for an available agent. This doesn't seem to be just because of contention: the scheduling can also be slow.
  • Using container images, ADO seems to delve into the container, adding a specific user and running as that, rather than running as the user configured in the image. This non-idiomatic use of containers is surprising and worth being aware of.

Advantages​

  • Everything in one place.
  • The CI/CD toolchain is entirely software as a service (with Microsoft hosted agents — it's possible to use your own agents if necessary, but there's no need for most use-cases).
  • Great integrations with cloud services — even other cloud providers.
  • It's not necessary to be using the Azure cloud platform.
  • Use as little or as much as you need — you're not obliged to use the whole suite, and it has been designed with this in mind.
  • Free for small teams, with up to 30 hours build pipeline time for a private project (and free for open-source or public projects).
  • Free for visual studio subscribers with a paid for license. Licensing and Benefits
  • Each tool in the suite is comparable to industry-standard offerings — Pipelines is similar to CircleCI, Boards to JIRA, Artifacts to Artifactory, and Wiki to Confluence.

Disadvantages​

  • Documentation often has conflicting information which makes it necessary to resort to trial and error, with build and release pipelines a particularly noticeable example.
  • Sometimes terminology is confusing. An example would be the differences between YAML and classic pipelines — Azure Pipelines contains both "Builds" and "Releases", which can be defined in one pipeline file — however, UI-created releases are called "classic" pipelines. This isn't clear in the docs.
  • Some of the tools are lacking some of the functionality of more mature offerings (e.g. the "Boards" functionality is nowhere near as configurable as a JIRA board).
  • The lack of maturity in the product shows through in the user interface, where some unexpected locations of items can make for a confusing user experience.
Public page
5th July 2022