Other names:
- Pre-tested commit
- Gated Check-in
- Private Build
- Delayed Commit
Symptoms:
The build keeps breaking for trivial problems.
Problem:
Developers do not know what are the outcomes of committing their source code into the master branch. so they blindly commit and wait to see the results.
Forces:
You want to check in (commit) your changes into the master source control, but you are afraid of breaking one of the immediate build configurations on the CI server. For example, you are not sure if all the tests in the nightly build will pass, and your machine is too slow to run the nightly build locally.
You’d like to make sure, before you commit or merge into the master branch, that your changes won’t break. but this is very time consuming task locally.
Solution:
A gated commit is a process that can be supported by the CI server. It combines several steps, in several variations:
- Developer Requests a gated commit before committing actual changes.
- the CI server gets the current snapshot of files on the developer’s local machine through a local plugin to the text editor, usually. (in TFS this is called “shelving”)
- The CI Server merges the current snapshot with the master source version, as a separate, temporary set of files. this is not being committed to the master branch.
- The CI server then runs the specific build configuration requested by the developer , such as a nightly build, with the current code. this might include compilation, running tests, deployment etc.
- if the build configuration passes, the temporary file set is committed to master.
- if the build configuration fails, the temporary file set is discarded, and the developer is notified of the build failure, without interrupting the main master branch builds.
- Developer now has a log file to go through and see what to fix before checking in.
Examples:
Teamcity provides a “pre-tested commit” feature. Install the teamcity plugin in visual studio, and get a new button that allows you to run the current sources as a pre-tested commit. if it passes, changes are committed to source control.
Side effects:
This can lead to an overall feeling in the team that breaking the build is wrong, and is to be avoided at any cost. This might not be a healthy attitude, since the original purpose of a build process was always to find out problems. You might say that if the build breaks, then the build did it’s job. This culture of “breaking the build is bad, and it’s your fault” can lead to developers hiding their efforts, in an effort not to look stupid in front of their peers. in essence, a private build can lead to moving from a group effort, into individual based comparison system “who breaks the build the most?”.
More problematic: if developers always get the build failing privately, developers will feel they have to solve the build privately. when the build fails publicly, it can trigger help from the rest of the team to solve the problem faster since more brains are involved.