Improved traceability for pipeline trigger failures
This is probably my favorite thing out of the bunch (but please don’t stop reading after this!). When a pipeline triggers successfully, you know why and it’s visible, so that’s no problem. But when it doesn’t trigger… well… what’s the problem? You’re left double- and triple-checking things and, ultimately, putting on your Sherlock Holmes hat and doing some deduction. It can be very frustrating.
This change helps with that; it gives you a convenient UI you can look at to see what pipelines failed to trigger, and why they failed to trigger.
Hosted Linux ARM64 agents
Having a wider variety of platforms you can build on is always a good thing, especially for folks doing C or C++ development where the platform you build on makes a huge difference.
Configurable pipeline task restrictions
This is huge from a governance perspective. Now, you can disable the ability to use Marketplace tasks (i.e. third-party tasks), Microsoft tasks, or both. If you disable both, the only tasks you’ll be able to use are ones you explicitly upload.
Multi-stage pipelines Generally Available
I love YAML pipelines (I even wrote a blog about them!), and I especially love multi-stage pipelines. Multi-stage pipelines let you decompose your build and release process into different stages, all in the same YAML file – although of course, splitting things up into templates where appropriate is always a good idea.
YAML pipeline have been GA for a while now, but multi-stage pipelines are the next evolution. They give you the ability to define deployment pipelines in YAML, through the use of deployment jobs that target environments. You define the gate criteria (such as manual approvals, Azure Monitor checks, and so on) on the environment, and the pipeline engine stops the deployment until the gates are satisfied, then continue to the next stage defined in the YAML.
Additional deployment controls
In classic release pipelines, it was easy to add pre/post deployment approvals or gates (such as an Azure Monitor check for the health of an application). Multi-stage YAML deployment pipelines didn’t have anything equivalent, which was unfortunate. All they had was approval gates. Back in April, that changed! Now you can have a release gated on approvals, the successful invocation of an Azure function, a REST API call, Azure Monitor, or even just require that the pipeline implement a specific template. That last one is especially important if you have a specific template that you’ve decreed should be used as a base for all pipelines – this lets you enforce that developers are really using it and not circumventing the rules!
Azure DevOps is still my favorite devops platform, and it just keeps getting better. The feature timeline looks like it has a lot of exciting stuff planned for this year, too!