Background If you are using staged deployment in Azure DevOps, you will probably have multiple Azure Service Connections. So, it makes sense that you might want to use a Service Connection name that is stored in a variable group as a parameter to a templated YAML pipeline. # the build pipeline stages: - stage: UAT jobs: - deployment: ARM_Provisioning timeoutInMinutes: 0 environment: 'Staging' variables: - group: UAT pool: vmImage: 'windows-latest' strategy: runOnce: deploy: steps: - template: YAMLTemplates\ProvisionUsingARM.yml parameters: AzureResourceGroup: $(AzureResourceGroup) AzureServiceConnection: $(AzureServiceConnection) - stage: PROD jobs: - deployment: ARM_Provisioning timeoutInMinutes: 0 environment: 'Staging' variables: - group: PROD pool: vmImage: 'windows-latest' strategy: runOnce: deploy: steps: - template: YAMLTemplates\ProvisionUsingARM.yml parameters: AzureResourceGroup: $(AzureResourceGroup) AzureServiceConnection: $(AzureServiceConnection) With a template YAMLTemplates\ProvisionUsingARM.yml that uses the AzureServiceConnection variable ...

One of the most useful, and it seems relatively unknown, features in the GitHub web UI is the ability to edit multiple files in the UI and commit them in a single commit. This is done by loading VS Code in the browser when in the code view by pressing . (the full stop) The reason I find this so useful is that it allows me to make a series of small related changes to a project without having to clone the repository or using a CodeSpace, very useful when editing the related YAML files of reusable workflows in GitHub Actions. ...

This is is one of those posts I write so I remember how to do something in the future. Background I recently had a need to generate many Visual Studio SQL Database Projects from existing databases. Being a good ’lazy developer’ I wanted to do this from the command line so I could automate the process, but it took me far to long to work out how The Manual Way If you only have one database to import you can do this manually by using the Import option in Visual Studio for an individual SQL Database Project. ...

Introduction Previously Rik Hepworth has posted on ‘Importing bicep lint output as test results in Azure DevOps pipelines’. In his post he showed how you could move from using the ARM-TTK to validate ARM templates to using the built inBicep Linter. Rik’s solution involved taking the Bicep Lint output and converting it via the .SARIF format to JUnit so that it could be published to an Azure DevOps pipeline run as a set of test results. ...

Introduction Last year I posted on how to create your own Azure DevOps maintenance jobs. This solution has been working well for me, until the Azure DevOps Service connection’s Entra ID Service Principle secret expired. So, I thought it well worth revisiting the creation of this maintenance job but this time using Workload Identity federation to authenticate, and hence never again have to worry about the secret expiring. Updated Setup Process Note: This is a modification to the creation of the service connection, but the core the maintenance job setup remains the same as in my original post ...

The Issue Whilst refreshing an end-to-end devops demo, one I use for both Azure DevOps and GitHub, I hit a problem. The new Playwright UX Tests, that were replacing old Selenium ones, were failing on the GitHub hosted runner. The strange thing was the same tests worked perfectly on: My local development machine The Azure DevOps hosted runner And strangest of all, a GitHub self hosted runner The Solution Adding some logging to the tests showed the actual issue was that on the GitHub hosted runner the code to count the rows in an HTML table was always returning 0. ...

The Issue I have been recently refreshing a GitHub end-to-end demo I use for talks and workshops that I had not looked at for a while. It shows how legacy code bases can be deployed with GitHub Actions and Azure App Services. The demo uses MSDeploy to deploy a ASP.NET web application to Azure App Services. The MSDeploy package is created as part of the GitHub Action workflow. The workflow uses a PowerShell script to do the deployment using the following: ...

Background Our on premise build agents, though using the same image as the Microsoft hosted agents (generated using Packer, as I have previously posted about), have some extra setup done by Lability as they are deployed to a Hyper-V host. Most of this is specific to the needs of running on Hyper-V e.g. setting up networking, creating a 2nd disk to act as a working store for the build agent, and of course installing the Azure DevOps agent itself. ...

Background We have for many years based our Azure DevOps build and release pipelines on on-premise agents. This was done to provide a means to scale up each agent using ‘bigger & faster’ local VMs then the Microsoft Hosted agents provided, and to utilise spare Hyper-V hosts we had after moving services such as SharePoint to Office 365. To provide consistency of build agent experience to our developers, we decided we wished to use the same VM images on our on-premise agents as used by the Microsoft’s hosted agent pools. I have blogged previously on the process of creating these images with Packer and deploying them to Hyper-V with Lability. This is a process we still follow every couple of months to keep the images reasonably up to date. ...

Azure DevOps Server 2022.2 has recently been released. Unexpectedly this minor 2022.2 release includes a change in supported versions of SQL, SQL2017 support has been dropped. So, if someone attempted an upgrade from 2022.1 to 2022.2 they will get the error “TF255146: The SQL Server instance you specified (nnnnn) is version ‘SQL Server 2017 RTM’, which is not supported by this version of Azure DevOps Server. For more information about supported versions of SQL Server, visit https://www.visualstudio.com/docs/setup-admin/requirements " ...