Last week, we made the case that production software absolutely must be checked in to source control. Today we will ask a bit more of you by making the case that production software must be running through your continuous integration system.
The reasons are similar. Keeping your production software in source control allows you to recover production code easily, and keeping it in continuous integration allows you to build it easily. Like source control, continuous integration facilitates collaboration by forcing developers to merge their changes together frequently in order to keep the build green. By adopting the policy of only releasing software that was built by your build system, you ensure that your software can be reproduced by a machine with well-defined (and limited) environmental dependencies.
We recommend taking it one step further and adopting the branch-for-release strategy, with one main code line of “trunk” development and periodic “branches” for released software. Each code line (the “trunk” and each “release”) gets its own build in continuous integration. Ideally, software is only released to production if it was built by the continuous integration server off a release branch. Any software your team supports should have at least two builds in continuous integration – the current production release branch and the trunk.
Why build both the release and the trunk?
If you aren’t building the release branch, you have no easy way of creating a patch build on top of the software currently running in production. When the time comes to make an emergency bug fix, you want that process to be as simple, reliable, and panic-free as possible. Without a release build, you’ll struggle to cobble together a build on the server or, worse yet, just build it on your workstation. A release build indicates that this particular snapshot of the code is in production and supported.
A trunk build means that the application is supported going forward. A trunk build ensures that your team is properly caring for the code as the whole system evolves, and will at the very least will fix it if it breaks due to changes in shared code or libraries. This allows you to make major (non bug-fix) changes to the application as the need arises. If you aren’t building the trunk, you have effectively abandoned the project and told your business that you will never make changes to it again.
Keeping your code in continuous integration is critical because it allows you to quickly and consistently deliver deployable builds of your software. But perhaps more importantly, continuous integration is a critical communication mechanism. By putting a build in CI, you very clearly communicate to your team (and your business) that you have a shared responsibility to keep the build green and support the underlying software.
