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.
2. Continuous Integration (CI)
• 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.
2
4. CONTINUOUS INTEGRATION DOESN’T GET
RID OF BUGS, BUT IT DOES MAKE THEM
DRAMATICALLY EASIER TO FIND AND
REMOVE
- Martin Fowler, Chief Scientist, ThoughtWorks
By integrating regularly, you can detect errors quickly, and
locate them more easily.
4
12. How Does CI help
• Help you build the right thing
RELEASE
GET
FEEDBACK
IMPROVED
Release small chunks of
functionality frequently
Get regular
customer/tester validation
Incorporate feedback
rapidly
Fail fast learn fast
12
14. How Does CI help
• Deliver “real” progress
– “Done” is not longer “dev-complete”, but is
thoroughly validated as only a release can
• Release checklist
– Integration testing
– Unit testing
– User acceptance testing
– Performance testing
– Security testing
– …
14
16. Architecture of a CI Build System
The key to fixing problems quickly is finding them quickly.
– (Fowler, 2006)
16
17. Architecture of a CI Build System
The key to fixing problems quickly is finding them quickly.
– (Fowler, 2006)
More than a process
Continuous Integration is backed by several important principles and practices.
17
18. The practice
• Maintain a single source repository
• Automate the build
• Make your build self-testing
• Every commit should build 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
18
19. How to do it
• Developers check out code into their private workspaces.
• When done, the commit changes to the repository.
• The CI server monitors the repository and checks out changes
when they occur.
• The CI server builds the system and runs unit and integration
tests.
• The CI server releases deployable artefacts for testing.
• The CI server assigns a build label to the version of the code it
just built.
• The CI server informs the team of the successful build.
• If the build or tests fail, the CI server alerts the team.
• The team fix the issue at the earliest opportunity.
• Continue to continually integrate and test throughout the project.
19
20. Team Responsibilities
• Check in frequently
• Don’t check in broken code
• Don’t check in untested code
• Don’t check in when the build is broken
• Don’t go home after checking in until the
system builds
20
21. Tools of CI
• A comprehensive and up-to-date listing of the
many open source and commercial CI build
servers
– http://confluence.public.thoughtworks.org/displa
y/CC/CI+Feature+Matrix
– At this time, 25 products are compared on dozens
of attributes.
– Identifies the most important features for
companies and projects involved in the developing
CI build servers.
The most important criterion in choosing a tool is whether it does what you need it to do.
-- Duvall et al. (2007)
21
24. Tools of CI
Ref: http://java.dzone.com/node/28241/results Ref:http://www.wakaleo.com/resources/polls
Total vote: 643
First Vote: 2010/02/12
Last Vote: 2011/03/08
24
26. Jenkins vs. Hudson
• Jenkins: Original Hudson team
• Hudson: Oracle and Sonatype
26
27. What’s Jenkins/Hudson
• An open source CI server
• More then 23000 installations (Jul 2010)
• Plug-in extensibility (Over 370 plugins)
• MIT license
• Written in Java
• Available for Windows, Mac and Linux
• Runs as Servlet in Tomcat or standalone
27
28. Jenkins Features
• Trigger a build
• Get source code from repository
• Automatically build and test
• Generate report & notify
• Deploy
• Distributed build
28
33. Distributed Builds
• Master/slave architecture
• Start Master-only, add slaves later
• Slave: an agent running on the same
• machine or different machine and builds on
• behalf of the master
• Slaves can be different platforms
• Allows build/testing on different OSes
33
34. Jenkins Benefits
• Never gets bored doing builds and tests
• Catches problems fast: rapid feedback
• Alerts developers while code is fresh in their
minds
• Prevents bugs from propagating downstream
• Cheaper to fix bugs earlier, before QA or
Deployment
34
36. Barriers of CI
• Why doesn't every team already practice CI?
– It is not easy.
– Establishing a solid CI practice takes a lot of work and
technical knowledge.
– A number of new tools and processes must be mastered.
– Setting up a CI server requires that the build, unit test, and
executable packaging processes all be automated.
– Requires mastering a build scripting language, a unit
testing platform, and potentially a setup/install platform as
well.
36
49. Continuous Deployment
• Continuous Deployment is closely related to Continuous Integration
and refers to the release into production of software that passes
the automated tests.
• Essentially, “it is the practice of releasing every good build to users,”
explains Jez Humble, author of Continuous Delivery.
• By adopting both Continuous Integration and Continuous
Deployment, you not only reduce risks and catch bugs quickly, but
also move rapidly to working software.
• With low-risk releases, you can quickly adapt to business
requirements and user needs. This allows for greater collaboration
between ops and delivery, fuelling real change in your organisation,
and turning your release process into a business advantage.
49
By integrating regularly, you can detect errors quickly, and locate them more easily.
Many teams develop rituals around these policies, meaning the teams effectively manage themselves, removing the need to enforce policies from on high.
Jenkins was originally developed as the Hudson project. Hudson's creation started in summer of 2004 in Sun Microsystems. It was first released in java.net in Feb. 2005
Around 2007 Hudson became known as a better alternative to CruiseControl and other open-source build-servers.[2][5] At the JavaOne conference in May 2008 the software won the Duke's Choice Award in the Developer Solutions category
During November 2010, an issue arose in the Hudson community with respect to the infrastructure used, which grew to encompass questions over the stewardship and control by Oracle.[7] Negotiations between the principal project contributors and Oracle took place, and although there were many areas of agreement a key sticking point was the trademarked name "Hudson",[8] after Oracle claimed the right to the name and applied for a trademark in December 2010.[9] As a result, on January 11, 2011, a call for votes was made to change the project name from "Hudson" to "Jenkins".[10] The proposal was overwhelmingly approved by community vote on January 29, 2011 creating the Jenkins project.[11][12]
On February 1, 2011, Oracle said that they intended to continue development of Hudson, and considered Jenkins a fork rather than a rename.[13] Jenkins and Hudson therefore continue as two independent projects, each claiming the other is the fork. As of 22 January 2013, the Jenkins organisation on GitHub had 431 project members and 890 public repositories,[14] Hudson 33 project members and 82 public repositories.[15] The one month bug statistics were similarly proportioned: for Jenkins 250 bugs were opened and 170 closed, for Hudson 0 bugs were opened and 6 closed the previous thirty days.
In 2011, creator Kohsuke Kawaguchi received a Google-O'Reilly Open Source Award for his work on the Hudson/Jenkins project.
