--- title: "Build Bullet #4: Rolling Builds and the Plane of Confidence" url: "https://osherove.com/blog/2012/11/27/build-bullet-4-rolling-builds-and-the-plane-of-confidence.md" canonical: "https://osherove.com/blog/2012/11/27/build-bullet-4-rolling-builds-and-the-plane-of-confidence.html" published: "2012-11-27T13:42:46" updated: "2012-11-27T13:42:46" tags: ["Build Bullet"] author: "Roy Osherove" description: "When I check in code I have been working on, I feel: 1. I want to wait for the build result 2. I don’t want to waste time waiting for the build results, doing nothing 3. But I fear doing something in the code until I’m…" 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 Bullet \#4: Rolling Builds and the Plane of Confidence By Roy Osherove November 27, 2012 In [Build Bullet](https://osherove.com/blog/category/build-bullet) **Historical article** · Originally published November 27, 2012; technical details may be outdated. When I check in code I have been working on, I feel: 1.    I want to wait for the build result 2.    I don’t want to waste time waiting for the build results, doing nothing 3.    But I fear doing something in the code until I’m sure I didn’t break anything Supposedly, this is where a CI build configuration comes into place. CI builds are supposed to be as fast as possible so we can get feedback about what we checked in as quickly as possible and get back to work. But the tradeoff is that CI builds also do fewer things so that they can become faster, Thus leaving you with a sense of some risk, even if the build passed. This is why I like to have “**Rolling Builds**”. I like to have builds trigger each other in the Continuous Integration Server: •    A Check-in triggers the CI build •    A successful CI build triggers a nightly build. •    A successful nightly build triggers a deploy to test build. I think of the builds now as single waves crashing on my shoreline. Each build is a slightly bigger wave. Each wave crashing on the shore brings with it a layer of confidence in the code. And because they happen serially, I can choose to just relax and watch the waves of increasing confidence crash on the shore, or I can choose to continue coding right after the first wave of confidence. As I program, the next waves of build results hit the shoreline, and my notification tray tells me what that wave brought with it. Another “green” result wave tells me to go on about my business. A “red” wave tells me to stop and see what happened. But I always wait for at least the first wave to come ashore and tell me what’s going on. I need that little piece of information that tell me “seems legit so far” so I can feel 50@5 good about going back to coding. If my changes were big, I might wait until the next wave to see what to do. So my confidence after check in is not a black or white result. It is a continuous plane of increasing confidence on the code that I am writing, that is topped off when the code is deployed to production. > **Note**: This text is part of a [“Beautiful Builds” Booklet](http://beautifulbuilds.com/) I am working on. ## More in Build Bullet [All posts in Build Bullet](https://osherove.com/blog/category/build-bullet) - Jan 7, 2013 ### [Build Pattern: Shipping Skeleton](https://osherove.com/blog/2013/1/7/build-pattern-shipping-skeleton.html) - Dec 6, 2012 ### [Build Bullet #5– How to make your builds FAST using DRY and SRP Principles](https://osherove.com/blog/2012/12/6/build-bullet-5ndash-how-to-make-your-builds-fast-using-dry-a.html) - Nov 18, 2012 ### [Build Bullet #3– Start Products with an Empty Build and Deploy Pipeline](https://osherove.com/blog/2012/11/18/build-bullet-3ndash-start-products-with-an-empty-build-and-d.html) - Nov 18, 2012 ### [Build Bullets #2–Avoid XML Facing Build Tools](https://osherove.com/blog/2012/11/18/build-bullets-2ndashavoid-xml-facing-build-tools.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/