Whitepaper: Continuous Integration Using Jenkins
Whitepaper: Continuous Integration Using Jenkins
2. Introduction 3
3. Problem Statement 4
7. Continuous Testing 6
13 Key Benefits of CI 21
14 Success Story 22
15 Future Vision 22
16 Conclusion 23
17 References 23
1 Abstract
In a software development project, it is a natural process for several developers and testers to work on
different modules. Each developer or tester will be assigned a different module, so it is extremely important
to test and build the modules to ensure they work seamlessly with each other, with zero bug interference.
Frequent changes in code? Multiple code check-ins? Manual testing? Multiple integrations? Continuous
Integration (CI) is here to rescue.
CI is a practice that requires developers to integrate their code into a shared repository frequently, which
leads to multiple integrations per day by different developers. The goal here is to ensure that every change
in the code is built and tested immediately by an automated build, which in turn gives an instant picture if
something breaks.
This white paper will explain how we achieve continuous integration & automation, using Selenium as test
automation tool, Jenkins as CI tool, GitHub as a shared repository, and JIRA as Defect management tool.
Major takeaways from this paper would be adoption to part of Devops, its seamless integration, and
automation process and its benefits.
2 Introduction
Over the last two decades, software industries are following a traditional way of delivering frequent changes
in software development process, which has its own limitations/problems like missing on deadlines, more
time to market, poor quality of product, etc.
With technology innovations continuously growing, overcoming some of these limitations, software
industries have caught up with the latest digital trends. One of which is Continuous Integration, which is an
emerging game changer and surpasses the challenges faced with traditional software development
process.
Continuous Integration (CI) primarily deals with the automation of development processes, and build/code
integration/test automation. CI becoming such a well-accepted development practice, has also proved how
much more productive the development process can be with automation. It has become the catalyst for
continuous delivery (CI) practices - extending the automation through the entire software pipeline, through
staging and into production.
This paper is intended for beginners to get the overall understanding of CI, Continuous Deployment and
Continuous Delivery, how small/large enterprises leverage CI/CD, and how the road to Continuous
Integration/CD is paved with its own set of challenges.
3 Problem Statement
Traditional way of delivering rapid changes in software development projects consists of:
‘Release Meetings’
where everyone takes Multiple Integration
Intermittent Code working only on Go- No-Go decision of and operations
integration developer machines the build problems
All these results in poor quality of the product, more time to market, more cost, less customer satisfaction,
and ultimately adding less value to business.
Build
Deploy
Deploy
to Prod
Test
Deploy to
Staging
• Everyone commits to the mainline every day • Make it easy for anyone to get the latest
executable
• Every commit should build the mainline on an
integration machine • Automate deployment
7 Continuous Testing
Continuous Testing is integral part of CI process. Each time some code changes happen and checked in into
a shared repository, an automated test suite run, which is developed using any automation testing tool like
Selenium. This complete process can be achieved using CI tool like Jenkins.
Selenium automates browsers support different languages like Java, Python, Ruby, php, perl and javascript
with different browsers and operating systems. We use Selenium in conjunction with continuous
integration, to ensure web applications are automatically tested via scripts as opposed to manually. Selenium
can be used with TestNG, which is a rich testing framework and used for reporting, parallel testing, grouping
test of cases, etc.
Maven project can be created for writing script and creating dependency-using POM.xml once dependency
is set, Maven will download all the dependent jar files automatically. Maven also automates process of
creating initial project structure.
Information such as name of the project, artifact id, group id, .xml file path, plugin details like Surefire plugin,
fortysix plugin to send an automatic email after build success, etc.is mentioned in pom.xml file as depicted
below:
Dependencies
Dependencies are the libararies, which are required by the project. For example Log4j jars, Apache Poi jars,
Selenium Jars, etc. Dependencies are mentioned in the pom.xml like this.
Advantages of Jenkins
As an extensible automation server, Jenkins can be used as a simple CI server or turned into the continuous
delivery hub for any project.
• Easy installation
Jenkins is a self-contained Java-based program, ready to run out-of-the-box, with packages for Windows,
Mac OS X and other Unix-like operating systems.
• Easy configuration
Jenkins can be easily set up and configured via its web interface, which includes on-the-fly error checks and
built-in help.
• Distributed
Jenkins can easily distribute work across multiple machines, helping drive builds, tests and deployments
across multiple platforms faster.
Because of all above advantages of Jenkins, it is preferred over other CI tools, which are mentioned below.
Advantages of Jenkins
Apart from Jenkins, there are several tools for Continuous Integration, and most of them are open source.
• Bamboo • Travis CI
It is distributed and disconnected i.e. every checkout is actually a clone of master repository and every
developer has its own repository with its own branches and own commits. We can clone working the copy
of a local repository from Git server, which can also add and commit the test scripts that are developed locally
and push our changes to the Git.
Git is also used by the Ops team as a version control for automation to store scripts, tools and software
configuration.
The most important concept of Git is Branching and Merging. Developers can work on their own feature
branch without disturbing others work. Branches are very easy to create and merge back. Since these
branches are local, these can be used all the time.
Developers make some local changes and commit these changes locally using ‘git commit’ command.
Before Pushing
Origin/Master
Master
These local changes can be shared with the team and sent to the central repository or master branch, using
‘git push’ command as depicted in the below fig. Another team member can now retrieve the changes using
‘git pull’ command.
After Pushing
Origin/Master
Master
Branches are the widely used feature in Git. Developers work on their own feature branch so that they don’t
disturb anyone else who is also implementing some features. As shown in the given diagram Master branch
is in blue, a little feature branch in purple and big feature branch in green. At some point, these branches are
merged to master branch using ‘git merge’ command.
Origin/Master
Master
Big feature
• SVN • Bazaar
Software development project involves multiple developers constantly working and pushing code files, that
need to be orchestrated together to build a product. The best practice is to keep a revision control system or
tool in place that helps the team to keep the latest and clean code in the repository at any point in the
development process. Below is the snapshot of Github, where codebase is placed.
The key aspect is to avoid keeping everything in the automated build. The build automation ensures that the
development team only works on the latest source code from the repository, and compiles it every time to
build the final product. We make Jenkins to periodically pull the project’s source code from the remote Git
Server by installing GitHub plugin, and by specifying the source code path of project in Source code
management section of Jenkins.
In order to execute our test cases automatically in build process, we should keep our test suite ready. Here
Selenium Webdriver is used with TestNG + Maven and test cases are automated using Hybrid Framework.
Once Maven is integrated with Selenium, pom.xml file is created where all project configuration details are
mentioned. It also provides initial folder structure as below.
After execution of the test scripts, it is very important have a snapshot of our execution status as in no. of test
cases passed, failed, skipped, time required to run the test, etc. Extent report, along with TestNG, helps us for
providing this status in very user-friendly way as shown in the screenshot below.
For self-testing code, we need a suite of automated tests that can check a large part of the code base for a
bug. A good way to catch bugs more quickly and efficiently, is to include automated tests in the build
process. The tests should be able to be kicked-off from a simple command and to be self-checking. Here
executable pom.xml path is given build section of Jenkins.
If the build is slow, then it would indicate a problem in the entire Continuous Integration process. CI ensures
that the builds are fast, and always limited to duration.
Scheduling Build
Jenkins has an ability to schedule the builds based on different configurations. From Build Triggers, Jenkins
can monitor the repository and start a build whenever any changes have been committed by choosing Poll
SCM option and entering syntax of cron. We can also schedule a nightly build by selecting a periodical
option and providing cron pattern. Project can also be built after other projects are built successfully through
‘Build after other projects are built’ option.
To verify the status of a build, once the build is triggered, we can check for the console output. It will show
something like the below image, which has information like who started and from where the build is
triggered, and build success or failure status, etc.
We can publish automated HTML reports in JIRA through Jenkins, by installing HTML Publisher plugin, and
by configuring Zephyr for JIRA Test Management plugin as a post build action. Provide report URL path as a
post build action in ‘Publish HTML report’ section.
Provide Jira URL in ‘Publish test result to Zephyr for JIRA’ section as post build action as below:
Emails can also be triggered to a respective person after every build run by providing some email
configurations like SMTP server, Port no., username and password for authentication in ‘Email notification’
section in Jenkins as follows:
Automated deployment allows developers to push the product to various environments quickly and save a
lot of time. This can be done through ‘Copy artifact’ and ‘deploy to container’ plugins of Jenkins. Here we
have created a separate job (Deploy to staging) to deploy the application to staging environment, which is a
Tomcat server. In the Copy artefact section, we need to give project name and artifacts to copy as shown
below.
And in Deploy to container, need to specify container details of staging and artifacts to deploy:
Now ‘Deploy to staging’ job will be automatically triggered, if upstream job runs successfully. This can be
achieved by adding post build action to upstream job to trigger downstream job as follows:
When no. of jobs (which are connected to each other) increases in Jenkins, it becomes difficult to understand
the pipeline. To visualise these pipelines and to understand how they are connected, we have Jenkins ‘Build
Pipeline’ plugin. It offers build pipeline view of all upstream and downstream jobs.
Create new view on Jenkins home page as ‘Build Pipeline view’, and configure the initial job to be triggered.
This is how we can see build pipeline view of all upstream and downstream jobs:
Deploy to Production
This is a final stage of build pipeline to deploy our application to production. This process can be automated,
or can be done manually. We can create Production deployment environment by spinning new Tomcat
server. This can be achieved by replicating staging environment binaries and configuration files from staging
to production environment.
Now created another job called ‘Deploy to Prod’ to deploy our code in production environment and gave
same configuration as Staging job like war file to be deployed and deploy to container as a post build action.
This job should be triggered manually after ‘deploy to staging job’ completes successfully. This can be done
by selecting ‘Build other projects (manual step)’ as a post build action in the “deploy to staging upstream” job.
And now, when we build the initial job which is our selenium test suite, all other dependent jobs will run
automatically except ‘deploy to prod’ as shown below. Other jobs are shown in green means they are
completed successfully and “deploy to prod” is shown in blue, because this job is configured to trigger
manually.
13 Key Benefits of CI
Saves Time
Adds Consistency
14 Success Story
In our project, we have Bi-monthly releases which consists a lot of manual efforts for unit testing,
deployment to different environments, system testing, staging deployment, etc. With implementation of CI,
manual efforts are cut down by 75%, by automating complete process right from unit testing till deployment
to staging.
Before CI, the team used to fix the bugs once QA testing is in progress. With implementation of CI, bugs got
detected as and when the code got checked in, in the repository and helped in eliminating 75% of the
development efforts.
Deployment cost
AES team (deployment team) used to take 4 hrs. for deployment per release, which is now reduced to 10 mins.
Cost of delay
Before CI, features are held on average 6 weeks after development completion before they are released.
Now with CI in place features are released as and when they are ready..
15 Future Vision
In the future, CI will have an even greater influence than it has today. Automated environment and
infrastructure creation and provisioning for cloud-based systems will mature fast. Tools like Puppet, Chef and
Capistrano making automated provisioning a reality. Containers, Automated deployment, etc. are another
area seeing growing adoption. Expected to have tool that grabs stack traces from production logs, and do
reverse engineering of the code to auto generate the test cases in our suite. Move from Continuous
Integration to Continuous Delivery, and deployment is the future.
16 Conclusion
In this white paper, we introduced Continuous Integration, Continuous Delivery and discussed how they can
be used to build and release well-tested software safely and quickly, and create a better product for the
customer, which is the real promise of agility. These processes leverage extensive automation and encourage
constant code sharing to fix defects early. While the techniques, processes, and tools needed to implement
these solutions represent a significant challenge, the benefits of a well-designed and properly used system
are enormous.
17 References
• https://dzone.com/articles
• https://jenkins.io/doc/
• https://www.tutorialspoint.com/jenkins/jenkins_overview.htm
• https://en.wikipedia.org/wiki/Jenkins
LTI (NSE: LTI, BSE: 540005) is a global technology consulting and digital solutions Company helping more than 250
clients succeed in a converging world. With operations in 27 countries, we go the extra mile for our clients and
accelerate their digital transformation with LTI’s Mosaic platform enabling their mobile, social, analytics, IoT and cloud
journeys. Founded 20 years ago as a subsidiary of Larsen & Toubro Limited, our unique heritage gives us unrivaled
real-world expertise to solve the most complex challenges of enterprises across all industries. Each day, our team of
more than 20,000 LTItes enable our clients to improve the effectiveness of their business and technology operations,
and deliver value to their customers, employees and shareholders. Find more at www.Lntinfotech.com or follow us at
@LTI_Global