In modern development workflows, maintaining consistency across build pipelines is crucial. A well-organized build process ensures reliability and minimizes repetitive configuration. For developers using YAML-based pipelines (e.g., Azure DevOps or GitHub Actions), template extension is a powerful approach to achieve this. This blog explores how to use YAML templates effectively to manage build stages for multiple functions in your project. What is Template Extension in YAML? Template extension allows you to define reusable configurations in one place and extend them for specific use cases. Instead of repeating the same build steps for every function or service, you can create a single template with customizable parameters. Why Use Templates in Build Pipelines? – Scalability: Add new services or functions without duplicating code. – Maintainability: Update logic in one place instead of modifying multiple files. – Consistency: Ensure uniform processes across different builds. Step-by-Step Implementation Here’s how you can set up a build pipeline using template extension. 1. Create a Reusable Template A template defines the common steps in your build process. For example, consider the following file named buildsteps-template.yml: parameters: – name: buildSteps # the name of the parameter is buildSteps type: stepList # data type is StepList default: [] # default value of buildSteps stages: – stage: secure_buildstage pool: name: Azure Pipelines demands: – Agent.Name -equals Azure Pipelines x jobs: – job: steps: – task: UseDotNet@2 inputs: packageType: ‘sdk’ version: ‘8.x’ performMultiLevelLookup: true – ${{ each step in parameters.buildSteps }}: – ${{ each pair in step }}: ${{ pair.key }}: ${{ pair.value }} 2. Reference the Template in the Main Pipeline This is your main pipeline file: trigger: branches: include: – TEST {Branch name} paths: include: – {Repository Name}/{Function Name} variables: buildConfiguration: ‘Release’ extends: template: ..\buildsteps-template.yml {Template file name} parameters: buildSteps: – script: dotnet build {Repository Name}/{Function Name}/{Function Name}.csproj –output build_output –configuration $(buildConfiguration) displayName: ‘Build {Function Name} Project’ – script: dotnet publish {Repository Name}/{Function Name}/{Function Name}.csproj –output $(build.artifactstagingdirectory)/publish_output –configuration $(buildConfiguration) displayName: ‘Publish {Function Name} Project’ – script: (cd $(build.artifactstagingdirectory)/publish_output && zip -r {Function Name}.zip .) displayName: ‘Zip Files’ – script: echo “##vso[artifact.upload artifactname={Function Name}]$(build.artifactstagingdirectory)/publish_output/{Function Name}.zip” displayName: ‘Publish Artifact: {Function Name}’ condition: succeeded() Benefits in Action 1. Simplified Updates When you need to modify the build process (e.g., change the .NET SDK version), you only update the template.yml. The changes automatically apply to all functions. 2. Customization Each function can have its own build configuration without duplicating the pipeline logic. 3. Improved Collaboration By centralizing common configurations, teams can work independently on their functions while adhering to the same build standards. Best Practices Final Thoughts YAML template extension is a game-changer for developers managing multiple services or functions in a project. It simplifies pipeline creation, reduces duplication, and enhances scalability. By adopting this approach, you can focus on building great software while your pipelines handle the heavy lifting. If you haven’t already, try applying template extension in your next project—it’s a small investment with a big payoff. We hope you found this article useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Here we will see how to backup the repository using the YAML file. This includes the following steps Create an Azure DevOps Personal Access Token (PAT) Create a YAML file Create Subscription Connection Create an Azure DevOps Personal Access Token (PAT) Step 1: Sign in to your Azure DevOps Portal Step 2: Go to Personal Access Token Step 3: Create a Token by clicking on “New Token“ Give it a name Select the “Read” checkbox to fetch the repository Click on Create Note: Copy and Save the token as you will not be able to see it again Create a YAML Pipeline Step 1: Go to Pipelines Step 2: Choose Azure Repos Git Step 3: Select your repository Step 4: Configure it as a starter Pipeline Below is the default code you will see. Trigger: The wildcard (*) will monitor all the branches, the pipeline will be triggered whenever you have any changes in your repository CmdLine: The command calls “git clone –mirror ” to make a copy of your repository. PAT needed to be used while fetching a repository Archive Files: It will take the git repository which was cloned in the previous step and then zipped to “Backup.zip” File Copy: It will take the archive copy and send it to Azure Blob Storage Creating a Subscription Connection Step 1: Go to Project Settings Step 2: Go to Service connections Step 3: Click on New service connection Step 4: Choose Azure Resource Manager Step 5: Select Authentication Method as Service Principal (automatic) Note: Make sure to use the same credentials to login to DevOps as in Azure Portal Step 6: Subscription will be chosen automatically. Give it a name Select a resource group where you have your storage account Then save Step 7: Use the connection name in YAML. Save and Run It will create a Job See the status of the Job After Job gets completed, you will see a zip file in your blob

This is blog is intended to share information about creating a CI / CD Pipeline using YAML file. Case Study Create a CI/CD pipeline using YAML for a web application So, let’s start with lets creating a project Use cmd to create a project and then bind it to a solution Create Solution dotnet new sln -o Test_CI_CDPipeline Then change the directory cd Test_CI_CDPipeline Then create a Web Project inside Test_CI_CDPipeline dotnet new mvc -n Test_CI_CDPipeline Now bind the project to solution dotnet sln HelloWorldApp.sln add HelloWorldApp.Web\HelloWorldApp.Web.csproj Need to restore all the dependencies dotnet restore Now, build the solution. Do not restore dependencies while we are building the solution. dotnet build –no-restore –configuration release Publish the solution dotnet publish –no-build –configuration release. Now a project is created, built, and published on local Machine. The aim is to achieve the same using a continuous integration pipeline. For this one need to have an Azure DevOps account. In that, create an organization (if not created already) and then create a project. You can either create a private project or a public project. Before that, one needs to initialize git in the location machine. Go to the working folder (location of the location file). Initiate the git git init The purpose of git is to host the source code. Ensure that binaries created while building a project should not be included. For this add gitignore file to the project. Now, you need to stage all the content git add . Commit the content git commit -m “—Name-it—” Now you can push this to the Azure DevOps repo. Copy and paste the command and everything from the local machine will be pushed to Azure Repo. Create Pipeline Go to Pipelines on the Left panel and click on Create Pipeline. It gives two options YAML or Classic editor. Select Azure Repos Git (YAML) as it will be used to push the local project in further steps Select the project created earlier Select the type of project you are creating After this, you will see a YAML file. Here one needs to edit the file and make changes as per the need. Below is a sample code Trigger:  specifies which branches cause a continuous integration build to run Pool: specifies which pool to use for a job of the pipeline. A pool specification also holds information about the job’s strategy for running. Steps: specifies a list of tasks that need to be run Task: specifies commands/tasks that need to perform to achieve a build file. Build the project first Publish the Project Publish it as an Artifact Click save and run. Below shows the artifact created Now, this artifact needs to be consumed by an Azure website. For this, one needs to create a web application. Create an app service for that in the Azure portal. We need to create a service connection to connect Azure resource. Go to Project Setting, then service connections Create a New connection and select Azure Resource Manager Choose Automated (here you need to login with the same credentials that you use for the Azure portal) and click next Choose the subscription and Resource group. Give a name to the connection Now, proceed with creating a release pipeline Select the template you want to use and then apply. Choose the artifact from where you want the files to be picked up and click add Click on Job to a stage Add your Azure subscription, select the app service you have created, and save it. Then click on Create release Click on Deploy Once you are done deploying, click on the URL from the App service

While setting up and working on a project in Azure DevOps sometimes we realised that the process we have selected is not what we need for the current project and we want to change the process in AzureDevOps without loosing any task. Before making any changes, we should keep a check i.e. The inherited process you are trying to move the project should contain at least one of the expected work items Open the project and click on the project setting as shown in the screenshot below In the project setting you can see the project process as “Agile”, click on it. As you click on it, you will be redirected to the below page where you have to select the project and click on the three vertical dots for changing the process. As you click on change a process, a panel will be open from the left-hand side from where you need to select the process. As you select the process and click on save, the project process will get change You can go back to the project and see, all the tasks visible which you can move as per the new process.

GitHub is a platform that is used by developers to work together on the same program at the same time. The underlying program is called Git and it keeps track of different versions and by giving support for merging conflicting modifications by different people. GitHub is an online hosting platform of code that you share through Git. Git is a command-line tool, GitHub adds an excellent web platform to share between developers and it also gives you an external backup of your code. Azure DevOps provides Git service that you need to complement your existing workflows. In order to getting started with Git go to below link and click on getting started with Git https://azure.microsoft.com/en-us/services/devops/ Click on new Project and select visibility to private Clone the local repo on DevOps once we set the repo we can then clone it to Visual Studio or any other IDE. We can see the different projects gets uploaded on DevOps Git repo service as shown below. The basic operations Below are the most basic commands/operations for Git that will allow you to get started easily: Clone: “downloading” an existing folder (called repository) of code on GitHub to your local computer so that you can work on it Commit: when you have made changes in your code repository, you must commit it before you can upload it to GitHub Push: when you have committed your changes, you then push them so that they get registered on GitHub and so that potential collaborators can see them Pull: when someone else is working on the same code and they have pushed their changes, your code is not the newest version anymore. To receive the newest version, you should do a pull