VSTS

I recently hit a problem with builds triggered by branch policies in Azure DevOps Repos. With the help of Microsoft I found out the problem and I thought it worth writing up uncase others hit the issue. Setup Folders Assume you have a Git repo with source for the UI, backend Services and common code in sub folders / [root] UI Services Common Branch Policies On the Master branch there are a policies of running...

Introduction I use Azure DevOps Pipelines for the build and release of my Azure DevOps Pipeline extensions, I previously detailed my process here . For a good few months now YAML builds have been available. These provide the key advantage that the build is defined in a YAML text file that is stored with your product’s source code, thus allowing you to more easily track build changes. Also bulk editing becomes easier as a simple text editor can be used....

I am automating the process by which we keep our build agent up to date. The basic process is to use a fork of the standard Microsoft Azure DevOps Pipeline agent that has the additional code included we need, notably Biztalk. Once I have the Packer created VM up and running, I need to install the agent. This is well document, just run _.config.cmd –help _for details. However, there is no option to add user capabilities to the agent....

A major problem when moving from the graphic editing of Azure Pipeline builds to YAML has been the difficulty in knowing the options available, and of course making typos. Microsoft have just released a VSCode extension to help address this problem – it is called Azure Pipelines I have yet to give it a really good workout, but first impressions are good. It does not remove the need for good documentation of task options, there is a need for my script to generate YAML documentation from a task....

The problem If you are like me for historic reasons you have multiple Azure DevOps organisations (instances) backed by the same Azure Active Directory (AAD). In my case for example: one was created when Azure DevOps was first released as TFSPreview.com and another is from our migration from on-prem TFS using the DB Migration Tools method; and I have others. I make active use of all of these for different purposes, though one is primary with the majority of work done on it, and so I want to make sure the inherited process templates are the same on each of them....