Continuous integration benefits: Why adopting a CI/CD tool like Jenkins makes sense

What’s the deal with Jenkins? Consistency in deployment

Consistency is one of the biggest benefits from a CI tool like Jenkins, especially when it comes to application deployment. By adding parameters to a Jenkins task, it can be easily configured for different environments and different users. This results in a single Jenkins deployment pipeline that all stakeholders can share. Everyone uses the same build and deploy configuration, and as a result, there is no indispensable employee who has sole control of key steps in the integration process.

And since every user shares the exact same integration pipeline, there are no mysteries in the deployment chain. This eliminates the often opaque steps many organizations follow when kicking off a deployment. And more to the point, it eliminates the wasteful downtime that occurs when poorly documented steps fail, and you don’t have the expertise to fix it.

Jenkins reinforces build integrity

We should note that while every stakeholder uses the same integration and deployment pipeline, that pipeline will be parameterized based on the the role and environment in which a user works. Integration steps, such as switching between source code repository or flipping between a test and production database, are repeated constantly. This reinforces the integrity of the build and eliminating surprises during the deployment process.

The efficient delivery stream

The inevitable result of using Jenkins is a move towards a DevOps-based approach to development and deployment. This factors error-prone manual steps out of the build process. Automation makes deployments more consistent. The end result is an efficient delivery stream that spends less time under operational siege. Deployments happen more frequently, and features and fixes get integrated more often.

Why Jenkins? Here’s what I’ve seen it do

Over the past several years, I’ve watched organizations embark on what C-level executives like to describe as their “DevOps journey.” I simply see it as a way t0 make the build, test and deployment process highly automated, infinitely repeatable and consistent across environments. But if people want to slap a “DevOps journey” label on it, I’m happy to go with it.

There are plenty of moving parts in a DevOps transition, but from what I’ve seen, the most important one is the introduction of a CI tool such as Hudson, Concourse, Bamboo or Jenkins. Jenkins is open source and a continuation of Oracle’s Hudson CI, and it enjoys more community support than all other CI tools combined. Furthermore, enterprise support is available from companies such as Cloudbees if required. Each environment I’ve supported, though, found Jenkins more than sufficient to meet our needs.

The weird thing about Jenkins is how deceptively simple it is, while at the same time, being incredibly powerful.

All Jenkins does is pull together and consolidate build steps. Jenkins can be configured to pull from a source code repository like Git through CodeCommit. It will run and report on the status of unit and code quality tests. And assuming all of the requisite tests pass, Jenkins will build the application using a tool such as Apache Ant, Gradle or Maven. The assembled application — whether it’s a microservice deployed to a container or a portlet deployed to the WebSphere Portal Server — can then optionally be sent to a Nexus or Artifactory repository or moved into production.

SCM integration of builds

While all of this may sound impressive on the surface, it’s actually not that revolutionary. Every organization has a mechanism for moving code into production. Plenty of code has gone into production without using a CI tool. But there is something intrinsically valuable about having all of the deployment steps consolidated within a single tool, with all the underlying data saved in a structured format. It’s easier to track changes and revert back to previous processes if all of the underlying files are stored in a source code repository.

Code quality tool standardization

Jenkins helps standardize the use of various testing tools in the build and development process. And we’re not talking about compulsory testing tools like JUnit or JMock, but code quality tools like SonarCube, problem determination tools like PMD, and even performance and load testing tools. It only takes one developer to make a product like CheckStyle or PMD part of the Jenkins build and check that change into Git. So the next time another developer on the team rebases, their own local Jenkins installation will start using that testing tool as well. Furthermore, the fact that the tests are handled outside of a development tool like Eclipse, and instead run on every commit, rather than every save, tends to make developers more productive, rather than slowing down their creative process.

Pipelines as workflows

We should note that while Jenkins nudges organizations to automate as many build steps as possible, CI pipelines can also be built with hard stops that require manual intervention. In fact, the old way to say Jenkins “pipeline” was workflow. So you can configure a CI build to require a member of the user acceptance testing (UAT) team to log into Jenkins in order for a job to move on to the next stage in the process. Or a member of the operations team can have final say over whether or not an assembled application goes into production or not. Automation is always a goal, but Jenkins doesn’t dismiss the reality that manual deployment steps always exist.

Jenkins will build your DevOps culture

Many evangelists talk about the need to change organizational culture in order to embrace CI tools or perform a DevOps transition. I have always objected to that thinking.

We can define culture as a set of repeated behaviors which groups of loosely associated people perform. Organizations don’t need to change their culture in order to start doing CI and CD. Instead, what I’ve found is that when you introduce good tools like Jenkins to development and operations teams, they embrace the tool and its capabilities, and as a result, the tool changes their behaviors. The culture change isn’t a prerequisite, but instead, is a result of operations and development teams finding a better and more productive way of doing their jobs.

Plenty more to say

Anyways, I promised my Java meetup mates a quick description of integrating Jenkins at various enterprises has helped to make builds more consistent, repeatable and frequent. As you can tell, I’m not very good at “quick descriptions.” And even at this point, there is plenty more I could say about how a good CI tool impacts the software development lifecycle. But I think that covers the basics. If a DevOps transition is in your future, be sure to plot an early Jenkins pitstop on your DevOps roadmap.