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.
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.
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.
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.
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!