--- title: "Build Pattern: Gated Commit" url: "https://osherove.com/blog/2013/1/20/build-pattern-gated-commit.md" canonical: "https://osherove.com/blog/2013/1/20/build-pattern-gated-commit.html" published: "2013-01-20T13:31:10" updated: "2013-01-20T13:31:10" tags: ["Build Bullet"] author: "Roy Osherove" description: "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…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Build Pattern: Gated Commit By Roy Osherove January 20, 2013 In [Build Bullet](https://osherove.com/blog/category/build-bullet) **Historical article** · Originally published January 20, 2013; technical details may be outdated. ## 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](http://www.jetbrains.com/teamcity/features/delayed_commit.html)” 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. ## Lessons on this topic - [Single Branch](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/single-branch/) · Beautiful Builds and Continuous Delivery Patterns ## More in Build Bullet [All posts in Build Bullet](https://osherove.com/blog/category/build-bullet) - Feb 7, 2013 ### [Build Pattern: Cumulative Build](https://osherove.com/blog/2013/2/7/build-pattern-adopt-artifacts.html) - Jan 20, 2013 ### [Tests and Builds are Made to be Broken](https://osherove.com/blog/2013/1/20/tests-and-builds-are-made-to-be-broken.html) - Jan 19, 2013 ### [Build Pattern: Extract Script](https://osherove.com/blog/2013/1/19/build-pattern-extract-script.html) - Jan 19, 2013 ### [Build Pattern: Fill In the Blanks](https://osherove.com/blog/2013/1/19/build-pattern-fill-in-the-blanks.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/