Builds Are the Heartbeat of the DevOps Release Cadence
When you look at the health of a project and ask yourself if you’ve got a healthy agile project, a good indicator to measure this is the build cadence. You can draw a rough analogy that the number of builds is similar to the pulse of a project. A regular “heartbeat” indicates a good, healthy project, but a sporadic “heartbeat” is going to uncover an anemic project and may indicate the need for some concern about the overall health of the project.
Slow and Sporadic Builds
If you find that your heartbeat is sporadic, slow or lethargic, it’s a good bet that at least part of your pipeline is not fully automated and that there are manual builds steps slowing you down. It may also indicate that your developers are checking code in on a very infrequent basis. If this is the case, it means that your project will be missing out on some of the basic build metrics and a lot of automated metrics surrounding build quality.
A slow heartbeat will in turn will lead to slower feedback cycles, you’ll see merge debt piling up, and often your deployments will become riskier, leading to deployments being moved to weekends or after-hours events in order to reduce deployment risk.
This might also indicate that you haven’t fully captured all the automation needed for your build and release pipelines and that there are unseen manual steps that will need to be accounted for each time you release a build.
Rapid, Consistent Builds
A regular build cadence indicates you have a healthy, strong project with a solid heartbeat.
If you have multiple builds per day, that’s a good indicator that you have a healthy project. Developers are checking code in frequently and receiving good feedback from your various code scanning tools like sonarQube that will help guide them into producing quality code.
You are also able to rapidly run a CI build and run through many testing cycles and unit tests, increasing confidence in the quality of your code for the project. Small changes to the source code can be quickly tested and defects can be isolated to these small changes to determine the root cause if there are any breaking changes.
Additional Metrics
Once you’ve got a handle on your project heartbeat, there are additional metrics that will become important as you take your project’s pulse:
Build Length
The build takes longer and longer, it may not be a bad thing, but if you are finding that a build takes 15 minutes to complete, it means each gated check-in turns into an enforced coffee-break for the developer performing the check-in. This is turn could lead to fewer check-ins by the development team if it takes an inordinate amount of time to perform these check-ins.
If you find that the CI build it taking a longer, it may be time to look at breaking out the CI builds for your modules up into smaller, more specific CI builds per module and push some of the larger time-sucking builds to nightly builds and integration testing.
Build Fails
If a build is failing due to quality gates or unit tests, this may indicate that developers are committing code that is not yet ready to be merged, or that you are having consistent quality problems with a specific developer.
Number of Commits per Developer
While your project heartbeat might be strong, individual developers may end up with infrequent check-ins, leading to an accumulation of merge debt for when they do finally perform a check-in, so keep an eye not only on the overall heartbeat, but individual contributors as well.
Rogue Commits
Each commit should be tied back to a work item that adds business value (backlog, epic, feature). Each commit should be tied back to a business value or else it becomes difficult to measure the flow of business value as the project progresses.
Summary
CI Build Cadence is a good rough indicator of your project’s overall health, but needs to be considered within the confines of the project’s overall progress. Multiple builds per day triggered by various developer check-ins can indicate that you have a healthy project. But long periods between code check-ins may indicate an anemic project that is accumulating technical merge debt leading to problems with integrations in the future.
