IntegrationWorkz

 When connecting to external resources like Azure Resource Manager you will need a service connection in Azure DevOps. Normally I utilize a service principal for this purpose. The certificate issued by Microsoft Entra ID was normally valid for two years but Microsoft changed this to three months in the release of January 18th and is promoting the usage of Workload identity federation  (WIF). When testing this WIF based service connection I noticed that the OIDC token is only valid for about 50 minutes. This time is to short for the PowerShell script I use to monitor the Azure Image Builder image builds. These image build processes can take up to four hours but fail now with an error message like the one below. A configuration issue is preventing authentication - check the error message from the server for details. You can modify the configuration in the application registration portal. See https://aka.ms/msal-net-invalid-client for details.  Original exception: AADSTS700...

To make the switch from the graphical release pipelines in Azure DevOps I am missing two features. The first one is to be able to defer a deploy and the second one is to exclude certain deployment steps without the need for editing the YAML file.  The defer option is something Microsoft has to solve in their Azure DevOps proposition. It's a feature which you have in the graphical release pipeline but what they have not implemented yet in their YAML pipeline replacement. Approvals and certain gate conditions are implemented on the environment but the defer option is still missing .  Pipeline The conditional deployment option can be implemented with the help of runtime parameters and expressions . In the parameter section you define boolean parameters which will control the deploy behavior. With the expressions you can control which stage/job/task should be executed when the pipeline runs. In the below YAML sample I experimented with conditions in the azure-pipelines.yml ...

In my post called " Switch from Azure DevOps release pipeline to YAML based CI/CD pipeline " I explained how to implement a combined CI/CD pipeline based on YAML templates. Because most of the deployments in my daily work are consuming multiple artifacts I had to do some additional R&D to find a solution for those releases in Azure DevOps. Base structure In the first post about the transition to YAML CI/CD pipelines I introduced the base structure. The templates I want to reuse are added to the yaml-template folders in the root of my GIT repo. For the CD pipelines which lack a CI phase I introduce a new folder called yaml-releases which will contain the YAML files for releases which are based on multiple artifacts. The folder structure within my GIT repo is thus: yaml-releases releaseArea myMultipleArtifactsRelease azure-pipelines.yml cd-job.yml yaml-templates jobs ... templates ......

It has been years ago I started applying continuous integration (CI) and continuous deployment (CD) principles at work. Around 2005, it was the time of Visual Studio 2005 Team System, we started using a build server in our daily development process. From then on it was no longer more: "it works on my machine". With every check-in of code changes a CI build was started which compiled your code and run unit tests which verified the quality of your code.  Deployment was in the beginning still a process of manually copying build artifacts and script files to servers and doing the installation process based on the instructions from the deployment manual (if available). Gradually it migrated to scripts (mix of batch/PowerShell/VBScript files) that our release automatically ran from the build server. In 2016 we migrated from our on-premise TFS 2008 based environment to the cloud solution nowadays known as Azure DevOps . We upgraded our MSBuild driven CI/CD pipelines to the new vis...

If you want to delete an Azure AD tenant which contains an Azure DevOps Enterprise application record you will first have to remove this Enterprise application record. Removing the Azure DevOps Enterprise record will not succeed from the user interface because the delete button is greyed out. To remove the record follow these steps: Create a new Global Admin account in the directory you are trying to delete. Make sure you copy the temporary password. Start Windows PowerShell commandline and run: Install-Module -Name AzureAD . Once done run Connect-AzureAD . You will be prompted to login, login with the user you created and you will be asked to change your password. Run Remove-AzureADServicePrincipal -ObjectId [Object ID] to remove the Enterprise application record. Remove the Global Admin account you created. After the Azure DevOps Enterprise record is removed you can delete the Azure AD tenant.

At the moment I am middle in the process of writing my ARM templates for deploying an Azure DevTest Lab environment based on an Azure DevOps CI/CD pipeline. Unfortunately not all the options you can configure from the Azure portal are exported by the automation script option of the resource group or are available within the Azure Resource Explorer . So much of the information you need you have to find in the REST API documentation of DevTest Labs. To find out what the results are from the Policies - List GET method I need to query the REST API. I will be using the Postman app for this purpose. To query the Azure REST API you will need to be authenticated. You can do this in two ways: with your own Microsoft/Azure AD account or with a service principal . Because of the ad-hoc character of my research the Microsoft account route is the one I will use. Retrieving bearer token To retrieve the bearer token of my Microsoft account I need to authenticate myself. For this purpose we w...

Eldert Grootenboer ( Motion10 ) posted a series of blog posts around setting up CI/CD for Azure API Management using Azure Resource Manager templates. In his series he describes how you can using Visual Studio Team Services to host GIT repositories and set up a build and release pipeline for deploying your API Management service and it's APIs. This blog post is an extension on his first article wich describes the setup for deploying the API Management service and is done as a nested ARM template (as described in the linked template article). Scenario The API Management service is default hosted under Microsoft's azure-api.net DNS domain. To provide a professional experience to our developers we want to host our API Management service under our own DNS domain. The SSL certificate will be stored in Azure Key Vault and the configuration will be part of the CI/CD pipeline as described by Eldert in his blog posts. To make the scenario more production like we will store ...