Repo-driven build triggers, the quiet period, and you
If you're thinking "What the heck is the quiet period?", this article is for you
Bamboo is a continuous integration and delivery tool, and part of that continuous word implies to running builds per commit. However, spinning up builds per commit is expensive and time consuming, and knowing that commits often happen in a rushed fast wavy way, it might be more convenient waiting for the blast to end before attempting a build. Though this is all to your team to decide we have a feature in Bamboo that makes this silent wait possible. Bamboo's "quiet period" feature allows aggregating multiple commits per build, so reduces the costs and helps teams get faster feedback. It's an optional setting on each repository connected to Bamboo. After a commit has been made to the repository, the quiet period (if enabled) tells Bamboo how long to wait before kicking off the build.
Navigate to the Advanced Options in the Linked Repositories configuration screen to find this feature. Here’s what it looks like:
Fun Fact! The quiet period was originally invented to cater for the fact that CVS commits are non-atomic. In general, however, it can be used to coalesce multiple commits into a single build regardless of what version control system you’re using.
Why would you want to do that?
The quiet period comes into play if the repository is configured to notify Bamboo when commits are made. If not, and Bamboo is polling the repository for changes, then the quiet period is effectively moot because the polling period acts as a way to coalesce multiple commits into a single build (as the following diagram shows).
Note: The diagram is not to scale (imagine the build time is substantially larger in real life). This is one of the rare occasions that polling could be considered useful.
The main use case for the quiet period is when you have a long build and you don’t want to deprive other developers who commit changes just moments after yours from boarding the same train (so to speak). Generally you want to avoid long builds, but that’s not always possible. If a build takes a long time (say an hour) and someone commits just after you then they would have to wait almost two hours for their build result. If only the train would wait a few minutes to allow a few people to get on board before starting!
What about parallel builds of the same plan?
Bamboo’s default setting is to allow only one concurrent build per plan. It’s possible to allow multiple concurrent builds of a plan, but doing so in this instance only kicks the can down the road. For example, if you set the build concurrency to two then it will be third commit that will have to wait for one of those first two builds to finish before it can start. As mentioned earlier, though we're not suggesting questioning the continuous part of continuous integration, you can turn on this feature and save some of your team's time and energy resources!
When do you use the quiet period?
Consider turning on the quiet period for builds that run long (say, over an hour) and are triggered by a call from the repo (as opposed to builds that poll the repo at intervals). The quiet period will hold the build at the station a little bit so that a few more commits can get on the train. Since build duration is the largest value here (remember the diagram is not to scale), it is only a small delay for the first committer but a large time saving for the second and third. So overall, it’s a good thing.
Following shows how only one build is triggered for the three commits:
Note that setting the quiet period should not be confused with attempts to throttle the server in order to keep the build queue small. Use the concurrent builds setting at the global level, and also overridable at the plan level for that purpose.
The quiet period is more important now than ever before!
Prior to Bamboo 5.6, configuring repos to pro-actively call out to Bamboo when a commit is received and trigger a build was, frankly, a bit of a pain. And since it is most relevant in the context of repo-driven build triggers, the quiet period didn’t get a lot of usage. Now, however, repo-driven build triggers are dead simple when you connect Bamboo to Bitbucket. The notifications for Bamboo are automatically configured as soon as you create your repo in Bitbucket (or, in the case of existing Bitbucket repos, as soon as you link Bamboo and Bitbucket on the back end). So all you have to do is select this as the trigger type in your build plans. Triggering builds this way is far more efficient than spending Bamboo’s CPU cycles on polling repos every few minutes – this is especially true the more repos and build plans you have! So for both these reasons, the quiet period is making some noise (if you will).
Hopefully we’ve inspired you to try out the repo-driven triggers and the quiet period on some of your longer-running builds. Just one small way to achieve an easier, faster, more scalable CD practice!
on a related note...
When did that get in our repo?
It can seem impossible to find when specific strings of text were introduced. While the Git blame command does great for showing you the most recent modification of the line, how do we find the earliest? Check out our tip.
Put it into practice
Continuous delivery from code to customer
Bamboo is a continuous delivery tool that ties automated builds, tests and releases together in a single workflow. Take the tour to learn more.