Build is the step in the SAFe for DevOps Health Radar where committed code is continuously integrated, tested, and turned into a deployable artifact with built-in quality. In this video, I walk through what the Build step involves, why continuous integration matters, and how techniques like gated commits and static security analysis help you maintain quality at speed.
From Committed Code to Deployable Artifact#
Before we reach the Build step, we have gone through the earlier stages of the SAFe for DevOps Health Radar. It starts with ideas from the customer or business. We formulate hypotheses, collaborate and research to identify the real customer need, define the minimal architecture, and synthesize a vision with a roadmap and features. In the Develop step, we break features into user stories and implement them.
Once the code is committed, the Build step begins. The goal is to take the committed code, reintegrate it with the rest of the codebase, run tests and code analysis, and produce a deployable artifact with built-in quality.
Continuous Integration#
Every commit to version control should trigger an automated process. The continuous integration server takes the newly committed code, reintegrates it with the rest of the codebase, and then executes a series of checks:
- Build/Compile the code together with the rest of the codebase
- Run unit tests to verify component-level correctness
- Execute code analysis to check code quality
- Run security code analysis (static analysis) to detect vulnerabilities
The key principle is fast feedback. Developers need to know as quickly as possible whether their committed code was good or whether it introduced problems.
The Problem with Long-Lived Branches#
One of the most common sources of problems is long-lived branches. Teams often work on a branch for an entire sprint and then try to reintegrate everything on the last day. This approach causes a lot of issues and is rarely successful.
The solution is to merge back as fast as possible so that there is always one branch containing the current version of the software. Whether the team follows trunk-based development or Git Flow is their decision. The important thing is that code gets merged back quickly so that continuous integration can do its job.
Broken Builds and Gated Commits#
A broken build affects not only your own team but also other teams working on the same codebase. That is why a broken build always has the highest priority and needs to be fixed immediately.
One strategy to avoid broken builds altogether is the gated commit. With gated commits, the build server takes your newly committed code and reintegrates it with the rest of the codebase without committing it to version control yet. It then builds the code, runs the unit tests, executes the code analysis, and performs the security analysis. Only if everything passes does the build server commit your code into version control. If something fails, your code comes back to you with a notification. This technique prevents defects from ever entering the main codebase.
Application Security#
Static security checks are an essential part of the Build step. Under the umbrella of application security, we statically analyse not only our own source code but also the packages and libraries we depend on. A vulnerability in any library in the dependency chain can become a vulnerability in our application. Automated security scanning tools catch these issues early, before the artifact reaches production.
The Maturity Levels#
The SAFe DevOps Health Radar provides a maturity assessment for the Build step:
- Sit: Builds are run fewer than once per iteration or sprint and are completely manual.
- Crawl: Builds are run once per iteration or sprint and are partially automated. Dev branches are open for months or more and builds break often.
- Walk: Automated builds run once a day. Broken builds are corrected in two to four hours. Manual unit tests are run against each build. Dev branches are open two to four weeks.
- Run: Builds run automatically upon code commit. Broken builds are corrected within one hour. Automated unit tests are run against each build. Dev branches are merged to trunk every iteration.
- Fly: Builds run on every commit. Builds include static code analysis and security analysis. Gated commits prevent defects from entering version control. Dev branches are merged to trunk on every commit.
Key Takeaways#
- The goal of Build is a deployable artifact with built-in quality. Committed code must be reintegrated, compiled, tested, and analysed before it becomes an artifact.
- Continuous integration is essential. Every commit should trigger a build, unit tests, code analysis, and security analysis automatically.
- Avoid long-lived branches. Merge back to the main branch as quickly as possible to keep integration smooth.
- Fix broken builds immediately. A broken build has the highest priority because it affects the entire team and other teams.
- Use gated commits to prevent broken builds. The build server validates your code before it enters version control.
- Include application security in your build. Scan your own code and all dependencies for vulnerabilities as part of every build.