Rolling Builds and the Plane of Confidence

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 I am working on.