Chapter 3 discusses continuous integration (CI) as a critical practice for automating the build, testing, and deployment of software, emphasizing the necessity of team discipline and version control. Key requirements include frequent check-ins, a comprehensive automated test suite, and a short build process to maintain software in a working state. CI establishes a foundation for enhanced infrastructure and feedback mechanisms, facilitating faster delivery of high-quality software.

1. Reliable Software Releases through Build, Test, and
Deployment Automation
Chapter 3. Continuous Integration
Jez Humble, David Farley
Continuous Delivery

2. 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 deliver
software much faster, and with fewer bugs, than teams that do not.

3. What You Need Before You
Start
• Version Control
• An Automated Build
• Agreement of the Team

4. 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 use
of version control. We don’t believe that there is a project small enough to
do without it

5. An Automated Build
• You need to be able to run your build process in an automated way from
your continuous integration environment so that it can be audited when
things go wrong.
• Your build scripts should be treated like your codebase. They should be
tested 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, and
allows for better collaboration with operations people.

6. 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.

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

8. 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

9. 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.

10. 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 check
in. You will start to get more failing builds.
• The continuous integration process will take so long that multiple commits
will have taken place by the time you can run the build again, so you won’t
know which check-in broke the build.
• People will check in less often because they have to sit around for ages
waiting for the software to build and the tests to run.

11. 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.

12. 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

13. 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

14. SUMMARY
• To implement continuous integration is to create a paradigm shift in your
team. 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.

15. SUMMARY
• Implementing CI forces you to follow two other important practices: good
configuration 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.

16. SUMMARY
An established CI system is a foundation on which you can build more
infrastructure:
• Big visible displays which aggregate information from your build system
to 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 deployment
pipeline, which provides testers and operations staff with push-button
deployments.

17. Andrés Callejas González
Universidad Pontificia Bolivariana