Continuous Integration (CI) is a software development practice where team members integrate their work frequently, tested through automated builds to identify errors quickly. This document outlines CI's practices, benefits, and tools, emphasizing communication, fast feedback, and the importance of maintaining a common source repository. The advantages of CI include reduced risks, easier bug detection, and improved developer collaboration, ultimately leading to a more efficient development process.

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

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

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

4. ● Building a feature with continuous
integration
● Let's do something to a piece ● Update the working copy with
of software,we assume it's the changes from the others
small and can be done in a & rebuild, check for clashes.
few hours. ● It is yours responsibility to
● Take a copy of the current create a successful build.
integrated source onto your ● Commit your changes.
local development machine.
● Build on the integration
● Alter the production code,
machine.
and add or change the
automated tests. ● Must fix the build quickly.
● Build and run the automated ● Shared stable base, fewer
tests. bugs, bugs show up
quickly.

5. ● Practices of continuous integration
● Maintain a Single ● Keep the Build Fast
Source Repository ● Test in a Clone of the
● Automate the Build Production
● Make Your Build Self- Environment
Testing ● Make it Easy for
● Everyone Commits To Anyone to Get the
the Mainline Every Day Latest Executable
● Every Commit Should
● Everyone can see
Build the Mainline on what's happening
an Integration Machine ● Automate Deployment

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

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

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

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

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

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

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

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

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

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

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

17. ● 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.

18. ●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.

19. Final thoughts
● when unit tests fail or a bug emerges, developers might ● initial setup time
revert the codebase back to a bug-free state, without wasting required
time debugging ● well-developed
● developers detect and fix integration problems continuously - test-suite required
avoiding last-minute chaos at release dates to achieve
automated testing
● early warning of broken/incompatible code advantages
● early warning of conflicting changes ● large-scale
● immediate unit testing of all changes refactoring can be
● constant availability of a "current" build for testing, demo, or troublesome due
to continuously
release purposes
changing code
● immediate feedback to developers on the quality, base
functionality, or system-wide impact of code they are writing ● hardware costs
● frequent code check-in pushes developers to create modular, for build
less complex code machines can be
● metrics generated from automated testing and CI focus significant
developers on developing functional, quality code, and help
develop momentum in a team

20. ● 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

21. 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-t
● http://www.developer.com/open/article.php/3803646/The-Best-Contin
● http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.htm