I decided to create a video of my blog post ‘Swapping my Azure DevOps Pipeline Extensions release process to use Multistage YAML pipelines’. [iframe width=“560” height=“315” src=“https://www.youtube.com/embed/WMQ0G9eXczE" frameborder=“0” allowfullscreen=”" allow=“accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture”] The video up on YouTube

I have today released another enrichment to the dataset available in my Cross Platform Release Notes Azure Pipeline Task. It now returns an extra array of data that links work items and commits to build artifacts. So your reporting objects are: Array Objects workItems – the array of all work item associated with the release commits – the array of all commits associated with the release pullRequests - the array of all PRs referenced by the commits in the release...

I recently post about Enriching the data available in my Azure DevOps Pipelines Cross Platform Release Notes Task by adding Pull Request information. Well, that first release was fairly limited only working for PR validation builds, so I have made more improvements and shipped a newer version. The task now will, as well as checking for PR build trigger, try to associate the commits associated with a build/release pipeline to any completed PRs in the repo....

In the past I have documented the build and release process I use for my Azure DevOps Pipeline Extensions and also detailed how I have started to move the build phases to YAML. Well now I consider that multistage YAML pipelines are mature enough to allow me to do my whole release pipeline in YAML, hence this post. My pipeline performs a number of stages, you can find a sample pipeline here....

I have recently hit a problem that some of my Azure DevOps YAML pipelines, that I use to build my Azure DevOps Pipeline Extensions, are not triggering on a new PR being created on GitHub. I did not get to the bottom of why this is happening, but I found a fix. Check and of make a note of any UI declared variables in your Azure DevOps YAML Pipeline that is not triggering Delete the pipeline Re-add the pipeline, linking to the YAML file hosted on GitHub....

A common request for my Generate Release Notes Tasks is to enrich the data available beyond basic build, work item and commit/changeset details. I have resisted these requests as it felt like a never ending journey to start. However, I have now relented and added the option to see any pull request information available. This feature is limited, you obviously have to be using artifacts that linked to a Git repo, and also the Git repo have to on an Azure DevOps hosted repository....

Background GitHub is a great system for individuals and OSS communities for both public and private project. However, corporate customers commonly want more control over their system than the standard GitHub offering. It is for this reason GitHub offers GitHub Enterprise. For most corporates, the essential feature that GitHub Enterprise offers is the use Single Sign On (SSO) i.e. allowing users to login to GitHub using their corporate directory accounts....

I recently got a very interesting PR for my Cross-platform Release Notes Azure DevOps Pipelines Extension from Kenneth Scott. He had added a new templating engine to the task, Handlebars. Previous to this PR the templating in the task was done with a line by line evaluation of a template that used my own mark-up. This method worked but has limitations, mostly due to the line by line evaluation model. With the Kenneth’s PR the option was added to write your templates in Handlebars, or stay with my previous templating engine....

Problem I recently tripped myself up whist adding SonarQube analysis to a rather complex Azure DevOps build. The build has two VsTest steps, both were using the same folder for their test result files. When the first VsTest task ran it created the expected .TRX and .COVERAGE files and then published its results to Azure DevOps, but when the second VsTest task ran it over wrote this folder, deleting the files already present, before it generated and published it results....

I wrote recently about Creating Hyper-V hosted Azure DevOps Private Agents based on the same VM images as used by Microsoft for their Hosted Agent. As discussed in that post, using this model you will recreate your build agent VMs on a regular basis, as opposed to patching them. When I came to do this recently I found that the Packer image generation was failing with errors related to accessing packages....