This article is based on a guide originally published on C# Corner. It covers the end-to-end process of setting up Continuous Integration and Continuous Deployment (CI/CD) for an ASP.NET Web API application using Visual Studio Team Services (VSTS) and Azure App Service.
Introduction
Visual Studio Team Services (VSTS) — now rebranded as Azure DevOps — lets you configure a project so that every code commit automatically triggers a build and, on success, deploys the updated application to Azure App Service. This guide walks through that complete setup for an ASP.NET Web API application, from creating a Git repository in VSTS through to verifying a live deployment in Azure.
Prerequisites
- Visual Studio 2015 or later (Visual Studio 2017 used in this example)
- An active Azure subscription
- A Visual Studio Team Services (VSTS) account
- An existing ASP.NET Web API project on your local machine
Overview of Steps
- Create a new project in VSTS with Git version control
- Push an existing local project to the new Git repository from Visual Studio
- Configure a Build Definition in VSTS with Continuous Integration enabled
- Create an Azure Web App as the deployment target
- Configure a Release Definition in VSTS with Continuous Deployment to Azure App Service
- Commit a change and verify the automated build and deployment
Step 1: Create a New Project in VSTS with Git Version Control
Sign in to your VSTS account and click New Project on the home page.
In the Create new project dialog:
- Enter a project name (e.g., KendoGrid)
- Set Version control to Git
- Choose a Work item process (e.g., Agile)
- Click Create
You can use either Git or Team Foundation Version Control (TFVC). Git is the recommended choice for most modern workflows due to its distributed nature and broad tooling support.
Step 2: Push an Existing Project to the VSTS Git Repository
Open your existing ASP.NET Web API project in Visual Studio (File > Open). Once the project is loaded, look at the bottom-right status bar for the Add to Source Control option and click it.
The Team Explorer window opens and presents two options:
- Push to Visual Studio Team Services — creates a new repository on your VSTS account automatically
- Push to Remote Repository — connects to the Git repository you already created in Step 1
Because you already created the repository in VSTS, choose Push to Remote Repository.
Click Publish Git Repo, paste the remote Git URL from your VSTS project, and click Publish.
After a successful push, you can browse to the Code tab of your VSTS project to confirm that all files are present in the repository.
Step 3: Configure a Build Definition in VSTS
From the repository page in VSTS, click Set up build in the top-right corner.
The Create new build definition wizard opens. Select the ASP.NET (Preview) template, which pre-populates the build steps appropriate for an ASP.NET project (NuGet restore, build, test, publish).
On the settings screen, check Continuous Integration. This tells VSTS to trigger a build automatically on every commit pushed to the repository. Click Create.
VSTS will pre-load all required build tasks. Review the steps (NuGet restore, MSBuild, VSTest, Publish Build Artifacts) and adjust only if your project requires non-default settings. When finished, click Save.
Step 4: Create an Azure Web App as the Deployment Target
Log in to the Azure Portal. Create a new Web App by navigating to New > Web + Mobile > Web App. Complete the required fields (App name, Resource Group, App Service Plan) and click Create.

Once provisioned, the overview blade shows the default URL for your new App Service (e.g., https://<your-app-name>.azurewebsites.net). Keep this URL handy — you’ll need it when configuring the release definition.
Step 5: Configure a Release Definition in VSTS
In VSTS, navigate to Build & Release > Releases and click New Definition.

From the list of deployment templates, select Azure App Service Deployment and click Next.
On the next screen:
- Select your Project and Build Definition from the dropdowns
- Check Continuous Deployment to trigger a release automatically after every successful build
- Click Create
In the release definition editor:
- VSTS automatically lists the Azure subscriptions associated with your login. Select the appropriate subscription.
- Click Authorize to grant VSTS access to your Azure resources.
- Select the App Service Name you created in Step 4 from the dropdown.
- Enter the App Service URL in the App Service URL field.
- Click Save.
Step 6: Commit a Change and Verify the Pipeline
With the CI/CD pipeline in place, any commit pushed to the VSTS Git repository will automatically trigger a build. If the build succeeds, a release is triggered automatically and the application is deployed to Azure App Service.
To test this, make a small change to your application (for example, update a page title in an HTML file) and commit and sync the change from Visual Studio’s Team Explorer.

Navigate to Build & Release > Builds in VSTS. You should see a build queued or in progress. VSTS also sends a build status notification email.
Build in Progress
Build Succeeded
Once the build completes, the release is triggered automatically. Navigate to Build & Release > Releases to confirm the deployment status.
With a successful deployment, open the Azure Web App URL in your browser to confirm the changes are live.
Summary
This walkthrough covered the complete CI/CD setup from code to cloud using VSTS and Azure App Service:
- Created a new VSTS project with Git version control
- Pushed an existing ASP.NET Web API project to the VSTS Git repository from Visual Studio
- Configured a Build Definition with the ASP.NET template and Continuous Integration enabled
- Provisioned an Azure Web App as the deployment target
- Configured a Release Definition using the Azure App Service Deployment template with Continuous Deployment enabled
- Verified that a code commit triggers an automated build and deployment end-to-end
Note: Visual Studio Team Services (VSTS) was rebranded to Azure DevOps in September 2018. The underlying concepts — pipelines, build definitions, release definitions — remain the same, though the UI and terminology have evolved. If you are using Azure DevOps today, the equivalent features are found under Pipelines > Builds and Pipelines > Releases.