Build a CI/CD (Continuous Integration/Continuous Deployment) Pipeline from Visual Studio

This article will demonstrate how to build a complete CI/CD pipeline in Visual Studio and deploy it to Azure using the new Continuous Delivery Extension for Visual Studio. Using CI, allows you to merge the code changes in order to ensure that those changes work with the existing codebase and allows you to perform testing. On the other hand, using CD you are repeatedly pushing code through a deployment pipeline where it is built, tested, and deployed afterwards. This CI/CD team practice automates the build, testing and deployment of your application, and allows complete traceability in order to see code changes, reviews and test results.

In order to create a CI build and a release pipeline and Release Management that is going to deploy the code into Azure, all you need is an existing web-based application and an extension from the marketplace. Otherwise, you can always contact the experts that offer end-to-end DevOps consulting services based on the modern methodologies designed to deliver high-quality software faster.

For more information about how to work with Kubernetes cluster and deploy it to Azure Kubernetes Service (AKS) and work with Azure Container Registry, see **Kubernetes cluster for beginner

Step 1: Enable Continuous Delivery extension for Visual Studio

In order to use Continuous Delivery Tools for Visual Studio extension you just need to enable it. The Continuous Delivery Tools for Visual Studio extension makes it simple to automate and stay up to date on your DevOps pipeline for ASP.NET and other projects targeting Azure. The tools also allow you to improve your code quality and security.

1. Go to Tools, choose Extensions and Updates.
2. From the prompted window, select Continuous Delivery Tools for Visual Studio and click Enable.

*If you don’t have installed Continuous Delivery Tools go to Online Visual Studio Marketplace, search for “Continuous” and download it.

Step 2: Create a project in Team Services

In this step you are going to create a project in Team Services and put your project code there without leaving your IDE. Team Services is a tool that allows you to build a continuous integration and continuous delivery.

1. Go in the Solution Explorer, right-click on your web-based project.
2. Click on the new context menu Configure Continuous Delivery.
3. New window is displayed Configure Continuous Delivery. Click on the Add this project to source control plus button.

1. Click on the Publish Git Repo button located in the Publish to Visual Studio Team Services section in Team Explorer.
2. Your Microsoft Account is automatically fetched from your IDE. Also is displayed the Team Services Domain which will be used and your Repository Name. Click on the Publish Repository button in order to create a project in Team Services.
3. After the synchronization is finished you will see that your project is created in the Team Explorer.

Now your project is created into Team Services account (the source code is uploaded, there is a Git Repository and it is generating continuous delivery pipeline automatically).

1. In the output window you can see that your CI/CD are setting up for your project.
2. After a while, you are going to get 3 different links:

• Link to the build
• Link to the release
• Link to the assets created in Azure which is going to be the target for your deployment. (application service)

For more information about how to work with Docker like, pull docker image, run docker image and work with container, see **Docker for beginners

Step 3: Open the project in Team Services

A build definition is the entity through which you define your automated build process. In the build definition, you compose a set of tasks, each of which perform a step in your build.

1. Choose the Build Definition link provided in Output window and copy.
2. Paste it in a browser in order to open the project containing your application in Team Services.
3. The summary for the build definition is displayed. You can see that the build is already running.
4. Click on the build link.

1. It is shown an output of your build server which is running your build automatically.
2. Click on the Edit build definition.

1. You are going to see all the tasks that were automatically set up in order to be able to build the code that you had inside your Visual Studio. You can:

• Add additional task
• Customize the tasks that are already there

Step 4: Test Assemblies Task

Each task has a Version selector that enables you to specify the major version of the task used in your build or deployment. When a new minor version is released (for example, 1.2 to 1.3), your build or release will automatically use the new version. However, if a new major version is released (for example 2.0), your build or release will continue to use the major version you specified until you edit the definition and manually change to the new major version.

1. Click on the Test Assemblies.
2. You can see a little flag icon which means that there is a new available preview version of this task. Click on the Flag Icon and choose version 2* in order to preview.

1. There are several new items shown for the Test Assemblies One of them is Run only impacted tests. This is an item which allows tools to analyze which lines of code were changed against the tests that were run in the past and you will know which tests execute which lines of code (you will not have to run all of your tests, you are able to run only the tests that were impacted with the changes).
2. Run tests in parallel on multi-core machines is an item which allows your tests to run in such a way to use all the cores you have available. Using this item you will effectively increase the number of tests running at the same time, which will reduce the time to run all the tests.

1. Code coverage enabled is another very useful item that during executing your unit test, VSTS will monitor the code as it is being tested and highlight which lines of code were actually covered with your tests.

Step 5: Add additional task

A task is the building block for defining automation in a build definition, or in an environment of a release definition. A task is simply a packaged script or procedure that has been abstracted with a set of inputs. There are some built-in tasks in order to enable fundamental build and deployment scenarios.

1. Click on the Add Task plus button in order to create new additional task.
2. An enormous list of tasks is displayed that can be run out of the box that allow you to target any language/platform. (Chef support, CocoaPods, Docker, NodeJS, Java).
3. If you want to install another feature or extension which is not listed, simply click on the link Check out our Marketplace which is displayed above the list of tasks.

1. In new tab is opened Visual Studio Marketplace with all additional features and extensions. All of them are open source and you can actually go to GitHub and see their source code. You also can write your own task using PowerShell or NodeJS.

For more information about how to work with Git with animation. All commands will be represented in graphical animation. E.g. git branch, git merge, git rebase, git cherry-pick and many others, see **Mastering Git with animation

Step 6: Setting encrypted and none encrypted Variables

Variables are a great way to store and share key bits of data in your build definition. Some build templates automatically define some variables for you.

1. Go and click on the second tab named Variables (next to the tab Tasks).
2. Click on the padlock located next to the variable value, in order to encrypt it.
3. After encrypting, the value of the variable is displayed with asterisks, and no one can see this value except the person who encrypted it.

Step 7: Turn on the Continuous Integration (CI) Trigger

On the Triggers tab you specify the events that will trigger the build. You can use the same build definition for both CI and scheduled builds.

1. Go and click on the third tab named Triggers, where actually you can setup your Continuous Integration.
2. Enable the box Disable this trigger means that this build will run automatically whenever someone checks in code or with other words when a new version of the source artifacts is available.

Step 8: Build Definition Options

If the build process fails, you can automatically create a work item to track getting the problem fixed. You can specify the work item type. You can also select if you want to assign the work item to the requestor. For example, if this is a CI build, and a team member checks in some code that breaks the build, then the work item is assigned to that person.

1. Go and click on the fourth tab named Options.
2. Enable the box Create Work Item on Failure. CI builds are supposed to build at every check in, and if some of them fail because the developer made an error, you can automatically create a work item in order to track getting the problem fixed.
3. Default agent queue option is displayed in the second half of the Options. In the drop down list are listed all available pools:
   • Default (if your team uses private agents set up by your own)
   • Hosted (Windows based machine, if your team uses VS2017 or VS2015)
   • Hosted Linux Preview (if your team uses development tools on Ubuntu)
   • Hosted VS2017 (if your team uses Visual Studio 2017)

Step 9: Build Summary

You can see the summary of the build, in other words everything that happened during the build, following the next steps:

1. Click on the Summary button located in the upper right corner.

1. Click on the build number, located in the Recently completed.

1. The build summary is displayed. You are able to see:

• Code coverage
• All work items and tasks
• Deployments

For more information about DevOps, what is DevOps, how to work with DevOps, what is Continuous Integration and what is Continuous Delivery. What is the difference between CI pipelines and CD pipelines and many other topics. See **DevOps for beginner

Step 10: Release definition

A release definition is one of the fundamental concepts in Release Management for VSTS and TFS. It defines the end-to-end release process for an application to be deployed across various environments. Remember that you as a developer, never have to leave VS in order to deploy an application from VS into Azure.

1. Click on the succeeded deployment link, displayed in the Build Summary page, in the Deployments section. This is a CD portion of a CI/CD.

1. A release definition is displayed that deployed the code into Azure.
2. Click on the three dots located next to the particular release definition.
3. From the displayed context menu, select Edit.

1. The deployment is very similar to the build system. All it does is taking a result of CI and deploying it in Azure using CD. In this page there are displayed:

• Series of environments
• Tasks that you want to perform in each environment

Step 11: Check if the application is really deployed from Visual Studio into Azure

Microsoft Azure is a cloud computing service for building, testing, deploying, and managing applications and services through a global network of Microsoft-managed data centers. In this step you will verify if your web application is deployed in Azure, following the next steps:

1. Go in your Azure portal.
2. Click on the Resource Groups.
3. Search for the “demo”.
4. Click In the search results on your web project “e2edemo”.
5. Open the web application link.

1. Click on the Browse button displayed in the upper menu.

1. The website which code is running in your Visual Studio should be opened, now hosted in Azure. Now every change that developer makes will immediately be deployed inside Azure environment, which is giving you a true Continuous Delivery.

Conclusion

Continuous Integration is a software development practice in which you build and test software every time a developer pushes code to the application. Continuous Delivery is a software engineering approach in which continuous integration, automated testing, and automated deployment capabilities allow software to be developed and deployed rapidly, reliably, and repeatedly with minimal human intervention.

High-performing teams usually practice Continuous Integration (CI) and Continuous Delivery (CD). VSTS not only automates the build, testing and deployment of your application, but it gives you complete traceability to see everything in the build including changes to your code, reviews, and test results, as a tool which is fully supporting DevOps practices.