Gated Check-ins in Visual Studio Team Services using TFSVC and Git

A continuous integration build ensures that the code within a source control repository can be compiled successfully after a commit. It is defined as:

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

Where as CI builds occur after a commit has been merged into the repository, a gated check-in is a "pessimistic" process that would treat a commit as completed only if the result of it being merged with the repository is a successful build.

In this post I will try my hand in setting up a gated check-in using Visual Studio Team Services (VSTS). I will start off with TFSVC as the underlying version control system and then replicate the same functionality using Git.

Configuring a Gated Check-In Using TFSVC

Prerequisite: A repository already exists in the remote server with project code checked-in. I will be using one of my demo CRM projects.

  1. Define the steps for the build that would act as the verification build.

    Verification Build

  2. Navigate to the Triggers tab within the build definition and enabling the Gated Check-In trigger.

    Gated Check-In

  1. Leave the Run continuous integration triggers for committed changes unchecked. If a CI build has been configured and this option was checked then an additional CI build would run after a successful gated check-in build.

Testing Out the Process

  1. Make a change to the code that causes an compilation error.
  2. Check-in this code into the version control. Upon clicking the Check In button within Visual Studio, the following warning dialog appears indicating that the new check-in would be stored as a shelveset until its successful completion:

    Gated Check-In Warning

  3. Uncheck the Preserve my pending changes locally option and click on the Build Changes button to kick off the build.

  4. Next, navigate to builds definition folder and confirm that the verification build was in fact triggered and that it failed as expected.

    Failed Gated Build

  5. Since we did not opt-in to preserve our check-ins locally, let's retrieve it from the generated shelveset. Back in Visual Studio, navigate to theTeam Explorer window and from the Actions menu click the Find Shelvesets

    Failed Gated Build

  6. Select the last shelveset that failed the build - it would be prefixed with Gated_.

    Shelvesets Assigned

  7. Fix the compilation errors we introduced previously and check in the changes.

    Check-in Corrections

  8. Verify that the new check in and resultant gated-build is successful.

    Successful Gated Build

  9. Now that the check-in has been merged, get the latest version of the code using Visual Studio.

Configuring a Gated Check-In Using Git

Branch Policies are used to implement gated check-ins in git. It is a feature in VSTS that provides rules to govern the activity within a branch and ensure the code quality and change management standards are followed.

There are many policies available but I am interested only in the ones related to when a pull request is made.

Given the way that git operates, it cannot be configured to have a gated check-in against every commit as we did with TFSVC. Instead the policy would be enforced during the pull requests between the topic branch to the master branch.

The following steps describe the process of setting up a gated check-in on the master branch:

Prerequisite: A repository already exists in the remote server with project code checked-in. I will be using one of my demo CRM projects.

  1. Start off by defining a build that would act as the verification.

    Verification Build

  2. Navigate to the repository.

  3. Click on the Branches menu.
  4. Click on the ellipsis against the master branch and on the menu and select Branch Policies.

    Update Branch

  5. Under the Automatically build pull requests menu check the When team members create or update a pull request into the master branch, queue this build: option.

  6. Then select the build that you want to use to perform the verification.

    Branch Policies

  7. Click Save Changes button to confirm the changes.

Testing out the Policy

Now let's test our branch policy:

  1. On the development machine, create a new local branch called development.
  2. Commit a change that causes a compilation error.
  3. Push the branch and changes to the remote repository.

    Development Branch

  4. Next, log into VSTS and navigate to the Branches menu.

  5. Click on the ellipsis against the development branch to open up the context menu.
  6. Select the New pull request option.

    New pull request

  7. Provide a meaningful Title and Description and click on the Create button.

    New pull request

  8. Confirm that a new verification build has been queued for the pull request.

    Verification Build

  9. Confirm that this build failed.

    Confirm Build Failure

  10. Now let's fix the code, commit and push the change in to the repository.

    Fix the build

  11. Verify that the build policy has detected the new commit and automatically associated it with the pull request.

  12. Confirm that a new build was triggered as a result and that its successful. The successful build completes the pull request.

    Complete Pull Request


comments powered by Disqus