Build a CI/CD Pipeline With Visual Studio
Learn how to set up a CI/CD pipeline in Visual Studio Team Services to automate the build, testing, and deployment of your code.
Join the DZone community and get the full member experience.Join For Free
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 a 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.
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.
Step1: Enable the 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 and other projects targeting Azure. The tools also allow you to improve your code quality and security.
- Go to Tools, choose Extensions and Updates.
- 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.
- Go in the Solution Explorer, right-click on your web-based project.
- Click on the new context menu Configure Continuous Delivery.
- A new window is displayed Configure Continuous Delivery. Click on the Add this project to source control plus button.
- Click on the Publish Git Repo button located in the Publish to Visual Studio Team Services section in Team Explorer.
- 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.
- 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).
- In the output window, you can see that your CI/CD are setting up for your project.
- 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.
- Choose the Build Definition link provided in Output window and copy.
- Paste it into a browser in order to open the project containing your application in Team Services.
- The summary for the build definition is displayed. You can see that the build is already running.
- Click on the build link.
- It is shown an output of your build server which is running your build automatically.
- Click on the Edit build definition.
- Add an 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.
- Click on the Test Assemblies.
- 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.
- There are several new items shown for the Test Assemblies One of them is Run only impacted tests. This is an item which allows to 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).
- 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.
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.
- Click on the Add Task plus button in order to create a new additional task.
- An enormous list of tasks is displayed that can be run out of the box that allows you to target any language/platform. (Chef support, CocoaPods, Docker, NodeJS, Java).
- 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.
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.
- Go and click on the second tab named Variables (next to the tab Tasks).
- Click on the padlock located next to the variable value, in order to encrypt it.
- 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.
- Go and click on the third tab named Triggers, where actually you can set up your Continuous Integration.
- 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.
- Go and click on the fourth tab named Options.
- 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.
- Default agent queue option is displayed in the second half of the Options In the drop-down list are listed all available pools:
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:
All work items and tasks
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.
- A release definition is displayed that deployed the code into Azure.
- Click on the three dots located next to the particular release definition.
- 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
MicrosoftAzure 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:
- Go to your Azure portal.
- Click on the Resource Groups.
- Search for the "demo."
- Click In the search results on your web project "e2edemo."
- Open the web application link.
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.
Published at DZone with permission of Mohamed Radwan, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.