Gated check in

A gated check-in is a software integration pattern used to avoid breaking a build. It triggers an automated build before code is checked in, if the build fails, it is not checked in until all issues are fixed, otherwise, it is merged to the main branch.

Table of contents.

1. Introduction.
2. How it works.
3. Reasons for gated check-ins.
4. Issues with gated check-ins.
5. Summary.
6. References.

Introduction.

A gated check-in also referred to as gated commit or pre-tested commit is a commit with a condition. It triggers an automated build before code is checked into the main branch. The condition is that if the build fails, the code is not checked in until errors have been fixed.

This reduces the chances of breaking a build by restricting developers from checking in code that is broken into the source control system. That is, when a check-in is initiated by a developer, it only checks in the code if the build is successful otherwise it is rejected until all errors are resolved.

Note that this does not prevent garbage code, just code that does not compile.

This pattern of integration is usually supported by a continuous integration-CI server. For a developer to perform a gated commit, he/she must request it from a CI server before committing the changes to the main branch.

How it works.

If we want to check something in, it has to be built in the branch it was committed to as if the commit happened.

Behind the scenes, the commit is turned into a shelveset with a pending build request.

The shelveset sits until a build agent that will process it is available.
Once a build agent is available, it unshelves the branch as a full commit.
Now assuming a build fails, the shelveset will remain so that we can fix any bugs or issues. In the meantime, we can commit it to pending changes in a development branch although we will be notified to build it first.

We can decide to wait for it to build or undo pending changes, if it builds successfully, we will have whatever we committed in the gated check-in. Otherwise, if the build fails we can recall the shelveset, fix errors and issues, and try to build again.

Reasons for gated check-ins.

We use gated check-in when we want to prevent code from being merged to the main branch automatically.

Other reasons include;

• To correlate with linked work items. This ensures data is stored and thus one can track and audit changes.
• To make sure CI/CD builds are successful before merging to critical code branches. As long as the build based on a newly checked-in code passes, it is considered safe to merge it.
• To allow us to review code using pull requests which only require a limited number of reviewers. Peer reviews allow collaboration in logical aspects of the application and implementation of best coding practices.

Issues with gated check-ins.

In some cases, we may find that gated check-ins cause issues. One such issue is that gated check-ins result in more time being needed for build since a gated check-in is based on a successful build and if there are errors then the build is queued up.

The second problem is that developers adopt a workflow that includes local testing instead of using an automated CI/CD process and hence frees up the build servers and thus chances of jobs being backed up lessen.

Summary.

By using gated check-ins, we are assured that the code being checked-in is safe for merging with the critical release branches.

In general, gated check-ins promote good and safe development practices within a team. With this article at OpenGenus, you must have the complete idea of Gated check-in build / gated commit.