In our small development team, we usually merge code without formal pull requests. Instead, changes are committed directly by the developer responsible for the project, and while I don’t need to approve every change in my role as the senior developer, I still need to stay aware of what’s being merged.  Manually reviewing each commit was becoming too time-consuming, so I built an automated process using Power Automate, Azure DevOps, and Azure AI.Now, whenever a commit is made, it triggers a workflow that summarizes the changes and sends me an email.This simple system keeps me informed without slowing down the team’s work. Although I kept the automation straightforward, it could easily be extended further.For example, it could be improved to allow me to reply directly to the committer from the email or even display file changes in detail using a text comparison feature in Outlook.We didn’t need that level of detail, but it’s a good option if deeper insights are ever required. Journey We get started with the Azure DevOps trigger “When a code is pushed”. Here we specify the organization name, project name and repository name. We can also specify a specific branch if we want to limit our tracking to simply that branch otherwise it tracks all the available branches to the User. Then we have a foreach loop that iterates over the “Ref Updates” object array. It contains a list of all the changes but not the exact details.This action pops up automatically as well when we configure the next action. Then we set up a “Azure DevOps REST API request to invoke” action. This has connection capabilities to Azure DevOps directly so it is better to use over a simple REST API action. We specify the relative URL as {Repository Name}/_apis/git/repositories/{Repository ID}/commits/{Commit ID}/changes?api-version=6.0 The Commit ID shows up as newObjectId in the “When code is pushed” trigger. Then we pass the output of this action to a “Create Text with GPT using a prompt” action under the AI Builder group.I’ve passed the prompt as below but it took several trials and errors to get exactly what I wanted. The last action is a simple “Send an email” one where I’ve kept myself as a recepient and I’ve added a subject and a body. Now to put it all together and run it – And here is the final output – When the hyperlinks are clicked they take me straight to azure while pointing to the file which is referred. For instance, if I click on the Events Codeunit – Conclusion Summarizing commit changes is just one way automation can make life easier.This same idea can be applied to other tasks, like summarizing meeting notes, project updates, or customer feedback.With a bit of creativity, we can use tools like this to cut down on repetitive work and free up time to focus on learning new skills or tackling more challenging projects.By finding smart ways to streamline our workflows, we can work more efficiently and open up more time for growth and development. If you need further assistance or have specific questions about your ERP setup, feel free to reach out for personalized guidance. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com.

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