Easy Promotion of Arbitrary Builds

Most of the practices described in the pain free building guide have been focused on the development team. However, broken builds also impact other teams, such as QA, that depend on a steady stream of builds. If the build breaks at the end of the day, and deployments and tests use the latest code and deploy them, a broken build can bring testing to a halt. Nothing will be deployed or tested, and the detection of new defects will be delayed. The result is that QA teams become less effective.

Indeed, many radical approaches to preventing build breakages have been suggested, with the intent of ensuring that the nightly build for QA will work successfully. If the build server manages the build products, this type of pipeline blockage can be avoided.

If instead of deploying "the latest code" the server is set to lookup the most recent successful build, or the most recent build to pass an early round of testing, development can continue to supply the testing pipeline even if the most recent commit happened to break the build. If the afternoon Continuous Integration build can be used in place of the nightly build (in the rare circumstance of a failed nightly build), more extreme measures can be avoided.

Like easy checkout of working code, this practice supports the fourth pillar of pain free building by ensuring that a broken build does not bring work to a halt. Effective workarounds that keep every team working are critical.