Reliable Software Releases through Build, Test, and Deployment Automation

Chapter 3. Continuous IntegrationJez Humble, David Farley

Continuous Delivery

Continuous Integration• Requires that every time somebody commits any change, the

entire application is built and a comprehensive set of automated tests is run against it.• The goal of continuous integration is that the software is in a

working state all the time.• The teams that use continuous integration effectively are able

to deliversoftware much faster, and with fewer bugs, than teams that do not.

What You Need Before You Start

• Version Control• An Automated Build• Agreement of the Team

Version Control• Everything in your project must be checked in to a single

version control repository: code, tests, database scripts, build and deployment scripts, and anything else needed to create, install, run, and test your application.• Some people don’t consider their project big enough to

warrant the useof version control. We don’t believe that there is a project small enough to do without it

An Automated Build• You need to be able to run your build process in an automated way fromyour continuous integration environment so that it can be audited whenthings go wrong.• Your build scripts should be treated like your codebase. They

should betested and constantly refactored so that they are tidy and easy to understand. It’s impossible to do this with an IDE-generated build process. This gets more and more important the more complex the project becomes.• It makes understanding, maintaining, and debugging the

build easier, andallows for better collaboration with operations people.

Agreement of the Team• Continuous integration is a practice, not a tool. It requires a

degree of commitment and discipline from your development team.• You need everyone to check in small incremental changes

frequently to mainline and agree that the highest priority task on the project is to fix any change that breaks the application.• If people don’t adopt the discipline necessary for it to work,

your attempts at continuous integration will not lead to the improvement in quality that you hope for.

Prerequisites for Continuous Integration

• Check In Regularly.• Create a Comprehensive Automated Test Suite• Keep the Build and Test Process Short.• Managing Your Development Workspace

Check In Regularly• The most important practice for continuous integration to

work properly is frequent check-ins to trunk or mainline.• It makes your changes smaller and thus less likely to break

the build. It means you have a recent knowngood version of the software to revert to when you make a mistake or go down the wrong path. • It helps you to be more disciplined about your refactoring and

stick to small changes that preserve behavior. It helps to ensure that changes altering a lot of files are less likely to conflict with other people’s work

Create a Comprehensive Automated Test Suite

• If you don’t have a comprehensive suite of automated tests, a passing build only means that the application could be compiled and assembled. • While for some teams this is a big step, it’s essential to have

some level of automated testing to provide confidence that your application is actually working.• Should provide an extremely high level of confidence that any

introduced change has not broken existing functionality.

Keep the Build and Test Process Short.If it takes too long to build the code and run the unit tests, you

will run into the following problems:• People will stop doing a full build and running the tests before

they checkin. You will start to get more failing builds.• The continuous integration process will take so long that

multiple commitswill have taken place by the time you can run the build again, so you won’tknow which check-in broke the build.• People will check in less often because they have to sit

around for ageswaiting for the software to build and the tests to run.

Managing Your Development Workspace• Developers should always work from a knowngood starting

point when they begin a fresh piece of work. They should be able to run the build, execute the automated tests, and deploy the application in an environment under their control. In general, this should be on their own local machine.• For most projects, the third-party libraries they depend on

don’t change very frequently, so the simplest solution of all is to commit these libraries into your version control system along with your source code.• In fact, one sign of a good application architecture is that it

allows the application to be run without much trouble on a development machine.

Essential Practices

• Don’t Check In on a Broken Build• Wait for Commit Tests to Pass before Moving On• Never Go Home on a Broken Build• Always Be Prepared to Revert to the Previous Revision

Essential Practices• Time-Box Fixing before Reverting• Don’t Comment Out Failing Tests.• Take Responsibility for All Breakages That Result from Your

Changes• Test-Driven Development

SUMMARY• To implement continuous integration is to create a paradigm

shift in yourteam. Without CI, your application is broken until you prove otherwise. • With CI, the default state of your application is working, albeit

with a level of confi- dence that depends upon the extent of your automated test coverage.• CI creates a tight feedback loop which allows you to find

problems as soon as they are introduced, when they are cheap to fix.

SUMMARY• Implementing CI forces you to follow two other important

practices: goodconfiguration management and the creation and maintenance of an automated build and test process.• CI requires good team discipline. What is different about

continuous integration is that you have a simple indicator of whether or not discipline is being followed: The build stays green. • If you discover that the build is green but there is insufficient

discipline, for example poor unit test coverage, you can easily add checks to your CI system to enforce better behavior.

SUMMARYAn established CI system is a foundation on which you can build more infrastructure:• Big visible displays which aggregate information from your

build systemto provide high-quality feedback.• A system of reference for reports and installers for your

testing team.• A provider of data on the quality of the application for project

managers.• A system that can be extended out to production, using the

deploymentpipeline, which provides testers and operations staff with push-buttondeployments.

Andrés Callejas GonzálezUniversidad Pontificia Bolivariana