Continuous integration (CI) is a software engineering practice where developers frequently integrate their work, leading to multiple integrations per day. This approach reduces integration problems and allows teams to develop cohesive software more rapidly. The presentation discusses what CI is, why teams need it, prerequisites like version control and automated testing, typical workflows, tools, and benefits like reduced risks and improved code quality. It also examines problems teams face in implementing CI effectively and potential areas of future research like making CI tools more adaptive and addressing scalability issues.

1. CONTINUOUS INTEGRATION

2. PRESENTATION PLAN
1.
State of the practice
1.
2.
3.
4.
5.
6.
7.
8.
2.
3.
4.
5.
6.
What is continuous integration?
Why do development teams need continuous integration?
Prerequisites for continuous integration process
General CI workflow
How does continuous integration affect development process?
When CI is not effective?
Short tools overview
Benefits of using CI
Problems with current state of the practice
Research ideas
Future of CI
CI and COPE
Recommended readings
2

3. WHAT IS CONTINUOUS
INTEGRATION?
Widely used
software
engineering
practice
development
process
automation
technique
Approach
helping to
reduce risks
3

4. WHY DO TEAMS NEED CONTINUOUS
INTEGRATION?
 Martin
Fowler:
… team integrate their work frequently,
… leading to multiple integrations per day.
… this approach leads to significantly reduced integration
problems and allows a team to
develop cohesive software more rapidly.
 CI
is the one of the XP practices
 Allows team to get fresh latest build
regularly
4

5. PREREQUISITES FOR CONTINUOUS
INTEGRATION
Not everything
you can integrate continuously
5

6. PREREQUISITES FOR CONTINUOUS
INTEGRATION
VCS system
CI tool
Separate
server
(usually)
Build
automation
Selftesting app
(unit-tests)
6

7. GENERAL CI WORKFLOW
Build
(compilation,
unit-testing, db
integration, etc)
Committing
latest
changes
Update by
scheduler
(on CI
server)
Application
is ready
7

8. GENERAL CI WORKFLOW
changes
detected
update
commit
build &
deploy
~
repository
deployment server
continuous integration server
8

9. TOOLS CLASSIFICATION
CI tools
Build management tools
Unit testing tools
Inspection tools
• Code coverage analysis
• Static analysis (syntax check, code
dependencies)
• Copy/paste detectors
10
Documentation generation tools

10. CI TOOLS

CruiseControl

CruiseControl.NET

CruiseControl.rb

JetBrains TeamCity

Apache Hudson

Apache Continuum

Atlassian Bamboo

FinalBuilder

phpUnderControl

XInc
11

11. CI TOOLS
Too many tools
 All are great
 All have the same principle
 But each has specific features

Diagrams,
metrics,
reporting
Interface,
usability
Integration
with SCM
tools
Notification
Distributed
builds
Different
ALM
approaches
12

12. CONTINUOUS INTEGRATION – PART OF SDLC
Initiation
Requirements
development &
management
Design
Testing
Integration
Implementation
Deployment
Maintenance &
support
Utilization
13

13. CONTINUOUS INTEGRATION – PART OF SDLC
Initiation
Requirements
development &
management
Design
Basic continuous integration
Testing
Integration
Implementation
Deployment
Maintenance &
support
Utilization
14

14. CONTINUOUS INTEGRATION – PART OF SDLC
Initiation
Requirements
development &
management
Design
Basic continuous integration
Testing
Integration
Implementation
Maintenance &
support
Utilization
Extended build
management
Deployment
15

15. BUILD TOOLS

Ant

NAnt

MSBuild

Maven

Make

Phing

Rake

…
16

16. UNIT TESTING TOOLS

Junit

NUnit

CppUnit

PHPUnit

SimpleTest

JSUnit

J3Unit
17

17. INSPECTIONS TOOLS.
TEST COVERAGE
Cobertura
 Atlassian Clover
 jTest
 JCoverage
 CodeCover
 EMMA
 Parasoft Insure++
 Ncover
 Xdebug
 Coverage.py

18

18. INSPECTIONS TOOLS.
TEST COVERAGE
Cobertura
 Atlassian Clover
 jTest
 JCoverage
 CodeCover
 EMMA
 Parasoft Insure++
 Ncover
 Xdebug
 Coverage.py

Java
C++
C#
PHP
19
Python

19. INSPECTIONS TOOLS.
STATIC ANALYSIS
 PMD
 FindBugs
 JLint
 FxCop
 Checkstyle
 ReSharper
 PHP_CodeSniffer
 Yasca
 NDepend
20

20. INSPECTIONS TOOLS.
COPY/PASTE DETECTORS
CPD
(Copy paste detector)
Checkstyle
Simian
Jplag
Atomiq
Clone digger
PBA
21

21. DOCUMENTATION GENERATION
TOOLS
Doxygen
JavaDoc
NDoc
CppDoc
phpDocumentor
pyDoc
RDoc
22

22. OTHER TOOLS
Source code
metrics (loc)
Dead code
detectors
Profiling
…
23

23. BENEFITS OF USING CI








Reduces risks of problems with source code integration
by stimulating team members to perform integration
early and often.
Provides automated reports about code quality.
Increases visibility of current project status and project
progress by providing shared reports available to all
team members.
Provides historical data on source code quality and
metrics.
Always contains last fresh build that could be used for
deployment, testing or other purposes.
Reduces number of routine repetitive activities by
automating part of development lifecycle.
Runs costly inspections on the server (in contrast to
inspections available in modern IDEs)
Stimulates developers to write better source code
24

24. BENEFITS OF USING CI FOR RESEARCH
Reproducible results of research
25

25. PROBLEMS

“Don‟t break the build” obsession.
This rule undermines cooperation, transparency and trust
between team members
 Root cause of the problem is failure to draw apply different
CI practices for different SDLC stages (development and
release)


Necessity to instantiate CI build plan for separate
branch/codebase
Some branches require instantiation of CI build plan, some
don‟t
 Usually there is no rule specifying whether branch should
have its own CI build plan configuration

Benefits of CI are different for different SDLC stages
 Necessity to write and support build scripts


Very often it happens that activity of supporting build scripts
is not a priority.
26

26. PROBLEMS
Even though builds run automatically, somebody needs
to support and configure CI server if project grows in
size.
 Continuous deployment and continuous release seem
to be a good idea, but do not usually occur in practice
due to lack of flexibility and configuration complexity.
 Teams that use CI are forced to make some premature
commitments that are difficult to change later (project
structure, deployments configuration, etc).

27

27. WHEN CI IS NOT EFFECTIVE?
 Pure
DVCS (without central repo)
 Experimental development
 Small projects
 Interpreted languages without unit-tests
 When database is being changed too often
 Types of projects
 Documentation (BA, etc)
 DB
 Support & maintenance
28

28. WHY SHOULD WE USE CI IF IDES
ALREADY HAS EVERYTHING WE NEED?

Modern IDEs already have:







embedded build systems
unit-tests
static inspections
dynamic inspections
code coverage metrics
documentation generation
…
29

29. WHY SHOULD WE USE CI IF IDE ALREADY
HAS EVERYTHING WE NEED?
Think about continuous integration as part of
your IDE running in the cloud
Therefore, it is assumed that list of CI
advantages, disadvantages would be applicable
to online IDEs running in the cloud
30

30. POTENTIAL AREAS OF RESEARCH

Smart CI
suggestion of the most important code quality issues
 prioritization of code quality report items


Inclusion of refactorings suggestion into CI builds
API refactorings
 Automatic migration to next versions of libraries


Increase adaptability of CI tools
automatic configuration of inspections
 detect when it is optimal to perform incremental build
and when it is optimal to perform full build

Detect when separate branch should be created to
configure separate CI build plan.
 “Refactor” CI practices for better scalability

31

31. MOST IMPORTANT RESEARCH PROBLEM

What is the problem?





Too much time and effort spent on "optimal configuration“ of
CI builds.
Even though there is a high chance that optimal
configuration exists, development teams are usually far from
optimal solution.
As a result, every team invents its own configuration, which
in vast majority of cases is not optimal enough for future
scaling.
Even though CI is good at saving effort and reducing risk for
teams of medium size, large projects have certain threshold
after which support of CI tools becomes too complex and
ambiguous.
After reaching certain project size CI does not scale
anymore (“Tailspin effect”)
32

32. MOST IMPORTANT RESEARCH PROBLEM

Why is it important?





Software become inherently complex
Software projects grow in size
But there is a certain cap for large projects when development
process cannot be effectively automated.
Therefore, more time, effort and resources are spent on
ambiguous routine activities causing problems with software
quality.
As projects grow in size, spending on software development
and support increase when project size reaches certain
threshold.
33

33. MOST IMPORTANT RESEARCH PROBLEM
 Possible
solutions:
Development of common rules and practices for effective
scalability and embedding those practices into CI tools.
 “Refactoring” of existing CI practices to common practice that
makes project scalable.
 …

34

34. RECOMMENDED READING
1. Continuous Integration: Improving Software Quality and
Reducing Risk by Paul M. Duvall, Steve Matyas, Andrew
Glover
35

35. RECOMMENDED READING
2. Continuous Delivery: Reliable Software Releases through
Build, Test, and Deployment Automation by By Jez
Humble, David Farley
36

36. RECOMMENDED READING
3. Release It!: Design and Deploy Production-Ready
Software by Michael T. Nygard
37

37. RECOMMENDED READING
4. Pragmatic Project Automation: How to Build, Deploy, and
Monitor Java Applications by Mark Clark
38

38. USEFUL LINKS
http://martinfowler.com/articles/continuousIntegratio
n.html - the main article about CI from Martin
Fowler
 http://www.infoq.com/news/2009/03/ContinuousDeployment - Beyond Continuous Integration:
Continuous Deployment
 http://radar.oreilly.com/2009/03/continuousdeployment-5-eas.html - Continuous Deployment in
5 easy steps
 http://www.proudlyserving.com/archives/2007/10/fe
ar_of_a_broke.html - „fear of the broken build‟ effect
 http://www.youbrokethebuild.com/ - great posters
created with the purpose of motivation people avoid
breaking the build

39