Julian Simpson, Principal Consultant at The Build Doctor, has compiled a set of patterns for maintaining a fast and reliable application build process and avoiding some Continuous Integration (CI) pitfalls. He also presents a number of patterns for deployment automation and testing in production-like environments.
- Façade Build: As build tools evolve build managers face the choice to keep their tried and tested but aging build scripts or rewrite them at the risk of regressions. The Façade build pattern promotes reuse of existing scripts by wrapping them in new tools first (for example embedding Ant code with Maven) and then refactor where appropriate.
- Captive Build Tool: Using a generic master build common to all projects also helps to evolve the build process without affecting development productivity.
- Green-Light Build: When Continuous Integration hits build resource limits, developers slow down as they wait for their turn to build. By dedicating some capacity to quick builds (such as time-critical bug fixes) the Green-Light Build pattern can boost productivity even if resource usage is sub-optimal.
Julian lists ten other patterns for efficient application testing and deployment to production-like environments using common techniques such as transactions, virtual images and stubs:
- Embedded Test Team
- Blue-green Deployments (contributed by Jez Humble and David Farley)
- Cookie Cutter Servers
- Simplicator (contributed by Steve Freeman and Nat Pryce)
- A/B Deployment (contributed by Timothy Fitz)
- Virtualization
- Time Slicing
- Stubs
- Atomic Deployment
- Configuration Repository
The list completes with four other useful build and CI patterns from different sources:
- Immediate Test Failure Notification (contributed by Aslak Hellesøy)
- Fast and the Full Builds (contributed by Jon Tirsen)
- Checkin Gate or Movable Checkin Gate (contributed by Sam Newman)
- Binary Deliverable (contributed by Parumu)
On a related note, Jez Humble posted a couple of deployment anti-patterns (insufficient parallelization and inflexible workflow) which introduce unnecessary constraints and/or delays in the deployment pipeline.