Background I’ve written a good few extensions for Azure DevOps Services. Most of the early ones I wrote were written in PowerShell, but of late I have tended to use Typescript (targeting Node.JS) for the added cross-platform support. This has led me to consider if it was worth the effort to convert all my legacy extensions to support cross-platform usage? This is of course assuming the tasks the extension contains are useful on a non-Window platform. There is no point porting a Windows only tool away from PowerShell. ...

Introduction There are times when you need to run Private Azure DevOps agents as opposed to using one of the hosted ones provided by Microsoft. This could be for a variety of reasons, including needing to access resources inside your corporate network or needing to have a special hardware specification or set of software installed on the agent. If using such private agents, you really need to have an easy way to provision them. This is so that all your agents are standardised and easily re-creatable. Firstly you don’t want build agents with software on them you can’t remember installing or patching. This is just another form of the “works on one developer’s machine but not another” problem. Also if you have the means to replace the agents very regularly and reliably you can avoid the need to patch them; you can just replace them with newer VMs created off latest patched base Operating System images and software releases. ...

Issue I have been busy automating the provision of our private Azure DevOps Agents using Packer and Lability; a more details blog post is on the way. All has been going OK on my test rig, but when came to run the automation pipeline on our main build HyperV host I got an error > Get-VmcConfigurationData : Datafile EnvironmentsBuildAgent-VS2017BuildAgent-VS2017.psd1 NOT FOUND. Exiting But the file was there! I check the default Lability paths, but all these looked OK, and none pointed to my environment location on C: anyway ...

Over the past few days I have published two major enhancements to my Azure DevOps Cross Platform Release Notes Extension. Added Support for Builds Prior to version 2.17.x this extension could only be used in Releases. This was because it used Release specific calls provided in the Microsoft API to work out the work items and changesets/commits associated with the Release. This is unlike my older PowerShell based Release Notes Extension which was initially developed for Builds and only later enhanced to work in Releases, but achieved this using my own logic to iterate across Builds associated with Releases to work out the associations. With the advent of YAML multistage Pipelines the difference between a Build and a Release is blurring, so I thought it high time to add Build support to my Cross Platform Release Notes Extension. Which it now does. ...

I have recently been doing a TFS 2015 to Azure DevOps Server 2019.1 upgrade for a client. The first for a while, I have been working with Azure DevOps Service mostly of late. Anyway I saw an issue I had never seen before with any version of TFS, and I could find no information on the Internet. The Problem The error occurred when I tried to queue a new build after the upgrade, the build instantly failed with the error ...

I recently posted on my initial experiences with GitHub Actions. I had hoped to deliver a session on this subject a DDD 14 in Reading , I even got so far as to propose a session. However, life happened and I found I could not make it to the event. So I decided to do the next best thing and recorded a video of the session. I event went as far as to try to get the ‘DDD event feel’ by recording in front of a ’live audience’ at Black Marble’s offices. ...

Introduction GitHub Actions open up an interesting new way to provide CI/CD automation for your GitHub projects, other than the historic options of Jenkins, Bamboo, Team City, Azure DevOps Pipelines etc. No longer do you have to leave the realm of GitHub to create a powerful CI/CD process or provision a separate system. For people familiar with Azure DevOps YAML based Pipelines you will notice some common concepts in GitHub Actions. However, GitHub Action’s YAML syntax is different and Actions are not Tasks.You can’t just re-use your old Azure DevOps tasks. ...

Hit a strange problem today trying to do a simple Work Item update via the Azure DevOps REST API. To do a WI update you need to call the REST API Using the verb PATCH With the Header “Content-Type” set to “application/json-patch+json” Include in the Body the current WI update revision (to make sure you are updating the current version) So the first step is to get the current WI values to find the current revision. ...

I have recently been getting a problem swapping between different organisations in Azure DevOps. It happens when I swap between Black Mable ones and customer ones, where each is back by different Azure Active Directory (AAD) but I am using the same credentials; because I am either a member of that AAD or a guest. The problem is I get into an authentication loop. It happens to be in Chrome, but you might find the same problem in other browsers. ...

I have recently be working on a release pipeline that deploys to a server behind a corporate firewall. This is done using an Azure DevOps private build agent and works fine. As the service is a basic REST service and takes a bit of time to start-up I though a gate was a perfect way to pause the release pipeline until service was ready for the automated tests. However, I hit a problem, the gates always failed as the internal server could not be resolved. ...