Continuous Integration

● What is continuous integration?● Building a feature with continuous integration● Practices of continuous integration● Benefits of continuous integration● Introducing continuous integration● Final thoughts● Continuous integration tools● Links

What is continuous integration?

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This presentation is a quick overview of Continuous Integration summarizing the technique and its current usage.

What is continuous integration?

● "it can't work (here)"● "doing it won't make much difference"● "yes we do that - how could you live without it?"

The term 'Continuous Integration' originated with the Extreme Programming development process, as one of its original twelve practices. Although Continuous Integration is a practice that requires no particular tooling to deploy, it is useful to use a Continuous Integration server.

● Integration is a "pay me now or pay me more later" kind of activity.

●Building a feature with continuous integration

● Let's do something to a piece of software,we assume it's small and can be done in a few hours.

● Take a copy of the current integrated source onto your local development machine.

● Alter the production code, and add or change the automated tests.

● Build and run the automated tests.

● Update the working copy with the changes from the others & rebuild, check for clashes.

● It is yours responsibility to create a successful build.

● Commit your changes.

● Build on the integration machine.

● Must fix the build quickly.

● Shared stable base, fewer bugs, bugs show up quickly.

●Practices of continuous integration

● Maintain a Single Source Repository

● Automate the Build● Make Your Build Self-

Testing● Everyone Commits To

the Mainline Every Day● Every Commit Should

Build the Mainline on an Integration Machine

● Keep the Build Fast● Test in a Clone of the

Production Environment

● Make it Easy for Anyone to Get the Latest Executable

● Everyone can see what's happening

● Automate Deployment

Maintain a Single Source Repository

● Software projects involve lots of files that need to be orchestrated together to build a product.

● Tools to manage all this - called Source Code Management tools, configuration management, version control systems, repositories, etc.

● Everything you need to do a build should be in there including: test scripts, properties files, database schema, install scripts, 3rd party libs.

● Keep your use of branches to a minimum.

● In general you should store in source control everything you need to build anything, but nothing that you actually build.

Automate the Build

● Automated environments for builds are a common feature of systems (Make, Ant, Nant, MSBuild, etc.)

● A common mistake is not to include everything in the automated build (virgin machine – up!)

● Incremental builds, component builds, targets● It's essential to have a master build that is

usable on a server and runnable from other scripts (Do not depend much on IDE)

Make Your Build Self-Testing

● A program may run, but that doesn't mean it does the right thing.

● A good way to catch bugs more quickly and efficiently is to include automated tests in the build process.

● CI has a weaker requirement of self-testing code then TDD.

● For self-testing code you need a suite of automated tests that can check a large part of the code base for bugs.

● The rise of TDD has popularized the XUnit family.● Tools that focus on more end-to-end testing, like FIT,

Selenium, Sahi, Watir, FITnesse, etc.● You can't count on tests to find everything.

Everyone Commits To the Mainline Every Day

● Integration is primarily about communication.

● The one prerequisite for a developer committing to the mainline is that they can correctly build their code.

● The key to fixing problems quickly is finding them quickly.

● The fact that you build when you update your working copy means that you detect compilation conflicts as well as textual conflicts.

● Since there's only a few hours of changes between commits, there's only so many places where the problem could be hiding. You can even use diff-debugging.

● Frequent commits encourage developers to break down their work into small chunks of a few hours each. This helps track progress and provides a sense of progress.

Every Commit Should Build the Mainline on an Integration Machine

● Using daily commits, a team gets frequent tested builds.

● People not doing an update and build before they commit, environmental differences between developers' machines and other issues – prevent mainline's healthy state.

● Integration build succeeds should the commit be considered to be done – developers responsibility.

● Use a manual build or a CI server.

● Do not just make builds on a timed schedule.

● If the mainline build fails, it needs to be fixed right away. You're always developing on a known stable base.

● It's not a bad thing for the mainline build to break. Fix fast!

● Patience and steady application – develop a regular habit of working mainline builds.

Keep the Build Fast

● The whole point of CI is to provide rapid feedback.● For most projects the XP guideline of a ten minute

build is perfectly within reason.● Start working on setting up a staged build.● Build pipeline – multiple sequential builds.● Fast commit build is the build that's needed when

someone commits to the mainline.● Secondary build which runs when it can – for

example tests that involve external services such as a database, etc.

Test in a Clone of the Production Environment

● The point of testing is to flush out, under controlled conditions, any problem that the system will have in production.

● You want to set up your test environment to be as exact a mimic of your production environment as possible.

● It's common to have a very artificial environment for the commit tests for speed, and use a production clone for secondary testing.

● Use virtualization.

Make it Easy for Anyone to Get the Latest Executable

● People find it much easier to see something that's not quite right and say how it needs to be changed.

● Anyone involved with a software project should be able to get the latest executable and be able to run it: for demonstrations, exploratory testing, or just to see what changed this week.

● Well known place where people can find the latest executable. For the very latest you should put the latest executable to pass the commit tests (pretty stable).

Everyone can see what's happening

● CI is all about communication, so you want to ensure that everyone can easily see the state of the system and the changes that have been made to it.

● Tray monitors, lights, lava lamps, toy rocket launchers, etc.

● Use a tool with a web site for dashboard, reporting and extended information.

● Wall calendar for a QA team to put red & green stickers indicating healthy & broken builds.

Automate Deployment

● To do CI you need multiple environments, one to run commit tests, one or more to run secondary tests.

● Use deployment scripts to move between environments

● If you deploy into production one extra automated capability you should consider is automated rollback.

● Rolling deployments in clustered environments.● Trial build to a subset of users.

●Benefits of continuous integration

● The greatest and most wide ranging benefit of CI is reduced risk.

● At all times you know where you are, what works, what doesn't, the outstanding bugs you have in your system.

● CI doesn't get rid of bugs, but it does make them dramatically easier to find and remove.

● Bugs are also cumulative. The more bugs you have, the harder it is to remove each one. Broken Windows syndrome.

● If you have CI, it removes one of the biggest barriers to frequent deployment – between customers and development.

●Introducing continuous integration

● There's no fixed recipe (your setup & team)● Get the build automated. Build the whole

system with a single command. On-demand.● Introduce some automated testing into you

build. Identify major areas. Start doing.● Try to speed up the commit build. Magic 10m.● Begin with Continuous Integration from the

beginning for a new project.● Get some help.

●Final thoughts

● Continuous Integration has become a mainstream technique for software development.

● Many teams using CI report that the advantages of CI well outweigh the disadvantages.

● The effect of finding and fixing integration bugs early in the development process saves both time and money over the lifespan of a project.

Final thoughts

● when unit tests fail or a bug emerges, developers might revert the codebase back to a bug-free state, without wasting time debugging

● developers detect and fix integration problems continuously - avoiding last-minute chaos at release dates

● early warning of broken/incompatible code● early warning of conflicting changes● immediate unit testing of all changes● constant availability of a "current" build for testing, demo, or

release purposes● immediate feedback to developers on the quality,

functionality, or system-wide impact of code they are writing● frequent code check-in pushes developers to create modular,

less complex code● metrics generated from automated testing and CI focus

developers on developing functional, quality code, and help develop momentum in a team

● initial setup time required

● well-developed test-suite required to achieve automated testing advantages

● large-scale refactoring can be troublesome due to continuously changing code base

● hardware costs for build machines can be significant

●Continuous integration tools

Most popular:

● Apache Continuum — continuous integration server supporting Apache Maven and Apache Ant. Supports CVS, Subversion, Ant, Maven, and shell scripts

● Hudson — MIT-licensed, written in Java, runs in servlet container, supports CVS, Subversion, Mercurial, Git, StarTeam, Clearcase, Ant, NAnt, Maven, and shell scripts

● CruiseControl — Java-based framework for a continuous build process

● CruiseControl.NET — .NET-based automated continuous integration server

Links

● http://en.wikipedia.org/wiki/Continuous_integration

● http://www.martinfowler.com/articles/continuousIntegration.html

● http://www.extremeprogramming.org/rules/integrateoften.html

● http://cruisecontrol.sourceforge.net/overview.html

● http://wiki.hudson-ci.org/display/HUDSON/Use+Hudson

● http://continuum.apache.org/

● http://www.wakaleo.com/books/continuous-integration-with-hudson-the-book

● http://www.developer.com/open/article.php/3803646/The-Best-Continuous-Integration-Tools.htm

● http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html