Build a CI/CD Pipeline With 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 code base 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 afterward. 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.

What Is Visual Studio?

Visual Studio is a powerful Integrated Development Environment (IDE). This feature-rich IDE has a robust environment for coding, debugging, and building applications. Azure DevOps (previously VS Team Services) has a comprehensive collection of collaboration tools and extensions that closely integrates the CI/CD pipeline of the Visual Studio environment. The CI (Continuous Integration) updates any code changes to the existing code base while CD (Continuous Deployment) pushes it through the deployment pipeline to build, test, and deploy further. The Visual Studio with CI/CD extensions thus automates the build, deployment, and testing process of software development. Not only that, it allows complete traceability in order to see code changes, reviews, and test results.

The quality of software is largely dependent on the process applied to develop it. The automated system of The CI/CD practices is focused on this goal through continuous delivery and deployment. Consequently, this not only ensures software quality but also enhances the security and profitability of the production. This also shortens the production time to include new features, creating happy customers with low stress on development.

In order to create a CI build, 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. DZone’s previously covered how to build a CI/CD pipeline from scratch.

How To Build a CI/CD Pipeline With Visual Studio

Step1: Enable the Continuous Delivery Extension for Visual Studio

In order to use the 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 other projects targeting Azure. The tools also allow you to improve your code quality and security.

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

*If you don't have Continuous Delivery Tools installed, 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 Continuous Integration and Continuous Delivery.

1. Go into the Solution Explorer, and right-click on your web-based project.
2. Click on the new context menu Configure Continuous Delivery.
3. A new window is displayed Configure Continuous Delivery. Click on the Add this project to source control plus button.
4. Click on the Publish Git Repo button located in the Publish to Visual Studio Team Services section in Team Explorer.
5. 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.
6. After the synchronization is finished you will see that your project is created in the Team Explorer.

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

7. In the output window, you can see that your CI/CD is set up for your project.

8. 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)

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 performs a step in your build.

1. Choose the Build Definition link provided in the Output window and copy.
2. Paste it into 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.
5. It is shown as an output of your build server which is running your build automatically.
6. Click on the Edit build definition.
7. Add an additional task.
8. 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 a new preview version of this task is available. Click on the Flag Icon and choose version 2* in order to preview.
3. There are several new items shown for the Test Assemblies. One of them is Run only impacted tests. This is an item that 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 by the changes).
4. Run tests in parallel on multi-core machines is an item that allows your tests to run in such a way as 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.

Step 5: Add an 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 a new additional task.
2. An enormous list of tasks is displayed that can be run out of the box allowing you to target any language/platform (Chef support, CocoaPods, Docker, Node.js, Java).
3. If you want to install another feature or extension that is not listed, simply click on the link Check out our Marketplace which is displayed above the list of tasks.

Step 6: Setting Encrypted and Non-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 you can set up your Continuous Integration.
2. Enabling the box Disable this trigger means that this build will run automatically whenever someone checks in code or, in 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 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:

• Code coverage
• All work items and tasks
• Deployments

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 the application from VS into Azure.

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.

• 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 to 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.

Further Reading: Release pipeline using Azure DevOps.

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.