Obaid ur Rehman

Continuous Integration
(CI)

1
Agenda

 Continuous Integration
 Introduction
 How does it work?
 Practices of Continuous Integration
 What Benefits does CI offer?
 A Basic CI Cycle
 Using CI to reduce Risk
 Benefits of CI
 What Prevents Teams from Using CI?
 When and How Should a Project Implement
CI?
 Conclusion
2
What is Continuous
Integration?
Martin Fowler describes CI as:
…a software development practice where
team members integrate frequently,
leading to multiple integrations per day.
Each integration is verified by an
automated build and test to detect
integration errors as quickly as possible.
This approach leads to significantly
reduced integration problems and
allows a team to develop cohesive
software more rapidly.
http://www.martinfowler.com/articles/continuousIntegration.ht
3
ml
What is Continuous
Integration?
 Rephrased another way, Continuous
integration describes a set
of software engineering practices
that speed up the delivery of
software by decreasing integration
times.

4
The Evolution of CI

 The term 'Continuous Integration'

originated with the Extreme
Programming development process,
as one of its original twelve practices.
 Continuous Integration emerged in
the Extreme Programming (XP)
community, and XP advocates Martin
Fowler and Kent Beck first wrote
about continuous integration around
2000.
5
So how does it work?

 Letstake a quick example of how a

development cycle would proceed in a
CI enable environment:

 I take a copy of the latest source code from

the repository.
 I do what ever I need to do to complete my
task.
 Once I am done I carry out an automated
build on my machine. This is called a private
build.
 With a good build, I can think of committing
6
So how does it work?

 The problem, is that other people may, and

usually have, made changes to the mainline
before I get chance to commit.
 So I am going to update my working copy.
 And then I do a private build, again and…
 If it fails, I fix it. I keep doing this till I get a
successful build !
 Once I have made my own build of a
properly synchronized working copy I can
then finally commit my changes into the
mainline, which then updates the repository.
 So, now I can call it day and head home….
No wait
7
So how does it work?

 Once I commit my code the integration

build machine, a separate machine
whose sole responsibility is to integrate
software, runs an automated build again.
 Its not until that this machines give a
green signal that I call it a day.

8
Okay, so what’s the
benefit?
 The result of doing this is that there is a stable
piece of software that works properly and
contains few bugs.
 Everybody develops off that shared stable base
and never gets so far away from that base that
it takes very long to integrate back with it.
 Less time is spent trying to find bugs because
they show up quickly.
 Continuous Integration assumes a high degree
of tests which are automated into the software.
 We’ll discuss more about benefits later on…
9
Principle and Practices of
Continuous Integration
 Theprevious story is the overview of
CI and how it works in daily life.

 Let’sfocus now on the key practices

and principles that make up an
effective CI.

10
Principle and Practices of
Continuous Integration

11
Maintain a Single Source
Repository
 Obviously!

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

12
Automate the Build

 Must do everything from compilation

to testing, inspection.

 Ruleof thumb: anyone should be

able to bring in a virgin machine,
check the sources out of the
repository, issue a single command,
and have a running system on their
machine.1
1.
13
http://www.martinfowler.com/articles/continuousIntegration.ht
Make Your Build Self-
Testing
 “…a body of code must have a set of
automatic tests that can check a
large part of the code base for bugs”

 Could be a combination of …
 A smoke test
 Developer written unit tests
 Subset of full test suite selected by QA

14
Automate Deployment

 Youshould have scripts that allow

you to deploy into production with
ease.

 Automaticdeployment helps both

speed up the process and reduce
errors.

15
Run Private Builds

 To prevent broken builds, developers should

emulate an integration build on their local
workstation.
 This allows you to integrate your new
working software with the working software
from all the other developers, obtaining the
changes from the version control repository
and successfully building locally with the
recent changes.
 Thus, the code each developer commits has
contributed to the greater good, with code
16
All Tests and Inspections
Must Pass
 Ina CI environment, 100% of a
project’s automated tests must pass
for your build to pass

 Automated tests are as important as

the compilation.

17
Everyone Commits Every
Day
 Integration
is primarily about
communication. Integration allows
developers to tell other developers
about the changes they have made.
Frequent communication allows people
to know quickly as changes develop.
 The key to fixing problems quickly is
finding them quickly. With developers
committing every few hours a conflict
can be detected within a few hours of it
occurring 18
Every Commit Should Build
the Mainline on an
Integration Machine
A CI server runs an integration build
whenever a change is committed to the
version control repository.
 Typically,
you will configure the CI
server to check for changes in a version
control repository every few minutes or
so.
 The CI server will retrieve the source
files and run a build script or scripts and
generate feedback. 19
 Basic CI Cycle

Revie
w
Developer
Feedback Genera
Mechanism te
Commit

Commit Po
Changes ll
Developer

Subversion CI Server Build Script, Compile

Commit Version Integration Source code,
Changes Control Build Integrate Database,
Repository Machine Run Tests and
Inspections,

Developer

20
Reducing Risk using CI

 Thingswill always go wrong on a

project. By effectively practicing CI,
you find out problems at every step
along the way rather than late into
the development cycle.

 CIhelps you identify and mitigate

risks when they occur, making it
easier to evaluate and report on the
health of the project based on
21
Reducing Risk

22
Risk: Lack of Deployable
Software
 CIeliminates lengthy integration
phases before delivering the software
internally (i.e., test team) or
externally (i.e., customer), because
we are building on every change.

23
Risk: Late Discovery of
Defects
 Once developers or teams believe they
have written the corresponding tests for
their source code, you can run a code
coverage tool to assess the amount of
source code that is actually executed by
the tests.
 Using CI can ensure this test coverage
is always up to date. For instance, you
can run a test coverage tool as a part of
your CI system’s build script whenever
there is a change to your version
control repository.
24
Risk: Lack of Project
Visibility
 Know the health of your project at all
times by running builds regularly.

 When effectively applying the

practice of CI, the project status is no
longer in question.

25
Risk: Low-Quality
Software
 InCI we run tests and inspections at
every change so you can discover
potential defects that may be
introduced into the code base by
learning the complexity, duplication,
design, code coverage, and other
factors.

26
What Is the Value of CI?

At a high level, the value of CI includes:

 Reduce risks
 Reduce repetitive manual processes
 Generate deployable software at any time and at any
place
 Enable better project visibility
 Establish greater confidence in the software product
from the development team
Let’s review what these principles mean and what value
they offer.

27
Reduce Risks
 Defects are detected and fixed sooner: Because
CI integrates and runs tests and inspections several
times a day, there is a greater chance that defects are
discovered when they are introduced (i.e., when the
code is checked into the version control repository)
instead of during late-cycle testing.
 Health of software is measurable: By
incorporating continuous testing and inspection into
the automated integration process, the software
product’s health attributes, such as complexity can be
tracked over time.
 Reduce assumptions: By rebuilding and testing
software in a clean environment using the same
process and scripts on a continual basis, you can
reduce assumptions (e.g., whether you are accounting
for third-party libraries or environment variables).
28
Reduce Repetitive
Processes
Reducing repetitive processes saves time, costs, and effort.
This sounds straightforward, doesn’t it? These repetitive
processes can occur across all project activities, including
code compilation, database integration, testing,
inspection, deployment, and feedback. By automating CI,
you have a greater ability to ensure all of the following:
 The process runs the same way every time.
 An ordered process is followed. For example, you may run
inspections (static analysis) before you run tests—in your
build scripts.
 The processes will run every time a commit occurs in the
version control repository.
This facilitates
 The reduction of labor on repetitive processes, freeing
people to do more thought-provoking, higher-value work
 The capability to overcome resistance (from other team
members) to implement improvements by using automated
mechanisms for important processes such as testing and
29
Generate Deployable
Software
CI can enable you to release deployable software at
any point in time. From an outside perspective, this is
the most obvious benefit of CI. We could talk endlessly
about improved software quality and reduced risks,
but deployable software is the most tangible asset to
“outsiders” such as clients or users. The importance
of this point cannot be overstated.
With CI, you make small changes to the source code and
integrate these changes with the rest of the code base
on a regular basis. If there are any problems, the
project members are informed and the fixes are
applied to the software immediately. Projects that do
not embrace this practice may wait until immediately
prior to delivery to integrate and test the software.
This can delay a release, delay or prevent fixing
certain defects, cause new defects as you rush to
complete, and can ultimately spell the end of the
30
What Prevents Teams from
Using CI?
 IfCI has so many benefits, then what
would prevent a development team
from continuously integrating
software on its projects?

 Often,it is a combination of
concerns.

31
Increased overhead in
maintaining the CI system?
 This is usually a misguided
perception, because the need to
integrate, test, inspect, and deploy
exists regardless of whether you are
using CI. Managing a robust CI
system is better than managing
manual processes.

32
Too much change in
Process?
 Some may feel there are too many
processes that need to change to
achieve CI for their legacy project.
 An incremental approach to CI is
most effective; first add builds and
tests with a lower occurrence (for
example, a daily build), then increase
the frequency as everyone gets
comfortable with the results.
33
Additional
hardware/software costs
 Toeffectively use CI, a separate
integration machine should be
acquired, which is a nominal expense
when compared to the more
expensive costs of finding problems
later in the development lifecycle.

 Costcan also be minimized through

Virtualization.
34
Developers should be
performing these activities
 Some times management feels like CI is just
duplicating the activities that developers
should be performing anyway.
 Yes, developers should be performing some
of these activities, but they need to perform
them more effectively and reliably in a
separate environment. Leveraging
automated tools can improve the efficiency
and frequency of these activities.
Additionally, it ensures that these activities
are performed in a clean environment,
which will reduce assumptions and lead to
35
When and How Should a
Project Implement CI?
 It is best to implement CI early in the project. Although possible, it
is more difficult to implement CI late in a project, as people will be
under pressure and more likely to resist change. If you do
implement CI later in a project, it is especially important to start
small and add more as time permits.
 There are different approaches to setting up the CI system. Though
you eventually want a build to run on every change to the system,
you can start by running a build on a daily basis to get the practice
going in your organization.
 Remember: CI is not just a technical implementation; it is also an
organizational and cultural implementation. People often resist
change, and the best approach for an organization may be to add
these automated mechanisms to the process piece by piece.
 At first the build can just compile the source code and package the
binaries without executing the automated regression tests. This
can be effective, initially, if the developers are unfamiliar with an
automated testing tool. Once this is in place and developers have
learned the testing tool, you can move closer to the benefits of CI:
running these tests (and inspections) with every change.
36
Conclusions

 CI is a set of principles and practices

as described.

 Ithelps in improving your software

development process by various
means as we discussed.

 Ithelps mitigate the various risks

faced by a project in its lifecycle.
37
Refrences

 Continuous Integration Improving

Software Quality and Reducing Risk
by Paul M. Duvall with Steve Matyas
and Andrew Glover, 2007 Addison
Wesley Signature Series

 Continuous Integration – Martin

Fowler
http://www.martinfowler.com/articles/
continuousIntegration.html
38
The End
The End
Thank you

39
QA Session
QA Session
Any question you want to ask?

Refrences
Continuous Integration Improving Software Quality and
Reducing Risk by Paul M. Duvall with Steve Matyas and
Andrew Glover, 2007 Addison Wesley Signature Series

Continuous Integration – Martin Fowler

http://www.martinfowler.com/articles/continuousIntegration.ht
ml

40