Jenkins offers a simple way to set up a continuous integration or continuous delivery (CI/CD) environment for almost any combination of languages and source code repositories using pipelines, as well as automating other routine development tasks. While Jenkins doesn’t eliminate the need to create scripts for individual steps, it does give you a faster and more robust way to integrate your entire chain of build, test, and deployment tools than you can easily build yourself.
“Don’t break the nightly build!” is a cardinal rule in software development shops that post a freshly built daily product version every morning for their testers. Before Jenkins, the best a developer could do to avoid breaking the nightly build was to build and test carefully and successfully on a local machine before committing the code. But that meant testing one’s changes in isolation, without everyone else’s daily commits. There was no firm guarantee that the nightly build would survive one’s commit.
Hudson and Jenkins
In 2004, Kohsuke Kawaguchi was a Java developer at Sun. Kawaguchi became tired of breaking builds in his development work and wanted to find a way to know, before committing code to the repository, whether the code was going to work. So Kawaguchi built an automation server in and for Java to make that possible, called Hudson. Hudson became popular at Sun, and spread to other companies as open source.
Fast-forward to 2011, and a dispute between Oracle (which had acquired Sun) and the independent Hudson open source community led to a fork with a name change, Jenkins. In 2014 Kawaguchi became CTO of CloudBees, which offers Jenkins-based continuous delivery products.
Both forks continued to exist, although Jenkins was much more active. Today, the Jenkins project is still active. The Hudson website was closed down on Jan 31, 2020.
In March 2019 the Linux Foundation, along with CloudBees, Google, and a number of other companies, launched a new open source software foundation called the Continuous Delivery Foundation (CDF). Jenkins contributors decided that their project should join this new foundation. Kawaguchi wrote at the time that nothing of significance would change for users.
Jenkins automation
Today Jenkins is the leading open-source automation server with some 1,600 plug-ins to support the automation of all kinds of development tasks. The problem Kawaguchi was originally trying to solve, continuous integration and continuous delivery of Java code (i.e. building projects, running tests, doing static code analysis, and deploying) is only one of many processes that people automate with Jenkins. Those 1,600 plug-ins span five areas: platforms, UI, administration, source code management, and, most frequently, build management.
How Jenkins works
Jenkins is distributed as a WAR archive and as installer packages for the major operating systems, as a Homebrew package, as a Docker image, and as source code. The source code is mostly Java, with a few Groovy, Ruby, and Antlr files.
You can run the Jenkins WAR standalone or as a servlet in a Java application server such as Tomcat. In either case, it produces a web user interface and accepts calls to its REST API.
When you run Jenkins for the first time, it creates an administrative user with a long random password, which you can paste into its initial webpage to unlock the installation.
What is CI CD Pipeline?
CI means Continuous Integration and CD means Continuous Delivery and Continuous Deployment. This is how SDLC works for dev-ops
Jenkins — The Ultimate CI Tool and Its Importance in CI-CD Pipeline
In this blog, we will try to automate entire Deployments with the help of Jenkins pipeline, Jenkinsfile using dockers
The whole development cycle will be based on the dev-ops model with the help of dev-ops tools as well
Jenkins provides us with various interfaces and tools in order to automate the entire process.
- We will create a git repository or use an existing one
- Dev team have the responsibility to commit the code to Dev-Branch
- Jenkins will fetch the code from Github and will map with the job enabled for a specific task
- We will make sure that CI and CD is done for the job/task
- Jenkins will pull the code and will enter the commit phase of the task
- Jenkins then will compile code and its called build phase of the task
- The code is deployed by Jenkins after the code is merged to Master branch by DevOps team and the job is started for a specific application
- The code is ready to be deployed and enter the deployment phase cycle
- The code after deployed from Jenkins then get deployed to the server using docker container
- After the code is working fine in staging server with unit testing, Same code then is deployed on the production server
With all the above 10 steps, Jenkins is responsible for the delivery phase with automating the deployment
Docker
Docker is simply sorted of virtual surroundings within which we will produce a server. It takes a couple of seconds to make a whole server and deploy the artifacts that we wish to check.
Why do we use docker?
As the same earlier, you’ll run the whole cluster in a very few seconds. we have a storage GitHub registry for images wherever you build your image and store it forever. you’ll use it anytime in any setting which may replicate itself.
Overall Satisfaction with Jenkins
Use Cases and Deployment Scope
We use Jenkins to build and deploy AEM (java/maven) applications. We usually stand up one instance per project so that teams do not interfere with each other. At the end of the project we destroy those instances. It is used primarily for CI to dev and qa environments, and final build package delivery. It integrates with our package management system Artifactory.
We have been able to leverage existing free plugins, and not needed to write any custom or convoluted scripts.
Pros and Cons
- Job chains. you can break up tasks into multiple jobs and chain them together.
- Jobs are very flexible. there are many plugins available for things like maven/ant/msbuild/s3 and if you can’t find one for your particular stack, you can always drop down to scripting.
- Notifications. we’ve used the out-of-the-box email notifications to report on failures, and we also use the Slack integration provided by a free plugin.
- Its open source, so there are times when plugins (not the core) have issues and you either have to wait for a fix, suggest a fix, or find a work-around.
- The UI leaves a little something to be desired. It seems like it was designed by engineers. fortunately there is a plugin for styling which makes it a little better.
- Version 2 is out. At the time when I tried to migrate from 1.6 I had issues because some of the plugins I use had issues in 2.0.
Return on Investment
- Helps identify build issues right away, almost within minutes of something getting saved to SCM.
- Helps managers (anyone really) deploy a daily build to QA for testing without needing additional dev resources.
- Helps create versioned release builds quickly and consistently without needing additional dev resources.
Alternatives Considered
Price. Jenkins is free, while most of its competitors are not. Its not proprietary meaning there are tons and tons of plugins and examples out on the web.
Overall Satisfaction with Jenkins
Use Cases and Deployment Scope
Jenkins is been use as our main CI/CD software, we have a micro-service architecture that is been build, tested, deployed through all our environments qa, staging, production and all of them at scale. We also build on jenkins our mobile applications with the same flow we build test and deploy our applications to the stores reducing human error on configurations and spotting issues before we even know about it. That allow us to reach an estate of trust with our clients.
About Jenkins we are using the new BlueOcean interface, what it is really amazing; and using Pipelines as our definition language.
Pros and Cons
- Integration with third part tooling, testing software and platforms
- Plugin platform, really flexible and easy to develop for
- Open source
- Scalable
- Easy to install and configure
- UI Interface
- API
- Administration
Return on Investment
- Reduce of set costs for CI/CD platforms
- Reduce of errors on the whole system is directly related to more incomes
- Ensure quality on our code that is also related to incomes
Alternatives Considered
Basically all those CI/CD tools provides the same set of tooling. SaaS solutions have a pre set pool of languages and containers you can use, but hey also are less flexible because they will not allow you to do advance configurations or setups you may need.
With jenkins you have the full power of the tool on your hand so there is no limit on what you can do
