Keeping a software project running is a difficult art. It's fine at first, when the site is in beta and you're happily flipping switches on Drupal's control panels. But soon the site goes live, and downtime costs both money and goodwill, and MySQL fills up with customer data that must not be lost or corrupted, and the code develops multiple branches that are developed and tested on multiple machines, and are edited by programmers who must avoid stepping on each other's work.
This is an introduction to the principles of Continuous Integration (CI), a popular strategy for software projects that attempts to minimize the risk, uncertainty, and effort of releasing new code. We'll discuss:
- Why managing a production site is so much more irritating than building a beta site from scratch, and how CI can ease the pain.
- The central goal of CI: That every project should have a single main branch that is always ready to deploy, passing all tests, and synced with each developer's work.
- Typical strategies for achieving this goal – dedicated integration servers; routine testing of each patch at several stages; frequent commits by all stakeholders; rapid, automated testing and deployment; testing on clones of the production stack – with notes on how these may apply to Drupal sites.
This is a beginner to intermediate session, requiring no coding experience, though a familiarity with the dynamics of software maintenance will help to inspire you.
Mike Booth, is a former devops engineer and the original release manager for Acquia Cloud Drupal hosting, and as such has had a meaningful relationship with Continuous Integration. Though his cardiologist cannot confirm it, Mike believes that CI may have saved his life. War stories will be told as time permits.