Integration Build

A Developer Workspace, lets you develop code. But you want integration and release to happen in a well-defined environment. This pattern describes how to ensure that integrated code works and maintains the quality of the Main Line

Consistency Challenges

A Developer Workspace should allow developers to do a fairly thorough build and test cycle. Developers need to build locally to get prompt feedback. But you don’t want to share code or release software that was (only) built on a developer’s desktop:

• Developer machines, even if they start with a standard image, may skew from the target environment. The impact of differences may be small, but we want to catch them early.
• Developer machines are often not on the same platform as the target system. In some cases, you may have multiple target platforms.
• Developers might — through accident or sloppiness— skip parts of the build and test cycle before pushing a change.
• As you evolve your process, there may be some tests and checks that can’t be run in a developer’s workspace.

Continuous Integration in a shared environment is a well-known practice that adds quality and speed to a process. We don’t want the CI environment to be the first place code is built and tested; A build that passes in a developer workspace should likely pass in a CI environment.

Because you want the mechanisms for running building and testing to be low overhead, the developer build won’t be exactly the same as the CI build:

• The CI build might run on a platform like Jenkins, Github Actions, or Circle CI. While it’s possible to run these tools locally, the overhead can be high.
• While it’s possible to run your build and test cycle in a container that matches the integration infrastructure, doing so adds overhead, slowing the build and test cycle.

We want a lightweight way to check that new code doesn’t break existing code while still enabling a productive developer build and test cycle.

Automated Backstop

** Establish an Integration Build that runs when changes are pushed to a Task Branch and on a merge to the Main Line. The Integration Build should share elements with the developer workspace build **

An Integration Build is an Automated Check that runs:

• When changes are pushed to a Task Branch
• When a Branch is merged to the Main Line.

An Integraton Build provides a backstop to ensure that the code passes all of the quality gates before it is shared with other developers (in the case of a push to a Task Branch) or before code is released (in the case of a merge to the Main Line).

The Integration Build:

• Is triggered on a change to a Codeline
• Checks out the latest version of the Codeline
• Compiles and Tests the code
• Runs Automated Checks, including test, style, and others, such as vulnerability scanning.

Your CI build might also perform housekeeping, such as reformatting code to match standards.

If you support a Continuous Deployment mode, the integration build that occurs on a merge to the Main Line will have a follow-up step that can deploy the latest artifact to some environment, either a development or staging environment or production.

An Integration Build helps to ensure consistency of the build results.

While the Integration Build may have some process wrapper steps that are necessary to set up a build on the server platform, the core part of the build should be executable in a developer workspace.

Cautions

An Integration Build is a critical check, but the expectation is that it will pass. In cases where the local build and test cycle is slow, developers might be tempted to limit test execution to code they changed and rely on the Integration Build. If this happens, investigate ways to speed up the build on developer machines.

If checks frequently fail in the CI Build, consider how to push those checks (or processes that address the errors) down to the developer workspace.

Be aware of the duration of the integration build. A long integration build can reduce flow. Some have noted that consistency of build time is more important than duration (Jaspan and Green 2023):

If build latencies were consistent or if the build system could usefully inform the developer of expected latency, the developer could make a better decision about what to do next. Reducing build latency is not our only lever to improve productivity here; we can also improve developers’ ability to make decisions around build latency as it is.

Next Steps

An Integration Build can be more than just Build and Test,. It can also support Automated Checks

To reduce the chance of failing Integration Builds have a mechanism to allow for a uniform build that is shared between the integration build and the developer workspace.

References

• Jaspan, Ciera, and Collin Green. 2023. “Developer Productivity for Humans, Part 4: Build Latency, Predictability, and Developer Productivity.” IEEE Software
• IEEE Softw. 40 (4): 25–29.