Ten years ago, continuous integration (CI) was just getting off the ground, and tools like Jenkins were first-class automation platforms for your CI pipelines. This jump from lower-level tools and custom scripts to tools like Jenkins was dramatic. However, now a new generation of web-based tools are available, representing another streamlining and functionality leap for product build automation.

Many large enterprises use Jenkins for CI. It was often the best choice when projects began. Jenkins is still a competent tool, but it requires configuration and management of both the software and endpoints.

Teams have made large investments to create Jenkins workflows specific to their needs and requirements. More modern tools are available, and compelling, but wholesale migration away from Jenkins can be daunting and expensive.

There is an alternative. You do not need to replace Jenkins where it is already working well. Instead, migrate to modern CI tools gradually as you add new apps and microservices.

What is Jenkins?

In 2005, Sun Microsystems developed an open-source package named Hudson, focused on building and testing Java applications. When Oracle purchased Sun, they intended to develop Hudson as a commercial package. In the meantime, the community created a second fork named Jenkins, which became what it is today.

Jenkins supports software testing and build automation, part of what we now call DevOps. It requires a physical or virtual machine and a managed endpoint linking to other systems.

A key feature of Jenkins is plugins that extend its capabilities and reporting. This plugin system has enabled Jenkins to keep up with a changing development landscape. For example, the following Jenkins script uses a Docker plugin.

/* Requires the Docker Pipeline plugin */
node('docker') {
    checkout scm
    stage('Build') {
        docker.image('node:14-alpine').inside {
            sh 'npm --version'
        }
    }
}

Migrating from Jenkins

Jenkins is a mature and capable tool trying to keep pace with the rapid and pervasive move to cloud technologies. Developers attracted to a new generation of CI tools may feel stuck using this older technology.

Migrating a complex process from Jenkins is difficult and potentially expensive. There is the learning curve of a new tool and possible operation disruptions if errors occur. Migration is can be daunting for teams who have been using Jenkins five or more years. All the work that went into creating complex Jenkins pipelines must be translated into a different format. Invariably, some functions and statements lack one-to-one conversion and require careful reconstruction on the new platform.

Jenkins is, at its core, still a CI tool, so deployment steps are tough to migrate. While plugins have helped it adapt to continuous delivery, each plugin requires a separate configuration that is not easy to port to other CI tools without re-creating everything manually.

Benefits of modern continuous integration tools

If Jenkins is already working, why would an enterprise consider moving to modern modern CI tools?

One benefit of modern CI tools is speed. Jenkins’ plugin-based architecture is powerful, but it covers functionality Jenkins does not have at its core. The result is a CI application that is not always quick enough to meet developers’ current expectations. Other, newer tools are available to build, test, and deploy applications and environments more rapidly.

Another benefit of modern CI tools is reduced maintenance time. Jenkins is open source and free, but someone must spend time installing and maintaining the installation on a physical or virtual machine. Typically, Jenkins requires external endpoints, so there is a networking aspect as well. Whether you are paying for support or paying internal employees to manage these, maintenance is an expense you cannot ignore. When you consider all the costs, modern web-based CI tools can be far less expensive than legacy tools like Jenkins.

Managing plugin sprawl is another consideration. Modern CI tools have more extensive modern workflows built in. There is no need to install dozens of plugins to get a CI system capable of operating in a cloud-native development and deployment environment. For example, instead of needing plugins to support modern basics like Git and containers, modern CI tools support them natively.

Another area where newer tools shine is debugging. When something goes wrong in your CI pipeline, modern CI tools offer visibility into the pipeline to determine what went wrong. This visibility is more limited in Jenkins.

Advanced notifications is another area where modern CI tools have an edge. Real-time notifications are available to contact the right people without delay when there is a process error or disruption. Again, plugins may fill these gaps, but then you have another component to support.

Analytics are common in today’s cloud-native world. Most modern CI tools have useful analytics built in, so you can see a wide variety of helpful information about your build-test-deploy pipeline.

Modern CI systems are much easier to manage than their legacy predecessors. For one, cloud-based tools eliminate the need to build and maintain infrastructure. Further, modern CI systems are scalable and highly available by default, taking another worry off your mind.

Combined pipelines

How do you get started with modern CI tools when you are running legacy tools such as Jenkins? One approach is to begin by using a modern CI tool with a new project or service. This way, you can leave the existing processes in place, learn new tools, and start to migrate in an organized and non-disruptive manner. Your Jenkins pipelines can continue to run without modification.

Eventually, as your teams become more familiar with modern CI tools, you can consider migrating existing Jenkins projects. You may want to start this gradually using a combined pipeline. For example, you may let Jenkins keep doing what it does best - building your complex application - and then let a modern CI tool take over tasks like containerizing the application and deploying it to a Kubernetes cluster.

CircleCI supports popular version control systems, can run in a clean container or virtual machine, has automated notifications, debugging with SSH, and can deploy projects to a variety of environments. Analytics (Insights) are also built in. The dashboard looks like this.

CircleCI dashboard

One approach is to create a new pipeline in CircleCI and then use the CircleCI API to trigger that pipeline using the Jenkins HTTP Request plugin. Once the new pipeline is installed in your Jenkins instance, you can build a GET/POST request to the CircleCI API.

The CircleCI API uses a few types of authentication including “basic_auth”, which you can configure in the Jenkins HTTP Request plugin. CircleCI has documents about how to trigger a pipeline. A sample Jenkins request (not including the authorization headers) might look like this.

httpRequest acceptType: 'APPLICATION_JSON', contentType: 'APPLICATION_JSON', requestBody: 

'''{
  "branch": "feature/design-new-api",
  "tag": "v3.1.4159",
  "parameters": {
    "deploy_prod": true
  }
}''', responseHandle: 'NONE', url: 'https://circleci.com/api/v2/project/gh/CircleCI-Public/api-preview-docs/pipeline', validResponseContent: '201', wrapAsMultipart: false

Using this technique, you can continue to drive your process from Jenkins while you start to migrate operations to CircleCI.

Speaking of migration, the CircleCI Jenkins Converter helps you convert Jenkins operations to CircleCI. It handles an expanding number of plugins and Jenkins syntax.

Start incorporating new CI tools

Now that you understand the benefits of modern CI and where CircleCI fits in, why not give it a try? Sign up your CircleCI free trial today to simplify your DevOps and get your team moving to the modern cloud.