Posts

Showing posts from October, 2022

Use an Azure Virtual Machine Scale set as Azure DevOps agents

Image
Author: Akhil M Anil || DevOps Engineer An agent in  Azure DevOps is a computing infrastructure with installed agent software that runs a job to perform a task/ a set of tasks. There are different types of agents available for the users such as: Microsoft Hosted Agents Self-hosted Agents Scale Set Agents Azure Virtual Machine Scale Set Agents Azure Virtual Machine Scale Set agents is a feature within Azure DevOps. It allows you to use an existing Virtual Machine Scale Set to host your Azure DevOps agents and allows Azure DevOps to manage the scaling out and in of those agents. Therefore, you get the ability to deploy your agents in a private network and control the dependencies that are installed on the agents. Note: You cannot run Mac agents using scale sets. You can only run Windows or Linux agents this way. Scale set agents currently supports Ubuntu Linux, Windows Server/DataCenter 2016/2019, and Windows 10 client. In this article, we will configure the Linux Scale Set agent, insta

Configure an Azure DevOps self-hosted Windows agent in Docker

Image
Author: Akhil M Anil || DevOps Engineer An agent is computing infrastructure with installed agent software that runs job to perform a task/ a set of tasks. There are different types of agents available for the users such as: Microsoft Hosted Agents Self-hosted Agents Scale Set Agents Self-hosted Agents An agent that we set up and manage on our own to run jobs is a  self-hosted agent .  Self-hosted agents give us more control to install dependent software needed for our builds and deployments. Also, machine-level caches and configuration persist from run to run, which can boost speed. We  can install the agent on Linux, macOS, or Windows machines. We can also install an agent on a Docker container. This Article covers configuring an agent on a Docker container and use the agent to run job to perform tasks. Run a self-hosted agent in Docker We can set up a self-hosted agent in Azure Pipelines to run inside a Windows Server Core (for Windows hosts), or Ubuntu container (for Linux hosts)

Getting the complete list of Repository names and details in Azure DevOps Project and Publishing as a CSV file using ADO Pipeline

Image
  Author: Akhil M Anil || DevOps Engineer Getting the complete list of Repository names  in Azure DevOps Project using REST Api and Publishing as a CSV file Representational State Transfer (REST) APIs are service endpoints that support sets of HTTP operations (methods), which provide create, retrieve, update, or delete access to the service's resources. This article covers creating a REST API call pipeline in Azure DevOps to access the Repos and retrieve the list of all Repositories created and publish the list as a csv file. Full code can be found in GitHub:  Azure-DevOps/Repos-List Nb: For authenticating to ADO, we are using PAT token. Ref:  Use personal access tokens - Azure DevOps | Microsoft Learn   Steps: Push the developed pipeline (azure-pipelines-repos.yml) code and python (repos.py) code to Azure Repos. If you have an existing PAT token use the PAT and make sure the PAT token has access to list the Repository list, if not create a PAT token and use the PAT token. Create

Pull Request Validation pipeline for branch policy in Azure DevOps

Image
Author: Akhil M Anil || DevOps Engineer A "PR" pipeline is just a pipeline that is triggered when a user creates a new pull request. It can be used for running tests, static analysis, linting, or other checks against the incoming branch as a way to ensure coding standards are met before merging the PR. Here we will see how we can impose branch policy in the PR validation pipeline and restrict the merging of codes to higher branches directly from lower branches. Consider we have 4 main branches Master/main, SIT, Integration, and dev. If we have an approved branching strategy that restricts the merging of the codes to any other branches than the specified branches, for example, the codes from dev can only be merged to the Integration branch, and the testing and deploying to the test environment will happen from the Integration branch, and similarly, after successful testing in a test environment the codes can be merged to SIT branch and testing and deployment in a UAT enviro