Continuous

Integration &
Deployment
Jenkins

 Jenkins is an open source automation tool written in Java

programming language that allows continuous integration.
 Jenkins builds and tests our software projects, which continuously
making it easier for developers to integrate changes to the project,
and making it easier for users to obtain a fresh build.
What is Jenkins?
 Jenkins builds and tests our software projects which continuously making it easier for
developers to integrate changes to the project, and making it easier for users to
obtain a fresh build.
 It also allows us to continuously deliver our software by integrating with a large
number of testing and deployment technologies.
 Jenkins offers a straightforward way to set up a continuous integration or continuous
delivery environment for almost any combination of languages and source code
repositories using pipelines, as well as automating other routine development tasks.
 With the help of Jenkins, organizations can speed up the software development
process through automation. Jenkins adds development life-cycle processes of all
kinds, including build, document, test, package, stage, deploy static analysis and
much more.
 Jenkins achieves CI (Continuous Integration) with the help of plugins. Plugins is used to
allow the integration of various DevOps stages. If you want to integrate a particular
tool, you have to install the plugins for that tool. For example: Maven 2 Project, Git,
HTML Publisher, Amazon EC2, etc.
 For example: If any organization is developing a project, then Jenkins will
continuously test your project builds and show you the errors in early stages of your
development.
Possible steps executed by Jenkins are for example:
 Perform a software build using a build system like Gradle or Maven Apache
 Execute a shell script
 Archive a build result
 Running software tests
History of Jenkins
 Kohsuke Kawaguchi, who is a Java developer, working at SUN Microsystems, was tired
of building the code and fixing errors repetitively. In 2004, he created an automation
server called Hudson that automates build and test task.
 In 2011, Oracle who owned Sun Microsystems had a dispute with Hudson open source
community, so they forked Hudson and renamed it as Jenkins.
 Both Hudson and Jenkins continued to operate independently. But in short span of
time, Jenkins acquired a lot of contributors and projects while Hudson remained with
only 32 projects. Then with time, Jenkins became more popular, and Hudson is not
maintained anymore.
What is Continuous Integration?
 Continuous Integration (CI) is a development practice in which the developers needs
to commit changes to the source code in a shared repository at regular intervals.
Every commit made in the repository is then built. This allows the development teams
to detect the problems early.
 Continuous integration requires the developers to have regular builds. The general
practice is that whenever a code commit occurs, a build should be triggered.
Continuous Integration with Jenkins
 Let's consider a scenario where the complete source code of the application was built
and then deployed on test server for testing. It sounds like a perfect way to develop
software, but this process has many problems.
 Developer teams have to wait till the complete software is developed for the test results.
 There is a high prospect that the test results might show multiple bugs. It was tough for
developers to locate those bugs because they have to check the entire source code of the
application.
 It slows the software delivery process.
 Continuous feedback pertaining to things like architectural or coding issues, build failures,
test status and file release uploads was missing due to which the quality of software can go
down.
 The whole process was manual which increases the threat of frequent failure.
 Jenkins is the most mature Continuous Integration tool available.
 Let's see a generic flow diagram of Continuous Integration with Jenkins:
 First of all, a developer commits the code to the source code repository. Meanwhile,
the Jenkins checks the repository at regular intervals for changes.
 Soon after a commit occurs, the Jenkins server finds the changes that have occurred
in the source code repository. Jenkins will draw those changes and will start preparing
a new build.
 If the build fails, then the concerned team will be notified.
 If built is successful, then Jenkins server deploys the built in the test server.
 After testing, Jenkins server generates a feedback and then notifies the developers
about the build and test results.
 It will continue to verify the source code repository for changes made in the source
code and the whole process keeps on repeating.
Advantages of Jenkins
 It is an open source tool.
 It is free of cost.
 It does not require additional installations or components. Means it is easy to install.
 Easily configurable.
 It supports 1000 or more plugins to ease your work. If a plugin does not exist, you can
write the script for it and share with community.
 It is built in java and hence it is portable.
 It is platform independent. It is available for all platforms and different operating
systems. Like OS X, Windows or Linux.
 Easy support, since it open source and widely used.
 Jenkins also supports cloud based architecture so that we can deploy Jenkins in cloud
based platforms.
Disadvantages of Jenkins
 Its interface is out dated and not user friendly compared to current user interface
trends.
 Not easy to maintain it because it runs on a server and requires some skills as server
administrator to monitor its activity.
 CI regularly breaks due to some small setting changes. CI will be paused and therefore
requires some developer's team attention.
Jenkins Architecture
 Jenkins follows Master-Slave architecture to manage distributed
builds. In this architecture, slave and master communicate
through TCP/IP protocol.
 Jenkins architecture has two components:
 Jenkins Master/Server
 Jenkins Slave/Node/Build Server
Jenkins Master
 The main server of Jenkins is the Jenkins Master. It is a web dashboard which is
nothing but powered from a war file. By default it runs on 8080 port. With the help of
Dashboard, we can configure the jobs/projects but the build takes place in
Nodes/Slave. By default one node (slave) is configured and running in Jenkins server.
We can add more nodes using IP address, user name and password using the ssh, jnlp
or webstart methods.
 The server's job or master's job is to handle:
 Scheduling build jobs.
 Dispatching builds to the nodes/slaves for the actual execution.
 Monitor the nodes/slaves (possibly taking them online and offline as required).
 Recording and presenting the build results.
 A Master/Server instance of Jenkins can also execute build jobs directly.
Jenkins Slave
 Jenkins slave is used to execute the build jobs dispatched by the
master. We can configure a project to always run on a particular
slave machine, or particular type of slave machine, or simple let
the Jenkins to pick the next available slave/node.
 As we know Jenkins is developed using Java is platform
independent thus Jenkins Master/Servers and Slave/nodes can
be configured in any servers including Linux, Windows, and Mac.
Continuous Deployment

 Continuous Deployment (CD) is a strategy whereby software testing

and sendoff to consumers is automated. It’s a way to make the
CI/CD pipeline faster, more efficient, and more agile — and give
customers what they want, when they want it.
 In essence, Continuous Deployment is the automation of the
deployment process, whereby changes to software code are tested
and deployed automatically.
 Continuous Deployment, the entire deployment process is
automated, from code review to deployment to a live environment.
Once the new code is tested and validated, it’s sent out to a live
environment.
Benefits of Continuous Deployment
 It saves time. It’s no secret that automation, if done correctly, can save a massive
amount of time — even as much as months — in the release of software changes.
 It saves money. Being able to push changes quicker leads to a happier consumer, and
happier consumers mean repeat business.
 It allows for flexibility. Listening to customer feedback regarding a specific application
and matching that with a quick turnaround time for release makes all the difference in
the software world, and the business world, too. CD gives developers the ability to
listen to consumers, and fix bugs, errors and other issues quickly and efficiently.
Continuous Deployment Tools
 Version control: This is part of the CI portion of the pipeline, as it tracks the changes
and revisions made to your asset, but it’s essential in making sure the CD part of the
pipeline goes smoothly. Version control makes sure the updates are visible across the
board.
 Configuration management: This refers to the process of ensuring all applicable
hardware and software are, in essence, speaking the same language.
 Infrastructure monitoring: Monitoring tools help you see how your back-end
changes are translating in the “real world,” or live environment.
 Automated testing: It wouldn’t be the CI/CD pipeline without it. Automated testing
is the backbone of the pipeline.
 Monitoring/alerts: Alerts are needed to trigger automatic rolling deployments if a
failed deploy needs to be reverted.
What is Vagrant? – Managing Virtual Environments
 Vagrant is an open source tool for managing virtual environments. That’s why you run
Vagrant with another tool like Virtual Box. Its goal is to solve the problems we just
discussed by allowing you to spin up virtual machines that are exactly the same every
time.
 You can be sure that the virtual machine you are running on your local machine is
exactly the same as the one you’re running on your staging or production server.
 Once you’ve used Vagrant (and another tool like Virtual Box) to set up a virtual server,
you run a provisioning script exactly the same on each machine. The provisioning
script will:
 Install the correct programs you need (e.g. Node.JS, PHP, etc);
 Correctly set up user permissions;
 Configure everything;
 Install anything else your application requires.
 What you end up with is essentially the same environment wherever you set up a
virtual machine with Vagrant.
 You can also push your Vagrant file and code to GitHub
What is Docker? – Containerized Applications
 One of the drawbacks of using Vagrant is you have to run an entire virtual machine to
run your application. This is very resource-intensive and can take a long time to set up
and run the provisioning script.
 Docker takes a different approach. You use a Docker file (a small ~5-30 line file) to
create a Docker image. This Docker image contains:
 All of your project code;
 Installments of anything you need (Node.JS, Rails, etc);
 Any configurations you need.
 It’s basically your complete application and all of its dependencies wrapped up into
one neat package. Then you can run this image as a container on any machine
running Docker. You don’t need a new virtual machine for each container, just one, as
they are designed to run on top of a machine.
 Then, you can run as many Docker containers as you like on that virtual machine – as
long as you have enough processing power and RAM.
 You could run a Docker container of a Rails app with a Rails installation bundled up
into it, while also running a container of a Node.JS application. You wouldn’t need to
install Rails or Node. Both would have their own installations contained within them.
 They are completely separate from each other but share an operating system kernel.
Main Differences – Vagrant vs Docker
 Vagrant sets up a predictable, repeatable environment (e.g. a virtual machine) for you
to run your application. You run your code into an environment and can expect it to
behave a certain way.
 Docker allows you to create images that ARE your project code. You use a Docker
image to build an environment that you can run anywhere. If you can run Docker, you
can run your application and it will work every time.
 Vagrant helps you set up entire virtual machines to run your applications, while
Docker helps you manage containers that can run on top of a virtual machine.