By far, Jenkins is the most adopted tool for continuous integration, owning nearly 50% of the market share. As so many developers are using it, it has excellent community support, like no other Jenkins alternative. With that, it has more than 1,500 plugins available for continuous integration and delivery purposes.
We love and respect Jenkins. After all, it’s the first tool we encountered at the beginning of our automation careers. But as things are rapidly changing in the automation field, Jenkins is left behind with its old approach. Even though many developers and companies are using it, most of them aren’t happy with it. Having used it ourselves on previous projects, we quickly became frustrated by its lack of functionality, numerous maintenance issues, dependencies, and scaling problems.
We decided to investigate if other developers face the same problems and quickly saw the need to create a tool ourselves. We asked some developers at last year’s AWS Summit in Berlin about this. Most of them told us that they chose Jenkins because it’s free in the first place. However, many of them expressed interest in trying to use some other Jenkins alternative.
When using Jenkins, teams tend to make more mistakes with the delivery and end up with broken pipelines. As a result, they implement inefficient practices, can’t adopt agility well, and lose the flexibility to innovate. When problems come up, you instantly need an expert that will resolve the issues to unblock developers.
Solving modern problems with old technology
CI servers date back to the mid-2000s when containers and microservices weren’t so popular. Coming from this pre-cloud era, Jenkins is designed primarily for manual installations. It doesn’t really help in taking the maximum advantage of Docker containers to create modern infrastructure. Docker integration is handled through multiple plugins (around 30 different ones are available with the name “docker”). For a world that is Dockerized, this is not what you’re looking for in a CI tool.
Challenges arise with access management, configuration usability, and setting up jobs. Even with a Jenkinsfile that helps you define the job structure, you need to recreate new jobs from scratch. With the CLI, you need to have good knowledge of how Jenkins stores its configurations, and the documentation doesn’t really help you there at all. The tool is hard to learn, especially from a beginner’s perspective.
All in all, Jenkins setup is hard to create, maintain, and automate.
Maintenance nightmares
Jenkins requires a lot of maintenance, so you need to have dedicated experts to resolve problems efficiently.
You need to create and manage scripts to orchestrate everything. Even the core concepts of a deployment pipeline like build, artifact, environment, variables, steps, triggers, workflows, applications and services, rollback, testing, and monitoring all require a Jenkins job or script to manage. Hardcoding a deployment pipeline with scripts doesn’t work in today’s world of public clouds, containers, and microservices.
Doing this will bring more problems than benefits since you have to maintain those scripts as technologies and applications change and evolve. In the end, you spend more time maintaining then deploying new versions of the product. Your DevOps team should be innovating around your deployment process, not dealing with broken pipelines. Your pipelines should be dynamic and easily adaptable to changes by the ecosystem.
Plugin overload
Plugins are great as they can provide extensibility to a system’s core functionalities. But, what happens when you have to use a plugin for everything, even basic tasks? Build for a Docker environment, Kubernetes, pull from GitHub, authentication… All pretty common tasks, for which you need to install and maintain a plugin.
Jenkins has 1500+ plugins available today. How do you decide which one to use? Most of them are written by third parties, which means they can lose support without any notice.
Also, worth mentioning is the dependency chain. Many services change all the time, making plugin dependencies very problematic and one of the most common causes of broken pipelines. This doesn’t really provide availability and stability.
Microservice support
Jenkins was born way before microservices became popular. So it does a very poor job of supporting microservices. Especially the observability and monitoring aspects when having a more significant number of microservices, each having its own pipeline process.
With no support for integrating and testing multiple services at once, Jenkins lacks essential functionalities for microservice applications.
Continuous delivery
Continuous integration is part of the entire continuous delivery process, but you need more than CI to achieve a company maturity in CD.
With Jenkins, you can try and build a CD platform yourself, but be aware you’ll need a whole team for it, a load of time and maintenance.
Wrap up
Jenkins comes with a limited set of features. You need plugins to integrate with a lot of tools we use in today’s ecosystem. The biggest pro of Jenkins is that it is used and managed by the community, so you can mostly find answers to your questions.
Jenkins is best for:
- On-premise solutions
- Code hosted in-house
- Highly customized workflows
- Companies that have the resources to dedicate a team to manage and maintain it
- Companies that don’t want to spend on a tool
For other solutions, you might want to try tools built with modern DevOps in mind, like [Microtica](https://microtica.com/?utm_source=devto&utm_medium=referral_link&utm_campaign=jenkins_is_old.
For more specific Jenkins alternative suggestions, check out this article.
Top comments (0)