DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 966,904 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Pavan Belagatti
Pavan Belagatti

Posted on

8 Reasons Why You Should Migrate from Jenkins

We continue to see new and improved software solutions for automating code/software deployment in the DevOps world. Whether you are a developer or an operations engineer, there is no room for using mediocre tools in this cloud-native world. Every day there are innovations, updated versions of old tools, and more accessible services that make our lives as coders and ops pros easier. Today, DevOps has become the focal point, with every company being called a software company. Continuous integration becomes the first step towards embracing DevOps as a methodology.

However, with so many continuous integration tools on the market, knowing which one is best for your organization can be tricky. There are also many options with different features, pricing models, and support plans. This article will help you understand why Jenkins is not a suitable tool to do CI for modern enterprises and how you can migrate from Jenkins to Drone CI.

The need for a true continuous integration tool

We all know that cloud tools are evolving each day, and we see a lot of substitute tools for the same job. For doing continuous integration, there are many tools in the market, but the one that truly understands the developers and built for them is hard to find. While Jenkins can be a good starting point for beginners and organizations, it gets difficult once the deployments increase. While speed can be another factor to judge a continuous integration tool, it should also be easy to set up on your computer with minimal commands. Drone CI has all it takes to be the one-of-a-kind CI tool helping developers build and test their applications through continuous integration. You can set it up on your local machine in minutes and start doing continuous integration. Drone CI is built on Docker & uses the power of containers at each stage.

Further, let’s see how Drone can be a better tool for continuous integration than Jenkins.

Jenkins

jenkins console

Jenkins is an open-source continuous integration tool. It is used to build and test software, either on a developer’s local machine or in a continuous integration environment like any public cloud. With Jenkins, you can automate your software delivery pipeline from code commit to production. Jenkins is primarily used for build and deployment automation. It is commonly combined with other tools in the DevOps toolchain, like source code management, issue tracking, and project management. In addition to these tools, Jenkins is used for automated testing and deploying applications. Jenkins’ features include managing different jobs, viewing summary graphs, and receiving email notifications.

Drone CI

Drone

Drone CI is an open-source continuous integration server acquired by Harness. It is used to build and test software, either on a developer’s local machine or in a continuous integration environment like any public cloud. With Drone, you can automate your software delivery pipeline from code commit to production. In addition to building software, Drone allows you to build, test, and deploy your applications. Drone CI is considered a modern continuous integration tool as it uses the declarative approach in the form of yaml files to automate tests and extensively employs Docker containers at every step. The build pipelines take less time, and it is easy to set up and run.

Docker builds

Drone CI is a container-based declarative continuous integration tool that extensively employs Docker containers at every step and can easily run on your laptops, private data centre or on a public cloud. This declarative nature of continuous integration helps organizations to adopt Gitops.

Here is a simple configuration yaml file,

kind: pipeline
type: kubernetes
name: default
steps:
- name: test
  image: node
  commands:
  - npm install
  - npm test
Enter fullscreen mode Exit fullscreen mode

Just extending the YAML configuration with another scenario where you would like to merge the changes to the master branch. In this case, the stages are,

  • Build
  • Unit test
  • Deploy to dev
  • Integration test

The yaml configuration can be easily specified as below,

kind: pipeline
name: default
steps:
- name: build
  image: node:8.6.0
  commands:
  - npm install
  - npm run build
  when:
   event:
     - push
- name: unit_test
  image: node:8.6.0
  commands:
  - npm run unit_test
  when:
   event:
     - push
- name: intergration_test
  image: node:8.6.0
  commands:
  - npm run integration_test
- name: deploy_dev
  image: node:8.6.0
  commands:
  - npm run deploy -- --env=dev
  when:
   event:
     - push
  branch:
    - master
Enter fullscreen mode Exit fullscreen mode

Reasons why Jenkins is not suitable in today’s Cloud Native world,

  • Jenkins is used more than just to do CI, and that’s where the problem starts as the Jenkins instances become more complex and create a bottleneck. There are more benefits of doing CI and CD separately. Jenkins users are using it to do CD with custom scripts which isn’t the right way to do DevOps.

  • You need a Jenkins expert to maintain it and debug it when something goes wrong. Drone administrators report spending far less time maintaining their Drone instances than Jenkins administrators. Drone can easily scale to handle thousands of pipeline executions per day, and only requires a few hours of maintenance per month.

  • With so many plugins, the vulnerabilities are easily introduced and chaotic. Plugins have complex interdependencies, so updating one plugin could potentially break another.

  • Jenkins can be tough to scale efficiently because you can have only one controller that can’t be run in a highly available mode. The reason behind this is that multiple Jenkins instances can’t work together in a high-availability configuration, only one Jenkins instance can be writing to the database at a time.

  • I mean, seriously, Jenkins was not designed keeping future innovations in mind. Jenkins was started years before Docker was created, so Jenkins has never been a container-native CI tool.

  • Jenkins is heavy on compute resources, it consumes a lot of resources and it still lags when your download some basic plugins.

The Jenkins docker image is ~270MB whereas the Drone docker image is ~22MB.

jenkins heavy

drone image

Also, check out Jim’s tweet on the same,

drone vs jenkins tweet

  • Jenkins requires a steep learning curve, and need to learn Groovy for complex CI/CD setup. Groovy is just one, Jenkins DSL is another and hence becomes hard and chaotic for someone who is trying to set it up for the first time.

  • Some users reported that running builds using Jenkins CLI hangs, and that is not a good sign for a DevOps tool. Whereas Drone CLI is fast and you can run builds locally with a simple drone exec command. Drone also has a β€œdebug mode” that can be enabled, allowing users to interactively debug failed pipelines but does Jenkins has this feature? I doubt it.

Why Should You Migrate from Jenkins to Drone?

drone pipeline

No doubt, Jenkins has a first-mover advantage in the continuous integration field, and it became popular because of its vast spread of plugins. For a small team with basic usage, Jenkins is OK, but it becomes challenging as your team grows. It lacks modern cloud native capabilities. Plugin configuration seems to be a nightmare, and at some point, it becomes hard to maintain and scale and can be difficult to maintain uptime. Also, Jenkins is popularly known for its high maintenance. Visibility on the pipelines is very poor using Jenkins and it makes debugging a real pain. Initially, when you set it up, it works like a charm, you change a simple thing, it starts breaking.

Lack of innovation and old methodologies make enterprises move away from Jenkins to much more sophisticated platforms. Managing Jenkins can be a full-time role, it squeezes out your developers’ energy and time.

github stars

There are many reasons to consider migrating from Jenkins to Drone. These are the top ones we consider:

  • Simplicity:

    Drone is much simpler than Jenkins. If you need something more advanced, then Jenkins has more features. However, if you just want to get up and running quickly without having to configure anything, then Drone is a much better choice.

  • Speed:

    Jenkins uses a polling mechanism by default to look for changes to your code. This is something that Drone avoids as it uses webhooks. This means that Drone is much faster at detecting changes to your code. Jenkins can work with webhooks, but it is not the default behavior and is not as easy as Drone.

  • Ease of Use:

    There are two ways that Drone is simpler than Jenkins. First, the user interface is much simpler. Second, the installation process is much simpler.

  • Modern Approach:

    Jenkins still uses old methodologies and executes commands directly when running jobs rather than using modern approaches such as containers.

  • Written in Go:

    Go is becoming a suitable language because of its capabilities to fit the cloud-native space, and Drone is written in Go, whereas Jenkins is written in Java.

  • Simple Tests:

    You no longer have to use Groovy to build your tests like in Jenkins. Everything is in a declarative fashion, and the tests are specified with the .drone.yaml file.

  • Simply Declarative:

    In Drone, everything is configured through simple YAML files and it is very easy to configure and even a newbie can understand and set up. As we discussed before, the declarative nature of Drone helps organizations adopt Gitops easily.

  • Totally Container Based and Cloud Native:

    Every step is a fully isolated Docker container so that developers can quickly know which image has been used at every stage. It helps debug if something goes wrong at any stage of the pipeline. It is easy to reproduce each step on your local machine.

Also, since GitOps is a more modern approach to deploying Kubernetes-related deployments, the combination of Drone and Argo CD goes amazingly well. For example, you can use Drone to build your images and then commit a change to your application configuration in git, which Argo recognizes and deploys the change. If you like a more customized approach, you can use Harness GitOps, which is well integrated with Drone.

Conclusion

There is no one-size-fits-all solution when it comes to CI/CD tools. Different organizations will have different needs. Similarly, different organizations will prioritize different features. Therefore, when selecting the right CI/CD tool for your organization, it is critical to evaluate your needs and find the product that best meets them.

Also, it is important to consider what functions are necessary for your organization and which ones are nice to have. Today, every organization desires to embrace DevOps and use modern cloud-native technologies to deploy software quickly. Hence, it becomes vital to keep in mind to select a platform/tool that is cloud-native and has modern capabilities. With that in mind, if you are currently using Jenkins and are looking for an alternative, consider migrating to Drone.

Also, Drone has handful of amazing plugins that you can use to extend the capability of your CI pipelines.

So why wait? Run your own Drone CI on your laptop.

Further reading and case studies on Drone:

Oldest comments (0)

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.