The Goal: Merge-Only Deployments

A common and sensible continuous delivery workflow looks like this:

1. A developer branches off master, makes changes, and opens a pull request.
2. A peer reviews and merges the PR into master.
3. An automation system detects the merge and:
   1. Increments a version number stored in a file in the repository.
   2. Commits the version bump back to master.
   3. Runs the build.
   4. Deploys the artifact.

This is straightforward in concept, but wiring it up correctly between VSTS (now called Azure DevOps) and Jenkins introduces several non-obvious pitfalls.

The VSTS Service Hook Problem

VSTS provides Service Hooks that can trigger external systems like Jenkins. The three hooks most relevant to this workflow are:

1. Build completed – fires when a VSTS build finishes.
2. Code pushed – fires on any push to a repository.
3. Pull request merge commit created – fires when activity occurs on a pull request.

The third option sounds ideal, but it does not fire only on merge. It fires whenever a new commit is pushed to the source branch of an open pull request as well. This means every intermediate commit a developer pushes while their PR is still open will trigger the Jenkins job—causing redundant and potentially broken deployments.

The “Code Pushed” Infinite Loop

Switching to the Code pushed hook seems like it could work if you filter by branch, but it introduces a different problem: the Jenkins pipeline itself commits back to master when it bumps the version number. That commit triggers the hook again, which kicks off another Jenkins run, creating an infinite loop of builds and deployments.

The Jenkins Poll SCM Limitation

Jenkins has a built-in Poll SCM trigger that checks the repository on a cron-like schedule. However, when using it with a multi-branch or remotely-hosted repository, it can be unclear which repository and branch the job will poll without explicitly configuring the Git plugin settings in the job. Polling also introduces latency and does not cleanly distinguish between a version-bump commit (made by Jenkins itself) and a genuine developer merge.

Recommended Solutions

Option 1: Filter Triggers Using a Commit Message Convention

Tag the version-bump commit with a recognisable message such as [ci skip] or a custom prefix like [version bump]. In your Jenkins pipeline or job script, inspect the commit message at the start of the build and abort early if the trigger commit matches that pattern.

// Example Jenkinsfile guard
def commitMsg = sh(returnStdout: true, script: 'git log -1 --pretty=%B').trim()
if (commitMsg.contains('[version bump]')) {
    currentBuild.result = 'ABORTED'
    error('Skipping build triggered by version bump commit.')
}

This breaks the loop without requiring changes to the VSTS hook configuration.

Option 2: Use a Dedicated Service Account for Version Commits

Configure Jenkins to push version-bump commits using a dedicated service account or bot user. In the VSTS Code pushed Service Hook, set the filter to exclude pushes made by that account. This prevents Jenkins-originated commits from re-triggering the pipeline without requiring any in-pipeline logic.

Option 3: Use the VSTS REST API to Verify PR Status Before Proceeding

When the Pull request merge commit created hook fires, VSTS passes contextual payload data to Jenkins. In the Jenkins job, add an early step that calls the VSTS REST API to confirm the PR status is completed (i.e., actually merged) before proceeding with the build and deployment stages. If the PR is still active, the job exits cleanly without deploying.

Option 4: Move Version Bumping Out of the Jenkins Pipeline

Consider separating version management from the build trigger entirely. Options include:

• Use a VSTS build task or release pipeline step to handle the version bump after the Jenkins build succeeds, not before.
• Derive the version number from the Git tag or commit count at build time rather than writing it back to the repository, eliminating the need for a post-merge commit entirely.
• Use a tool like Semantic Versioning with GitVersion or a similar utility that reads the version from Git history without modifying it.

Option 5: Replace Service Hooks with Jenkins Multibranch Pipeline and VSTS Git Plugin

The Jenkins Git plugin supports polling a specific VSTS Git repository and branch. In a Multibranch Pipeline job, configure the branch source to point at your VSTS repository and set the branch filter to master only. This ensures:

• Only changes to master are acted upon.
• Feature branches are ignored unless you explicitly add them.
• You can combine polling with a short interval or a VSTS webhook pointing at the Jenkins Git endpoint to reduce latency.

To prevent version-bump commits from re-triggering, combine this with Option 1 (commit message filtering).

Recommended Architecture Summary

Key Takeaways

• The VSTS Pull request merge commit created hook fires on all PR-related commits, not only on the merge itself—do not rely on it alone to gate deployments.
• Any pipeline that commits back to the monitored branch must include a mechanism to prevent retriggering.
• Eliminating the version-bump commit (by deriving version from Git metadata) is the cleanest long-term solution and removes an entire class of trigger-loop problems.
• VSTS is now called Azure DevOps; most of these concepts and hook types carry over to the modern platform.

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

1. Create a new project in VSTS with Git version control
2. Push an existing local project to the new Git repository from Visual Studio
3. Configure a Build Definition in VSTS with Continuous Integration enabled
4. Create an Azure Web App as the deployment target
5. Configure a Release Definition in VSTS with Continuous Deployment to Azure App Service
6. 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:

1. Created a new VSTS project with Git version control
2. Pushed an existing ASP.NET Web API project to the VSTS Git repository from Visual Studio
3. Configured a Build Definition with the ASP.NET template and Continuous Integration enabled
4. Provisioned an Azure Web App as the deployment target
5. Configured a Release Definition using the Azure App Service Deployment template with Continuous Deployment enabled
6. 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.