Azure CI/CD Pipeline using DevOps for Visual Studio Team Services

Azure CI CD Pipeline using DevOps for Visual Studio Team Services
Share this

In this article – Azure CI CD Pipeline using DevOps for Visual Studio Team Services, you will learn how to create and setup a DevOps CI/CD Pipeline from Visual Studio Team Services from scratch.

To read the next part of the article, please visit – Azure DevOps CI CD Pipeline using Visual Studio Team Services – Part 2

A brief objective of this article is mentioned as follows:-

  1. Create CI Build Definition
  2. Create CD Release Definition
  3. Create WebApp on Azure
  4. Trigger automated CI build when source code is checked in VSTS repository
  5. Trigger automated CD release after source code check-in and deploy to Azure WebApp

Detailed description of each step with screenshots are provided which will lead you to easily create and configure your CI/CD pipeline.


  1. Access to source code repository in VSTS
  2. Permissions to create Build and Release definitions
  3. Access to Azure subscription. If not available, Web App can be deployed to On-Premise IIS server also


Continuous Integration (CI) – means triggering an automated build (and possibly running tests) whenever new code is committed to or checked into the team project’s source control repository. This gives immediate feedback that code builds and can be committed/checked-in and can potentially be deployed.

If the source code after check-in fails to build, the CI build will fail and no erroneous code will be deployed on the server. This helps other developers from landing in a situation where latest code is fetched from the repository and source code doesn’t build or compile.

Continuous Deployment (CD) – means starting an automated deployment process whenever a new successful build is available.

CI/CD Pipeline in VSTS

Create Build Definition for CI Pipeline

Step (1) : Open VSTS using https://{youraccount} 

Replace {youraccount} with your VSTS account name.

Step (2) : Navigate to your project by the project’s name and click on ‘Build and Release’. This will open a page with the ‘Build’ option selected by default. You can also open the ‘Build’ option by hovering on ‘Build and Release’ option which will open a drop down menu where you can click on ‘Builds’.

This will open the ‘Builds’ homepage as shown follows.

CI Pipeline Build Home Page

Step (3) : Click ‘+ New’ button to start creating a new build definition.

Under ‘Select a source’,  ‘TFVC’ radio button is selected by default. You can also select from other options available depending upon your source code repository like ‘GIT’, ‘Subversion’, ‘Bitbucket Cloud’ etc. I have left the default option ‘TFVC’ selected as my source code is in TFVC (Team Foundation Version Control).

Under ‘Workspace Mappings’ section, a default server path for your source code to be build is displayed automatically. You can change the ‘Server Path’ depending upon your source code’s branch from which you want to deploy the code by clicking the ‘…’ button which will open a ‘Select Path’ popup to change your source code location/branch.  I have left the sever path to the default populated Server Path.

Finally click the ‘Continue’ button at the bottom of the screen as shown follows.

CI New Build Definition Select Source

Step (4) : Next a template selection screen is displayed. Select ‘Azure Web App’ option as click ‘Apply’ button as shown follows.

Step (5) : In the following screen, a build is created where you are required to enter the configuration information. The fields marked with Red color are the ones that are mandatory and needs to be filled up.

Firstly, the fields under ‘Process’ section marked with red color needs to be filled up.

CI New Build Configure Process

‘Name’ : For this textbox, enter a name of your choice for the build or leave the default name.

‘Agent queue’ : For this drop down list, select either a ‘Hosted’ or ‘Private’ agent queue. I will select a Private agent queue for this article.

‘Solution’ : Click the ‘…’ button. This will open a ‘Select path’ popup where you can navigate to the specific branch in source control and select the solution file (.sln) for your project.

‘Azure Subscription’ : For this drop down list, select your appropriate Azure subscription.

‘App service name’ : For this text box, first go to Azure Portal and create an App Service. Enter the name of the App service created by you here. After the new Azure WebApp has been created, it will look as follows. As the app is empty and nothing has been published to it, a default Azure welcome screen will be displayed.

New Azure Web App

After completing the required settings, the screen looks as follows.

NOTE : I have provided the Azure ‘App service name’ here as this is a mandatory field. Under Phase 1 section, disable or delete the ‘Azure App Service Deploy’ task as the deployment will be done using CD pipeline and not CI pipeline. I have disabled this step as can be seen in above screenshot.
CI New Build Process ConfiguredStep (6) : Next, click on ‘Phase 1’ section.

First setting is for NuGet Tool Installer. Leave the default populated NuGet version to 4.4.1 as shown follows.

CI Build Nuget Tool Installer

In the next ‘NuGet’ section, for the NuGet restore option, leave ‘Command’ to default value ‘restore’.

Under ‘Path to solution, packages.config, or project.json’, select the ‘…’ button. This will open ‘Select path’ popup window where you can select your solution file path, packages.config or project.json in the appropriate branch located in source control. I have selected the .sln file as shown follows.

CI Build NuGet Restore

Step (7) : Next click the ‘Visual Studio Build’ option.

Display Name : I have changes the Display Name to remove the default appended solution file path.

Solution : Select the path of your solution file as done in previous step (6).

Version : Leave this to the default populated option – ‘Latest’

MSBuild Arguments : Change this as below. Using the following option created a web package named ‘SOPWebPackage’ in the build’s stating directory. $(build.stagingDirectory) pointing to the build’s staging directory.

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:SkipInvalidConfigurations=true /p:PackageLocation=”$(build.stagingDirectory)/SOPWebPackage

Platform : Leave this to the default value $(BuildPlatform). If you wan to see the default value of this variable or change this to variable’s value to something else, click on the ‘Variables’ tab. Currently, the selected tab is ‘Tasks’ tab. ‘Variables’ tab is adjacent to the ‘Tasks’ tab.

Leave all other options to the defaults. The screen from this step looks as follows.

CI Build Solution

Step (8) : Leave all other steps to the defaults and jump to ‘Publish Build Artifacts’ section.

In the ‘Artifact publish location’ from the drop down list, select the option named – ‘A file share’. In the next text box that appears by the name ‘File share path’, enter a UNC file share path. I have entered a UNC file share path for my build server where I want the build artifacts to be dropped and picked up by the CD pipeline.

Also, I have checked the ‘Parallel copy’ option so that the files are copied to the artifact drop location in parallel using multiple threads to increase throughput.

I have left the ‘Parallel count’ to the default value of 8. The max degree of parallelism depends on the CPU cores of your build server machine.

Leave all other options to the defaults. The scree from this step looks as follows.

CI Publish Build Artifacts

Additional tasks like executing Powershell script or any other activity as needed can be achieved by adding and configuring additional tasks to the pahse, by clicking ‘+’ icon next to ‘Phase 1’ phase.

Step (9) : Currently, ‘Tasks’ tab is selected. Navigate and click on the ‘Triggers’ tab which will open the screen as shown follows.

CI Build Triggers

Under the ‘Continuous Integration’ option, check the ‘Enable continuous integration’ checkbox. Leave other options to the defaults.

CI Build Enable CI

Next go to the ‘Gated check-in’ section and click on the build name and select the ‘Enable gated check-in’ checkbox. Leave other options to the defaults. Finally, expand the ‘Save & queue’ drop down options and click ‘Save’ button to save all your changes.

CI Build Enable Gated Checkin

This completes creation of the CI Pipeline.

Create Release Definition for CD Pipeline

Step (1) : Click ‘Releases’ tab next to the ‘Builds’ tab. Click ‘+’ drop down list and select option ‘Create release definition’ as shown follows.

CD Create Release Definition


Step (2) : In the next screen that appears, under ‘Select a Template’ option, choose ‘Azure App Service Deployment’ option as shown follows. Finally click ‘Apply’ button to move to the next screen.

CD Release Select Template

Step (3) : In this screen as shown follows, under the ‘Artifacts’ section, click ‘+ Add artifact’ button.

CD Release Add Artifact

Step (4) : Next you will be presented with ‘Add Artifact’ section from where ‘Source Type’ – ‘Build’ is selected by default. Also the project is selected in the ‘Project’ drop down list and the selected item is the current project in source control where you are creating the CI/CD pipeline.

Only required setting is Source (Build definition) which is required to be selected from the drop down list. On expanding this drop down list, all the build created under this project will be displayed. Select the appropriate CI Pipeline build created previously.

CD Release Add Artifact Source

After selecting the Source (build definition), change Source alias name if you want the alias name as per your choice and finally click ‘Add’ button. Screen settings before clicking ‘Add’ button and making the required settings on this page are shown as follows.

CD Release Add Artifact Source Build

After the artifact is added, you can change the environment name to something like DEV, TEST, PRE-PROD or PROD depending on your choice by clicking on the ‘Environment 1’ step under ‘Environments’ section. Name this environment to DEV.

CD Release Environment

Step (5) : Next under the Environment, click on “1 phase, 1 task” link inside the environment box which will open the next screen as shown follows.

CD Release Environment Configuration

Under selected DEV environment, select Azure subscription and click ‘Authorize’. Then select App service name and finally click Save button as shown follows.

CD Release Environment Configuration Settings

Step (6) : Next click on ‘Deploy Azure App Service’ step. Only change needed to be done in this step is specifying the ‘Package or folder’ path.

\\D………..BUILD\drops\$(System.TeamProject)\$(Build.DefinitionName)\$(Build.BuildNumber) – [A]

Copy the ‘Publish build artifacts’ path specified from Step (8) of CI pipeline while configuring the CI build. In the same step, ‘artifact name’ was provided as ‘drop’ – [B]

In Step (7) of CI pipeline under ‘Build solution’ task, under ‘MSBuild Arguments’, copy the web package name provided which is this case is ‘SOPWebPackage’ – [C]

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:SkipInvalidConfigurations=true /p:PackageLocation=”$(build.stagingDirectory)/SOPWebPackage

MSBuild packages build output in a zip file with solution file name which in this case is – [D]

Combining the above sections [A], [B], [C], [D] makes ‘Package or folder’ location’s UNC file share path as follows :


Leave the other settings to the defaults. After this, click the ‘Save’ button to save all your changes.

Additional tasks like executing PowerShell script or any other activity as needed can be achieved by adding and configuring additional tasks to the phase, by clicking ‘+’ icon next to ‘Run on agent’ phase.

Step (7) : Click on the thunderbolt icon on top of the build artifact name and move the ‘continuous deployment trigger’ slider to the right to enable it. Finally click the save button to save the changes.

CD Release Enable CD Trigger

You can add more environments to the CD Pipeline like TEST, PRE-PROD, PROD etc. I have kept a single DEV environment to keep this article from getting too long.

[NOTE] : If you have multiple environments, the same CI Pipeline build artifacts will be published to the different environments with the same web.config variable values for DEV, TEST, PRE-PROD and PROD environments. To change the web.config variable values automatically by the CD pipeline depending upon the environment, firstly web.config transformations need to be setup in the Visual Studio solution’s source code. The variable values can be tokenized and a ‘Replace Tokenstask can be added to the CD Pipeline to change the web.config variable values.  Different environments can be linked one after the other in the pipeline so that code can be published sequentially to different environments. Also you can set approver for any particular environment to make sure that the CD pipleline deploys the code to that environment only after the approver approves it.

Again, I have not explained all these here in this article. This article has already gone too long as I have explained each and every step in details with multiple screenshots.

This completes creation of the CD Pipeline.

Execute CI/CD Pipeline

When source code is committed, the CI Gated Check-in build will fire automatically. If there is some error in code which can break the solution from building, the change-set will be rejected and the changes won’t be committed.

If the source code is committed successfully, after completion of the CI pipeline, the CD pipeline will be triggered automatically which will deploy all the build artifacts from the CI pipeline. So, if the check-in is successful, the source code will be automatically deployed to the Azure Web App.

If you don’t want to deploy the changes with every check-in and instead want to fire the build manually to activate the CI pipeline, you should not enable the Gated check-in trigger in the CI pipeline which was enabled in Step (9). You can also disable the Gated check-in trigger any time you want to.

Also if the Gated check-in trigger is enabled, you can still activate the CI pipeline manually so that you don’t need to check-in the source code to activate the CI pipeline.

Now, I will show how to activate the CI pipeline manually. First go to the CI pipeline and open the CI build and then click the ‘Queue’ button to queue a new build manually.

CI Queue New Build

After the CI build completes, the success or failure status is displayed. In this case, the CI build was successfully completed as shown follows.

CI Build Succeeded


Next, navigate to the releases tab where you can see the history of all CD pipeline release definitions.

CD All Release Definitions

Click on the latest release definition which will display it’s status as shown follows.

CD Release Succeeded

In this case the CD Pipeline release has completed successfully. Currently the ‘Summary’ tab is active. If you open the ‘Logs’ tab, a detailed log of every step can be seen.

CD Release Logs

After the CD pipeline completes successfully, navigate to the Azure Web App as shown follows.

Azure Web App

This concludes the article – ‘CI/CD Pipeline using Visual Studio Team Services’. To read the next part of the article, please visit – Azure DevOps CI CD Pipeline using Visual Studio Team Services – Part 2

I hope you liked this article. If you have any comments, questions or suggestions, please post them using the comments section below this article. I will try to respond at my earliest or somebody else reading the article and your comment will try to respond.

Please subscribe to my blog via email to get updates on the latest articles and also share this article over social networks like Facebook, Twitter etc.

Share this

Leave a Reply