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 the developer branch, and approved PRs (Pull requests) with the 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

Builds

This build pipeline helps to perform various tasks to build your pipeline, tasks like GIT Repository, restoring dependencies, compiling the application, running configured tests, and publishing outputs for deployments.

Once you click on New Pipeline and the page is redirected to configure your connected sources to build, i.e., CI(Continuous Integration), click on User classic editor.

Through the classic view editor, we can achieve Continuous Integration for the build pipeline, here we need to select our Repository details available in Azure DevOps.

Here we have to configure a Team Project (An Organization consisting of ‘n’ number of projects). You have to select valid project details for CIs (Continuous Integration).

Repository

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

Branches

From reports, we can create multiple branches for the development team. So here I’m showing only a master branch for the CI process.

Fill in 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 the Empty job option.

Select the ASP.NET application template as of now to create a build job and Click on the Apply button.

In this section, we have to configure Agent jobs (In these 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 the next articles.

1. In the Tasks option, our template job sequence will be available to build the repos code.
2. In the Variables option, we can declare our environment variables based on Dev, Test, and Prod environments.
3. We need to give a Name for continuous integration.
   

Once you click on the Save & Queue button, the 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 the local developer branch to the 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 solutions, it will run a test project for build solutions.
5. Once the above steps are done successfully, then our code is ready to publish
6. The complete code is getting ready and has created an artifact for CI.

Note. 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 of total CI (Continous Integration) then it fails to generate a successful artifact.

Once you click on run, the agent job will run for CI (Continuous Integration).

If we’ve any errors in our code or any DLLs or issues with restoring Nuget package manager paths, then the build failed, and login information for the 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 the build is succeeded and ready to configure release, For Release creation, Click on the Release button shown in the below screenshot.

Now we’re in the final stage of mapping Azure resources (PAAS) to deploy our code. It will support multiple items to deploy our code, as of now select the Azure App Service deployment option to configure our Azure web app services. Make sure you have admin rights on Azure resources or resource groups to configure Web app services.

Click on Add a Stage and give the proper name to your release stages. For every project, we have Dev, QA (Test), UAT & Production. Here I’m showing only a 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 the below screenshot.

You’ve to fill out Azure subscription details by clicking on the 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 the CI & CD pipeline.
2. If you already configured an Azure subscription with your email ID, you need to select it in the drop-down list as shown in the 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 the app service configuration is done, click on Create Release.

After clicking on the create release button, CD (Continuous Deployment) will be activated once you click on the create button shown in the below screenshot.

For the first release, automatic deployments will start and are shown in the below screenshot.

Once our deployment is done successfully for the configured stage we have information for each release 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 configure CI and CD configuration for your project delivery.

Continuous Integration = Build Pipeline

Now in this article, we configured only build and release pipelines. Initial setup for development will help this article configure CI and CD configuration for your project delivery.

Continuous Integration = Build Pipeline

Continuous Deployment = Release Pipeline.

Continuous Deployment Trigger

This is the option we can use to deploy our code by using the CI & CD pipeline to automate the deployment process.

Default Build {ArtefactName}- CI option is enabled to automate deployment. If in case it is disabled, automatic deployment is not done if the build (CI { Continuous Integration } ) is succeeded. This is the option to check where deployment has not happened when PRs are approved or the build has 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 the manager by enabling the pull request trigger. The default option is disabled to deploy the code for every pull request approved by the manager or TLs after code review. Enabling branching policies will help to avoid failures in the CI and CD process.

Branching Policies

1. Reviewer's approval is 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 the 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 the artifact, no worries about the save button, it is auto-saved as configured.

Pre-deployment Conditions

We have pre-deployment conditions to trigger configured deployment workflow 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.