The Two Most Common Issues with Jenkins and How to Fix Them

Continuous integration and continuous delivery (CI/CD) are the norm for today's software pipelines, and for good reason. Before CI/CD, testing and delivery processes were manual. Repeatability was nearly impossible and releases were stressful affairs that involved scrambling to fix major defects at the last moment. A harried team, of course, doesn't produce its best work, so to add insult to injury, software quality often wasn't quite up to snuff. 

The broad adoption of Jenkins (used by a whopping 70% of the world's developers!) for pipeline automation changed everything. Software organizations rely on Jenkins to power consistent, repeatable, early-and-often testing, which, in turn, means more frequent commits and higher-quality software going to market faster. Clearly, open source Jenkins is a fantastic CI/CD solution, but it has a significant weak point: Managing and scaling Jenkins for the enterprise is an uphill battle. 

Attempts to address challenges related to governance, administrative overhead, plugin management, infrastructure management and team dynamics have given birth to two common (and ugly) scenarios: Jenkinsteins and Jenkins islands.

Creating one monolithic Jenkins server and putting everyone in the organization on it — the Jenkinstein approach — may seem sensible, but it makes your servers extremely brittle and has a real potential to grind business growth to a halt. Let's look at the four main issues with a Jenkins monolith.

• Sluggish servers: When the server is overloaded, there's a direct impact on build and test times — and therefore to your ability to innovate quickly.

• Single point of failure: If your one and only Jenkins server goes down, your entire software organization's productivity is paused until the outage is resolved. 

• Plugin conflicts: Plugins are part of what makes Jenkins great, but having a monolithic Jenkins server creates the potential for plugin conflicts due to the distinct requirements of various teams.

• Individual dependency: Everything hinges on the organization's “Jenkins guy” configuring and maintaining the brittle setup.

When these frictions arise, many teams opt to strike out on their own, giving rise to Jenkins islands.

Often, each team within an organization has its own Jenkins controller. That does keep the Jenkinstein issues at bay, but it opens up a new can of worms. All those separate servers create the sense that each team lives on its own island. The result?

• No governance: Having every team working under its own set of rules and practices is a governance nightmare. Controlling who has access to what is all but impossible, and best practices can't emerge. 

• Compliance challenges: There's no mechanism in place to be sure teams are running tests consistently. Some teams might ensure that security scans are built into every segment of their pipelines while others may not, for instance. You'll never be able to achieve regulatory compliance that way.

• Lack of collaboration: It's difficult to hand off tasks between different disconnected Jenkins controllers. If a team discovers a new way of doing things more efficiently, they have no practical way of sharing this information with other siloed teams.

• Hidden costs: Engineers shouldn't waste their valuable time and resources maintaining an array of Jenkins instances and configurations.

Remember: No one is an island, and no Jenkins controller should be, either.

Whether it's Jenkins sprawl, monolithic controllers, plug-in vulnerabilities, time-consuming administrative tasks, or ballooning infrastructure costs, managing and scaling open source Jenkins (not to mention creating a culture where silos are broken down and everyone is aligned on a single shared vision) is a tall order. To achieve all of that, you need a shared, centrally managed, governed experience for all development teams running Jenkins. That's what CloudBees CI delivers.