You don’t need to migrate from Jenkins. Start building beside it.

Ten years ago, tools like Jenkins were first-class automation platforms for your CI pipelines. The jump from lower-level tools and custom scripts to tools like Jenkins created dramatic improvements. Now, a new generation of web-based tools are available. They provide a platform for the next leap forward for product build automation.

This long history means that many mature organizations use Jenkins for CI. 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. Compelling modern tools are available, but wholesale migration away from Jenkins seems complex 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?

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. Plugins have enabled Jenkins to keep up with a changing development landscape. Consider this Jenkins script, which 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 can be expensive, especially for systems in place for five or more years. As always, there is the learning curve of a adopting a new tool. Errors can cause operation disruptions.

The time and energy teams have invested in creating complex Jenkins pipelines must be translated into a different format. Invariably, some functions and statements lack parity 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 config 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 a lack of functionality at its core results in a CI application that can’t always meet developers’ expectations quickly. Other, newer tools can build, test, and deploy applications and environments faster.

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. Jenkins may require external endpoints, so there is also a networking aspect.

Whether you are paying for outside support or paying internal employees, 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 extensive modern workflows built in. You get a CI system capable of operating in a cloud-native development and deployment environment without installing dozens of plugins. For example, instead of needing plugins to support 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, the latest 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. 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 easier to manage than legacy tools. First, cloud-based tools eliminate the need to build and maintain infrastructure. In addition, 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 using a modern CI tool when you add a new project or service.

You can leave the existing processes in place, learn new tools, and start to migrate in an organized and non-disruptive way. Your Jenkins pipelines can continue to run without modification.

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, runs in a clean container or virtual machine, has automated notifications, debugging with SSH, and can deploy projects to many environments. Analytics (Insights) are also built in. The dashboard looks like this.

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. You can learn how to trigger a pipeline in the CircleCI docs. 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 for your CircleCI free trial today to simplify your DevOps and get your team moving to the modern cloud.