Continuous integration with Jenkins

Continuous
Integration
with
Jenkins
Mohammad Hossein Rimaz
K.N. Toosi University of Technology

Table of Contents
• Continuous Integration Fundamentals
• History
• Why Jenkins?
• Continuous Integration Step by Step
• 9 Benefits of Continuous Integration
• Getting Started with Jenkins
• Q&A

Continuous Integration Fundamentals
Continuous Integration, in its simplest form, involves a tool that
monitors your version control system for changes.
Whenever a change is detected, this tool automatically compiles
and tests your application.
If something goes wrong, the tool immediately notifies the
developers so that they can fix the issue immediately.

But Continuous Integration can do much more than this. Continuous
Integration can also help you keep tabs on the health of your code
base, automatically monitoring code quality and code coverage
metrics, and helping keep technical debt down and maintenance costs
low.
Combined with automated end-to-end acceptance tests, CI can also
act as a communication tool, publishing a clear picture of the current
state of development efforts.
And it can simplify and accelerate delivery by helping you automate
the deployment process, letting you deploy the latest version of your
application either automatically or as a one-click process.

In essence, Continuous Integration is about reducing risk by providing
faster feedback. First and foremost, it is designed to help identify and
fix integration and regression issues faster, resulting in smoother,
quicker delivery, and fewer bugs.
By providing better visibility for both technical and non-technical team
members on the state of the project, Continuous Integration can open
and facilitate communication channels between team members and
encourage collaborative problem solving and process improvement.
And, by automating the deployment process, Continuous Integration
helps you get your software into the hands of the testers and the end
users faster, more reliably, and with less effort.

But Continuous Integration is a mindset as much as a toolset. To
get the most out of CI, a team needs to adopt a CI mentality.
For example, your projects must have a reliable, repeatable, and
automated build process, involving no human intervention.
Fixing broken builds should take an absolute priority, and not be left to
stagnate.
The deployment process should be automated, with no manual steps
involved.
And since the trust you place in your CI server depends to a great
extent on the quality of your tests, the team needs to place a very
strong emphasis on high quality tests and testing practices.

History
Jenkins is the result of one visionary developer, Kohsuke Kawaguchi, who
started the project as a hobby project under the name of Hudson in late
2004 whilst working at Sun.
By early 2008, Sun recognized the quality and value of the tool, and ask
Kohsuke to work on Hudson full-time, starting to provide professional
services and support around Hudson.
In 2009, Oracle purchased Sun. Indeed, Oracle wanted to move towards a
more strictly controlled development process with a slower release schedule,
whereas most of the core Hudson developers, led by Kohsuke, preferred to
continue with the open, flexible, and fast-paced community-focused model
that had worked so well for Hudson in the past.
In January 2011, the Hudson developer community decisively voted to
rename the project to Jenkins.

Why Jenkins?
So what has made Jenkins such a success? And why use Jenkins for
your CI infrastructure?
Firstly, Jenkins is easy to use. The user interface is simple, intuitive,
and visually appealing, and Jenkins as a whole has a very low learning
curve.
However Jenkins does not sacrifice power or extensibility: it is also
extremely flexible and easy to adapt to your own purposes.
Hundreds of open source plugins are available, with more coming out
every week. These plugins cover everything from version control
systems, build tools, code quality metrics, build notifiers, integration
with external systems, UI customization, games, and much more. And
installing them is quick and easy.

Why Jenkins?
Last, but certainly not least, much of Jenkins’s popularity comes
from the size and vibrancy of its community. The Jenkins
community is a large, dynamic, reactive and welcoming bunch,
with passionate champions, active mailing lists, IRC channels and
a very vocal blog and twitter account. The development pace is
fast, with releases coming out weekly with the latest new features,
bug fixes, and plugin updates.

Continuous Integration Step by Step
Phase 1 — No Build Server
Initially, the team has no central build server of any kind.
Software is built manually on a developer’s machine, though it
may use an Ant script or similar to do so. Source code may be
stored in a central source code repository, but developers do not
necessarily commit their changes on a regular basis.
Some time before a release is scheduled, a developer manually
integrates the changes, a process which is generally associated
with pain and suffering.

Phase 2 — Nightly Builds
In this phase, the team has a build server, and automated builds
are scheduled on a regular (typically nightly) basis.
This build simply compiles the code, as there are no reliable or
repeatable unit tests. Indeed, automated tests, if they are written,
are not a mandatory part of the build process, and may well not
run correctly at all.
However developers now commit their changes regularly, at least
at the end of every day. If a developer commits code changes that
conflict with another developer’s work, the build server alerts the
team via email the following morning

Phase 3 — Nightly Builds and Basic Automated Tests
The team is now starting to take Continuous Integration and
automated testing more seriously.
The build server is configured to kick off a build whenever new
code is committed to the version control system, and team
members are able to easily see what changes in the source code
triggered a particular build, and what issues these changes
address.
In addition, the build script compiles the application and runs a
set of automated unit and/or integration tests.

Phase 4 — Enter the Metrics
Automated code quality and code coverage metrics are now
run to help evaluate the quality of the code base and (to some
extent, at least) the relevance and effectiveness of the tests.
The code quality build also automatically generates API
documentation for the application.
All this helps teams keep the quality of the code base high,
alerting team members if good testing practices are slipping. The
team has also set up a “build radiator,” a dashboard view of the
project status that is displayed on a prominent screen visible to all
team members.

Phase 5 — Getting More Serious About Testing
The benefits of Continuous Integration are closely related to solid
testing practices.
Now, practices like Test-Driven Development are more widely
practiced, resulting in a growing confidence in the results of the
automated builds.
The application is no longer simply compiled and tested, but if
the tests pass, it is automatically deployed to an application
server for more comprehensive end-to-end tests and
performance tests.

Phase 6 — Automated Acceptance Tests and More Automated
Deployment
Acceptance-Test Driven Development is practiced, guiding development
efforts and providing high-level reporting on the state of the project.
These automated tests use Behavior-Driven Development and
Acceptance-Test Driven Development tools to act as communication and
documentation tools and documentation as much as testing tools,
publishing reports on test results in business terms that non-developers can
understand.
Since these high-level tests are automated at an early stage in the
development process, they also provide a clear idea of what features have
been implemented, and which remain to be done. The application is
automatically deployed into test environments for testing by the QA team
either as changes are committed, or on a nightly basis.

Phase 7—Continuous Deployment
Confidence in the automated unit, integration and acceptance
tests is now such that teams can apply the automated
deployment techniques developed in the previous phase to push
out new changes directly into production.

9 Benefits of Continuous Integration [1]
1. Manual Tests Are Only a Snapshot
How many times have you heard a team member say “it worked
locally.” In their defense, it likely did work locally. However, when
they tested it locally they were testing on a snapshot of your code
base and by the time they pushed, things changed. Continuous
Integration tests your code against the current state of your code
base and always in the same (production-like) environment, so
you can spot any integration challenges right away.

9 Benefits of Continuous Integration
2. Increase Your Code Coverage
Think your tests cover most of your code? Well, think again. A CI
server can check your code for test coverage. Now, every time
you commit something new without any tests, you will feel the
shame that comes with having your coverage percentage go
down because of your changes. Seeing code coverage increase
over time is a motivator for the team to write tests.

4. Deploy Your Code to Production
A CI system can automatically deploy your code to staging or
even production if all the tests within a specific branch are green.
This is what is formally known as Continuous Deployment.
Changes before being merged can be made visible in a dynamic
staging environment, and once they are merged these can be
deployed directly to a central staging, pre-production, or
production environment.

5. Build Stuff Now
All your tests are green and the coverage is good, but you don’t
handle code that needs to be deployed? No worries! CI servers
can also trigger build and compilation processes that will take
care of your needs in no time. No more having to sit in front of
your terminal waiting for the build to finish, only to have it fail at
the last second. You can run any long-running processes as a part
of your CI builds and the CI system will notify you if anything
goes wrong, even restarting or triggering certain processes if
needed.

6. Build Stuff Faster
With parallel build support, you can split your tests and build
processes over different machines (VMs/containers), so the total
build time will be much shorter than if you ran it locally. This also
means you’ll consume fewer local resources, so you can continue
working on something else while the builds run.

7. Never Ship Broken Code
Using continuous integration means that all code is tested and
only merged when all tests pass. Therefore, it’s much less likely
that your master builds are broken and broken code is shipped to
production. In the unlikely event that your master build is broken,
let your CI system trigger a warning to all developers: some
companies install a little warning light in the office that lights up if
this happens!

8. Decrease Code Review Time
You can have your CI and Version Control System communicate
with each other and tell you when a merge request is good to
merge: the tests have passed and it meets all requirements. In
addition, even the difference in code coverage can be reported
right in the merge request. This can dramatically reduce the time
it takes to review a merge request.

9. Build Repeatable Processes
Today’s pace of innovation requires development teams to deliver
high-quality software faster than their competition. Modern
development teams are building ef cient software delivery
engines by creating repeatable processes that standardize
development best practices. With automated testing, your code is
tested in the same way for every change, so you can trust that
every change is tested before it goes to production.

References
[1] - https://dzone.com/articles/9-bene-ts-of-continuous-
integration
[2] - Jenkins: The Definitive Guide by John Ferguson Smart (2011),
O'Reilly Media

Continuous integration with Jenkins

More Related Content

What's hot (19)

Similar to Continuous integration with Jenkins (20)

More from Mohammad Hossein Rimaz (7)

Recently uploaded (20)

Continuous integration with Jenkins