InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Application Build and Continuous Integration Patterns

Posted by Manuel Pais on Apr 13, 2011

Sections
Operations & Infrastructure,
Process & Practices
Topics
Devops ,
Continuous Integration ,
Operations ,
Agile Techniques ,
Patterns and Practices ,
IT Service Management ,
Patterns ,
Cloud Computing ,
Infrastructure ,
Agile

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:

The list completes with four other useful build and CI patterns from different sources:

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.

No comments

Watch Thread Reply