According to ActiveState's State of CI/CD 2020” survey results, Jenkins is the most-used CI/CD tool on the market. As one of the first job runners on the market, it's had plenty of time to gain popularity, and has been a crucial component in advancing the DevOps approach of building and delivering software.
Thanks to over eighteen hundred plug-ins, Jenkins is very easy to extend—with the right set of plug-ins, you can do pretty much anything. The plug-in library is what allows every Jenkins user to end up with a personalized experience that's largely informed by the plug-ins they installed.
Plug-ins may be at the core of Jenkins, but they also quickly become a burden for teams using Jenkins. Managing the Jenkins platform for growing teams and companies can quickly become a bottleneck, slowing you down rather than increasing your agility.
In this guide, you’ll look more at some of the disadvantages of Jenkins, as well as learn about some alternatives.
Plug-ins are so central to using Jenkins that they make their first appearance in the installation process, where you're asked to select a plug-in to start with. The default installation comes with about twenty plug-ins, plus any that you selected during installation. These plug-ins are responsible for integrating your CI/CD with external tools such as GitHub or Bitbucket for version control. Plug-ins also extended the capabilities of Jenkins and the way it works. Even the pipeline system, which orchestrates builds, is a plug-in and can be modified using other plug-ins.
You can add new plug-ins to Jenkins through the marketplace. All plug-ins in the marketplace are community-based and open source, which means anybody can create a custom plug-in that matches their needs and list it on the marketplace. Usually, there are three important things you look at when selecting a plug-in:
- The popularity of the plug-in, which can be assessed by the number of installs.
- How well it's maintained, which can be estimated by looking at when the most recent update was.
- The dependencies required, such as other plug-ins you need to install.
While the large number of plug-ins available was once seen as an advantage for the platform, it's now often seen as a drawback, or at least a source of frustration that fuels the love/hate relationship that many people have with Jenkins.
When it was first released, Jenkins felt like a wonderful self-service environment where a solid developer or team could do almost anything with the Jenkins pipelines and the right set of plug-ins. Today, however, you need real Jenkins expertise to maintain a Jenkins server, which is a disadvantage especially when compared to newer SaaS CI/CD options on the market.
There are many recurrent issues related to the Jenkins plug-in ecosystem. The first one is the unending cycle of upgrades and dependencies. A simple project can require over twenty-five different plug-ins, as every plug-in you install can install other plug-ins that are required for the first plug-in to work. This leads to a situation where you can install two plug-ins, each requiring the same third plug-in to work, and each relying on a different version of that third plug-in, leading to installation issues or bugs.
Bigger issues arise when you discover that a plug-in has a security flaw. If you discover that a plug-in is insecure or buggy, you open an issue on GitHub and wait for the plug-in to be patched, but what if the patch never comes? You can either bear with a security flaw, find a replacement plug-in and modify all your pipelines to accommodate the new plug-in, or fork the plug-in, patch it, and become the new maintainer of that plug-in. Given that new security breaches are discovered every day and plug-ins need to be patched frequently, this can quickly become a lot of work.
It also leads to yet another issue with Jenkins plug-ins. Even very popular plug-ins are often badly maintained or abandoned by the original maintainer entirely. From the perspective of the maintainers, this is totally understandable. Plug-ins are created to solve a problem, and most maintainers aren't planning to become professional plug-in maintainers on top of their job. On the user side, though, this leads to plug-ins that have poor support, because the maintainers are community members who have no obligation to maintain plug-ins indefinitely.
The last issue with Jenkins plug-ins is the lack of transparency. Without carefully examining the code, you can’t know the scope of a plug-in, and you have limited ability to limit the plug-in's access and actions on your server. Therefore, the trust factor is very important when selecting a plug-in, and you need to be careful to reduce the potential attack surface.
When you think about using Jenkins with a single team, these issues may not seem like a huge problem. They can build their pipeline base with their favorite set of plug-ins, and assuming there are no security issues, all is well.
But when the company grows, more developers come on board, new teams are created, and there are multiple applications and services, Jenkins plug-ins don't scale well. If you let everyone use whatever plug-ins they want, you'll quickly run into dependency and upgrade issues. On the other hand, if you limit the plug-ins developers can use, you'll end up with a frustrated team and developers who feel that you're preventing them from automating tedious aspects of their workflow.
Jenkins was only allows for a single primary node, and as such, simply wasn't designed with high availability in mind. As a result of these design choices, having to restart the server to change configuration or install new plugins causes downtime and interrupts the work of everyone in your organization who relies on Jenkins. There's no easy solution to this dilemma. Creating a Jenkins server for each team would be extremely cost-inefficient and would create silos between teams. Teams with independent Jenkins servers will build incompatible pipelines based on different sets of plug-ins, setting you up for a situation where your teams can't share their automation work with each other.
You can’t allow Jenkins to be a true self-service platform, because it would be operationally complex and reduce cooperation between teams. But the biggest argument against Jenkins plug-ins is that plug-ins are a security hazard. As mentioned earlier, almost all plug-ins are community created and supported. You need to trust that the maintainer uses security best practices, and keeps the plug-in patched against newly found vulnerabilities, which when done correctly is likely a weekly job. CI/CD platforms often have access to many systems and have the credentials needed to modify your infrastructure and interact with your production environment. This makes any CI/CD platforms a very sensitive part of your infrastructure, and security should be a top priority with these tools.
By now, you have a good understanding of some of the problems with Jenkins plug-ins. If you're thinking about moving away from them and towards a more secure infrastructure, here are some steps to take.
Create a shortlist of carefully selected plug-ins, and stick to those. This list should take into account both security and maintainability concerns. As a general rule, it's best to stick with plug-ins that offer integration with cloud providers such as GitHub or Amazon Web Services as they often receive strong support from the community and developers of those cloud providers. For instance, GitHub plug-in is a well-maintained plug-in you can rely on. Test new plug-ins and upgrades on a secondary Jenkins server before you run them on your primary server.
Avoid plug-ins that change the way Jenkins pipelines work, because if these plug-ins break, are no longer maintained, or develop a security vulnerability, you'll need to rework your entire pipeline.
Proactively keep an eye on your plug-ins' health by checking their GitHub repository to see if they're being actively maintained; if they're not, you should be looking for a replacement. This could prevent downtime in the future when upgrading a Jenkins server, or if a security breach is discovered. Plugins are independent pieces of software with potentially exploitable vulnerabilities that an attacker could exploit to gain access to your build systems—and all the other parts of your system that Jenkins, out of necessity, is granted read/write access to, such as your code repository, cloud provider, and network connection. As was made obvious by the SolarWinds malware injection via build pipeline incident, the CI/CD pipeline is a trusted part of the build process, and all it takes is a snippet of malicious code to not just make your company vulnerable, but all of your clients, as well. The extreme sensitivity of this area makes plugin monitoring and curation absolutely critical.
Container technology enables you to package environments with all their dependence. Thanks to the Docker plug-in, you can run Jenkins builds inside a Docker container. The Docker container can use an image created for the task and act as a Jenkins agent, complete with all the required dependencies for your build, eliminating the need to install plug-ins on your server.
One of the simplest solutions to Jenkins plug-ins issues is just to use fewer plug-ins. The fewer plug-ins you use, the fewer issues you have. To achieve that, you can favor scripts over plug-ins. For example, sending a Slack notification is as simple as sending an HTTP request to an API, and allows you to avoid relying on a third-party plug-in. Scripts can be more reliable than plug-ins because you can use them locally to perform the same action. While this may seem like more work than using a plug-in, you can share your automation script across the company and use them in any pipeline without impacting the Jenkins server.
The second approach is to work as much as possible with Jenkins templates. Templates let you define reusable pieces of pipelines (jobs), and add a layer of abstraction, making it easier for developers to configure and use Jenkins. Using a template offers you an easy way to identify the plug-ins required, since the plug-ins you need are the ones referenced in the template. This gives you a place to build your pipeline collaboratively and reduce the number of plug-ins you use across your organization.
Jenkins and its plug-ins ecosystem can be very appealing for people looking for a CI/CD solution for their projects. However, poorly maintained plug-ins, multiple different dependencies, and security risks have soured many people on the tool.
Jenkins plug-ins management will affect your organization, and mismanaged plug-ins can put your organization at risk. It's important to implement mitigation strategies, such as minimizing the number of plug-ins by defining standard jobs or pipelines, carefully curating your plug-ins, testing plug-ins and upgrades on a separate instance, and using container-based jobs to reduce your dependency with Jenkins plug-ins.
If you're tired of being bogged down by managing your CI/CD ecosystem, including your Jenkins server, you may be interested in Opsera. Opsera is a no-code DevOps platform that provides integrations to replace many Jenkins plug-ins, as well as to connect with your existing tools, making your team more agile and responsive, and allowing you to focus on creating great software, not managing your pipeline.
