Background My post-op chemotherapy treatment for my adrenal cancer meant I was struggling to get any fitness, so in 2019 I bought a Ribble CGR-ALe ebike based around the Mahle X35 system. It was in fact pre-ordered prior to the bike’s initial release by Ribble. This bike served me well, getting me out and about before any fitness returned. Since getting fit again, it has also proved useful for my 20KM each-way commute. Allowing me to avoid the traffic jams but still get to work without getting too hot and sweaty. ...

Background We have a few non-critical systems running as single instance Docker containers hosted on Azure WebApps. On these systems we have started to see the warning Your app is configured with Docker Compose, which is set to retire on March 31, 2027. For multi-container support, please update your app to support sidecar containers. So, best to get ahead of the game I looked into how to update them, factoring in that ours are all BICEP defined and deployed with Azure DevOps Pipelines ...

The Problem I recently had a customer who’s Azure DevOps Pipelines BizTalk 2020 build had suddenly started to fail. They said they had not altered their BizTalk solution, or their build process. The Analysis Turns out the issue was that the operating system on the VM that hosts their self-hosted Azure DevOps agent had had a update. This update it seems had updated the version of MSBUILD shipped with Windows. Making it the newest version, newer than the one shipped with Visual Studio 2019. ...

The Problem Today I was upgrading our self hosted Delinea Secret Server from 11.9.x to 12.0.x. These upgrades are usually an easy process, all achieved within the Secret Server web UI, but not today. The upgrade proceeded as normal, downloading the new package, updating the DB schema and updating the binaries, but then it stopped. It did not move onto the next step. The Analysis I remoted onto our Windows server hosting our Secret Server instance and via Internet Information Service Manager launched the Secret Server instance via the URL http://localhost. This showed the error ...

The Problem I have been using Packer to generate our Azure DevOps Build agent disk images for a while now. The advantage of this process is that our Azure DevOps self-hosted agents have the same installed software, and hence capabilities, as the Microsoft hosted ones. So it is trival to move a build pipeline from self-host agents to either Microsoft hosted agents or Managed DevOps Pools. However, the generation process for these agent VM images has been the gift that keeps giving and has generated a few blog posts … ...

Whilst presenting on ‘Migrating DevOps Toolsets’ at DDDNorth 2026 last weekend, I mentioned a blog post & flowchart I had created a few years ago to guide people through their options when migrating from what was then called TFS (Azure DevOps Server) to what was then called VSTS (Azure DevOps Services) When I got home, I thought that this old post & flowchart were worth bringing up to date. So, I also took the chance to make them a little more generic, making them more useful as a guide for a wider range of DevOps toolset migrations, not just Azure DevOps. ...

Background I have been doing the regular maintenance in our Azure DevOps Pipelines of updating the versions of tasks. This usually means you perform one of the following actions Just increment the major version number in the YAML e.g task: MyTask@1 to task: MyTask@2 when there is a newer version of a task available. If the task is out of support and abandoned, swap to a different task, one that is still being supported, that does the same action. Fork the out of date task, and perform the updates to bring it back into support. Swap to a PowerShell/Bash script that wrappers a CLI tool to do the same action - increasingly my go to solution. It is a shame the first option is often not possible, but don’t get me, or other MVPs on the long running subject of abandoned insecure Azure DevOps extensions ...

I have posted in the past about the issues a misconfigured cache can have in Azure DevOps Pipelines, or GitHub Actions. Well it caught me out again today, wasting a few hours of my time. Today, I had a failing integration test in a CI/CD pipeline, but all the tests passed locally. The failing test was looking for a certain number of rows returned from a API with known seed test data. I had revised the seed data and my test, but in my CI/CD pipeline my test was failing as it was still looking for the old number of rows. ...

The Issue I recently had an issue trying to add a new Azure DevOps Pipeline Agent Pool to an existing Azure DevOps 2022 Server via the Team Project Collection Settings UI. When tried to add the agent pool I got the error Access denied needs Manage permissions to perform this action. For more information, contact the Azure DevOps Server administrator The problem was that I was the Azure DevOps Server administrator ...

The Issue I have been chasing what it turned out to be a non-existent fault when trying to ingest test code coverage data into our SonarQube instance. I saw my ‘problem’ in a .NET 8.0 solution with XUnit v3 based unit tests, this solution was being built using this Azure DevOps Pipelines YAML - task: SonarQubePrepare@7 inputs: SonarQube: "SonarQube" scannerMode: "dotnet" jdkversion: "JAVA_HOME_17_X64" projectKey: "${{ parameters.sonarQubeProjectKey }}" projectName: "${{ parameters.sonarQubeProjectName }}" projectVersion: "$(GitVersion_Major).$(GitVersion_Minor)" extraProperties: | # Additional properties that will be passed to the scanner, # Put one key=value per line, example: sonar.cpd.exclusions=**/AssemblyInfo.cs,**/*.g.cs # Ingest the test results and coverage data sonar.cs.vscoveragexml.reportsPaths=$(Agent.TempDirectory)/**/*.coveragexml sonar.cs.vstest.reportsPaths=$(Agent.TempDirectory)/**/*.trx - task: DotNetCoreCLI@2 displayName: ".NET Build" inputs: command: "build" arguments: > --configuration ${{ parameters.buildConfiguration }} --no-restore projects: "$(Build.SourcesDirectory)/src/MySolution.sln" - task: DotNetCoreCLI@2 displayName: ".NET Test" inputs: command: "test" projects: "$(Build.SourcesDirectory)/src/MySolution.sln" arguments: > --configuration ${{ parameters.buildConfiguration }} --collect "Code coverage" --no-restore --no-build - task: SonarQubeAnalyze@7 displayName: 'Complete the SonarQube analysis' inputs: jdkversion: "JAVA_HOME_17_X64" - task: SonarQubePublish@7 displayName: 'Publish Quality Gate Result' inputs: pollingTimeoutSec: "300" At the start of the SonarQubeAnalyze@7 task log I could see that the .coverage file was found and converted into a .coveragexml file. However, there were multiple ‘The device is not ready’ errors when parsing this file later in the process. ...