Azure Devops Project Configuration - Pipelines

Azure DevOps Pipelines

Azure pipelines are used mainly to automate your build and deployments by using Continuous Integration and Continuous Deployment (CI & CD). No need to spend much time on deployment. For every commit from developer branch, approved PR’s (Pull requests) with manager, we can configure, automate, or manually approve a limit by giving access to each environmental staging. We will discuss this  more in depth in upcoming articles about Azure pipelines.

Main Components in Azure Pipelines

  1. Builds,
  2. Releases,
  3. Library,
  4. Task Groups,
  5. Deployment groups


This build pipeline helps to perform various tasks to build your pipeline, tasks like GIT Repository, restoring dependencies, compiling the application, run configured tests and publishing outputs for deployments.
Once you click on New pipeline and page is redirected to configure your connected sources to build, i.e, CI(Continuous Integration), click on User classic editor.
Through classic view editor, we can achieve Continuous Integration for build pipeline, here we need to select our Repository details available in Azure DevOps.
Here we have to configure Team Project (An Organization consists of ‘n’ number of projects). You have to select valid project details for CI’s (Continuous Integration).


We have an option to maintain multiple repos for Single Project. So we have to choose valid repos for CI’s process. 


From repos, we can create multiple branches for the development team. So here I’m showing only with master branch for CI process.
Fill all the required information and click on continue to pipeline job.
Once repository configuration is done and we have to configure a job to build repository code, we have multiple items to choose featured apps as shown in the below figure, or else we can create our own job by selecting Empty job option.
Select ASP.NET application template as of now to create build job and Click on Apply button.
In this section, we have to configure Agent jobs (In this agent jobs complete repos code was built in the cloud, restoring the nuget package manager for project dependencies), default artifact information (Once our code is successfully built we get an artifact to deploy it in configured stages), Click on Save & Queue. More about this Agent job execution sequence and real time usages will be detailed in next articles.
  1. In Tasks option, our template job sequenece will be available to build the repos code,
  2. In Variables option we can declare our environment variables based on Dev, Test and Prod environments, 
  3. We need to give a Name for Continous Integration.
Once you click on Save & Queue button, agent job will run for initial setup. Make sure your check-in code has  Zero errors and Zero warnings (Some warning messages will not be considered in this pipeline).
In tasks our repos code is built on every PR approved or commit approved from local developer branch to master.
  1. Nuget installer will install nuget packages.
  2. Restore the nuget package manager
  3. Build the solution
  4. If we create any test assemblies for build solution, it will run test project for build solutions.
  5. Once the above steps are done successfully, then our code is ready to publish
  6. Complete code is getting ready and has created an artifact for CI. 
These steps we can alter or configure at any time as per our organization process requirements. In this process if we get any failed cases total CI (Continous Integration) then it failed to generate a successful artifact.
Once you click on run, agent job will run for CI (Continuous Integration),
If we’ve any errors in our code or Missing any DLL’s or issue with restoring nuget package manager paths, then build failed and log in information for build will be available here to monitor the failed cases & issues. Once all agent job stages are succeeded without any error or failed cases, then build was succeeded and ready to configure release, For Release creation, Click on Release button shown in the below screenshot.
Now we’re in the final stage to map Azure resources (PAAS) to deploy our code. It will support multiple items to deploy our code, as of now select Azure App Service deployment option to configure our Azure web app services. Make sure you have an admin rights on Azure resources or resource groups to configure Web app services.
Click on Add a stage and give proper name to your release stages. For every project we have Dev, QA (Test), UAT & Production. Here I’m showing only single stage (Cloud_Host) to deploy our code. I’ll try to explore more about stages and replacing environmental variables for each environment in upcoming articles.
Click on View stage tasks shown in below screenshot,
You’ve to fill Azure subscription details by clicking on Manage option. Based on selected Azure subscription details you’ll get Azure app services details which are allocated in resource groups.
  1. Adding or Managing your Azure resources subscription details to configure CI & CD pipeline.
  2. If you already configured Azure subscription with your email id, you need to select in drop-down list as shown in below screenshot.
  3. Select App type( Here I'm using Azure web app services(PAAS) to deploy my solution).
  4. Select valid web app services which we are going to publish.
  5. You can add agents if required by clicking on '+' symbol here(not suggested for RND)
Once app service configuration is done, click on Create Release.
After clicking on create release button, CD (Continuous Deployment) will be activated once you click on create button shown in below screenshot.
For first release, automatic deployments will start and are shown in the below screenshot.
Once our deployment is done successfully for configured stage we have information for each releases and deployment information is shown in the below screenshot.
Now in this article we configured only build and release pipelines. Initial setup for development will help this article to configure CI and CD configuration for your project delivery.
Continuous Integration = Build Pipeline
Now in this articles we configured only build and release pipelines. Initial setup for development will help this article to configure CI and CD configuration for your project delivery.
Continuous Integration = Build Pipeline 
Continuous Deployment = Release Pipeline.

Continuous Deployment Trigger

This is option we can use to deploy our code by using CI & CD pipeline to automate the deployment process.
Default Build {ArtefactName}- CI option is enabled to automate deploy. If in case it is disabled, automatic deployment was not done if build (CI { Continuous Integration } ) is succeeded. This is the option to check where deployment has not happened when PR’s is approved or build was succeeded.

Pull Request Trigger

We’ve options to pull request enable trigger, and build branch filters trigger. Now here we are automating continuous deployment for every Pull request (Commits, Check-ins) approved by manager by enabling pull request trigger. Default option is disabled to deploy the code for every pull request approved by manager or TL’s after code review. Enabling branching policies will helps to avoid failures in CI and CD process.
Branching Policies
  1. Reviewer's approval required for every Pull Request
  2. Code review comments should be resolved in raised Pull Requests.
  3. Build Succeeded (Choosing a build pipeline (CI) to build your code).
  4. Interlinked work items should be completed (Work items traceability).
Pull Request Trigger
By enabling this option, it will create a new version of artifact to deploy the code and this information will be available in the release once it is successful or failed in the deployment process. You’ve to select a targeted branch to build a new version of artifact, no worries about save button, it is auto-saved as configured.
Pre-deployment Conditions
We have pre-deployment conditions to trigger configured deployment work-flow for CD (Continuous Deployment).
Artifact Filters
Select artifact condition(s) to trigger a new deployment. A release will be deployed to this stage only if all artifact conditions match.
Gates: Define gates to evaluate before the deployment.
Deployment queue settings: Define behavior when multiple releases are queued for deployment
Schedule: Trigger a new deployment to this stage at a specified time.
Pull Request Deployment: Enabling this will allow pull request-based releases to be deployed to this stage. Keep it disabled if this is a critical or production stage.
Pre-Deployment Approval: Select the users who can approve or reject deployments to this stage
Gates: Defining gates to evaluate before the deployment by giving delay time to code publish.
Deployment queue settings: Define behavior when multiple releases are queued for deployment.
Happy coding and configuring with Azure DevOps!