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

15 May 2017 | Visual Studio Team Services | TFSVC | ALM | 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.

   

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

   

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:

   

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.

   

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

   

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

   

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

   

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

   

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.

   

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.

   

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.

   

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.

   

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.

   

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

   

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

   

9. Confirm that this build failed.

   

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

    

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.

    

References

• Continuous integration | ThoughtWorks
• Build definition triggers
• Check in to a folder that is controlled by a gated check-in build process
• Git Branches and Policies in Team Foundation Server 2015 | Visual Studio 2015 Final Release Event | Channel 9
• Gated checkin for Git: Using Branch Policies to run a build in VSTS and TFS – Buck Hodges
• Protect your Git branches with policies | Team Services & TFS

comments powered by Disqus