The power and dominance of Jenkins for continuous integration (CI) is indisputable—it’s used by just about everyone everywhere to continuously build and test software at scale. Equally indisputable? It can be a handful. Extensibility is the foundation of its power, but limitless possibilities can make it unruly. 

Let me tell you, I was there sitting in the unruly. I knew I could get the job done, but I was experiencing inefficiencies that I myself created, trying to grow too fast or getting things set up quickly so my boss's boss could show a pretty chart to the shareholders. But I digress. One thing I’ve learned in my old age is I need to figure out where I am to know where I am going. (I'm sure I read this on a graduation card somewhere.)

Maybe you have a perfect setup already (which is great—I could have used your advice a year ago), but for those of you sitting in the unruly or looking to improve your setup (because who has time for inefficiencies?), let me share with you what I learned. And spoiler alert, it made it a lot easier to do my job, kept my talented developers happy, and even helped my boss’s boss with the pretty powerpoint presentations. 

Jenkins dominates enterprise SDLCs thanks to its unmatched flexibility. With 1,800+ plugins extending functionality and tool integration to every corner of development landscapes, there’s very little Jenkins can’t do. But two systemic issues have the potential to negatively impact development teams and the enterprises they support:

• Lack of centralization. Jenkins lacks centralized control. Enterprises that spin up multiple controllers are obligated to govern those controllers individually. There’s no hub from which operations, workflows, and processes can be administered across your CI environment, and no single screen from which users can be authenticated and provisioned globally. Orchestrating plugins or projects spanning multiple servers from a single cloud interface? Forget about it.

• Lack of operational visibility. Jenkins provides no “bird’s-eye view” that allows enterprises to see statuses or measure progress across their operations. In fact, even knowing who owns a project can be difficult. As a result, disconnected teams often work from incomplete info in silos, and managers struggle to coordinate the big picture across the SDLC.

These shortcomings have sweeping consequences, resulting in four woes (two of which are covered in this blog—check out Blog #2 for the exciting continuation) that all unmanaged (i.e., strictly open source) Jenkins controllers must negotiate.

Jenkins’ potential for administrative friction can slow productivity for both engineers and admins. After all, if your admins exhaust all their time chasing down these issues, they’ll inevitably rely on your best engineers to pick up the slack.  At one time, that engineer was me, and I was not happy about it. 

Managing all of your controllers is complex and time consuming. Jenkins, like any Java application, is not a “set it and forget it” technology. Controllers require continuous administrative oversight, from ensuring proper garbage collection to managing memory utilization. 

Managing, replicating, and provisioning Jenkins instances across teams is difficult. Different teams have different needs, and launching and maintaining multiple purpose-built servers, provisioning non-standardized plugin sets to each, and supporting different versioning schemes to meet distinct compatibility and security concerns can be exhausting for central admins and shared services teams—particularly if they’re attempting any form of governance or compliance. 

Scaling can stress admins as much as it does infrastructure. As teams experience success with Jenkins, other teams will want in on the action. How will an indeterminate number of Jenkins controllers (running different toolsets) impact disk utilization, garbage collection, or memory availability? Will the plugins in play impair performance? Will you need more infrastructure to handle the ever-changing load? 

Plugins don’t maintain themselves. (Spoiler alert—NO software maintains itself.) Admins spend considerable time updating (or deliberately not updating), negotiating compatibility conflicts, implementing bug workarounds, and resolving security issues as plugins multiply across controllers and teams.

Jenkins requires advanced JVM know-how. Exacerbating all of the above, Jenkins admins need JVM-focused skills that they often lack. This makes it more likely that engineers will be pulled into admin roles in the interest of pooling JVM knowledge to resolve issues.

When you spend time doing the same tasks over and over again, that’s a problem. Inefficiency  can afflict team productivity, hinder release schedules, and threaten goals across entire enterprises.

Work is unnecessarily duplicated across teams/servers. Once you’ve figured out a controller setup that works, there’s no way to quickly iterate that across additional servers/teams. This means setting up the controller, adding users, installing plugins, etc., from scratch every time. In fact, workflows of all kinds tend to be repeated again and again.

Infrastructure is often wasted. Without a means for overseeing and balancing resource utilization, infrastructure is often allocated where it isn’t needed. 

Workflow efficiencies are hard to replicate. If a team comes up with a clever setup, workflow, or process innovation, there is no simple way to share those enhancements with other teams on different servers. As a result, enterprises lose valuable opportunities to increase productivity across the board.

Onboarding can be tedious. Setting up new teams requires the same repetitive series of tasks every time. This creates significant drag that limits early-stage productivity.

Lack of communication can be crippling. Without visibility across controllers/teams, you’ll rely entirely on manual communications—an ugly prospect for most enterprises. This can be especially perilous when teams update plugins, tweak their pipelines, change network or firewall settings, or initiate security updates without informing other teams. Things tend to break, and it isn’t uncommon for teams to submit support tickets along the lines of, “It broke even though we didn’t change anything!”

I highlighted some of these Jenkins’ shortcomings strictly out of love. Jenkins remains the most valuable CI tool available, and there’s a reason 80% of enterprise companies use it. You need to remedy its shortcomings to unlock its true power and potential. Let's see how I did this.

The short answer for me was that I needed a management platform that eliminated the friction and——BONUS!!—reduced hidden costs of my Jenkins infrastructure. When I established a centralized authority from which all controllers could be managed, I had overarching visibility, optimization, and governance possibilities, because now I had access to all relevant information and functionality from a single portal. 

This was where CloudBees CI entered my life and brought a managed Jenkins solution which I used to overcome the woes and infrastructure challenges I’d created. I know you are thinking, “Yeah, yeah, another advertisement…” That may be, but this is what I used to meet my goals, and I'm sharing it with you. Take it or leave it—it's my story, and this is what worked. 

So how did this translate to my two woes that I wrote about earlier? 

Let’s start with a visual of this single portal. Imagine your teams and all the other teams that work together to make feature magic happen within your software application. Think of each team as a folder in a root directory. That folder contains all the objects the team needs. This folder can be isolated from the rest of the team, but all objects are managed from the root. This folder is your lightweight managed Jenkins instance. And the root is the CloudBees Operations Center. Each team has their own instance and objects and freedom to use the tools that work for them. And your Jenkins administration can see and manage all of the objects from one place.

The CloudBees Operations Center provides a centralized control plane capable of a few of my favorite features:

• Single-screen command of the entire Jenkins infrastructure

  • Visibility across all controllers, projects, and teams

  • Infrastructure health monitoring and alerting

  • Instant controller provisioning (supporting individual teams or team collaboration)

  • Creation of shared agents

  • Centrally managed authentication and authorization (SSO, SAML, RBAC, LDAP)

  • Sharing of events or messages across controllers and projects

  • Support for connecting, reusing, and managing resources as a cluster of connected assets

• Enterprise Configuration as Code (CasC)

  • Easily manage, configure, replicate, and update from a single source

  • Everything as code: the control plane itself, controllers, agents, projects, plugins, and pipeline templates

• Plugin management

  • Centralized plugin provisioning, configuration, monitoring, and updating (with recommended actions to assist with maintenance)

  • Plugins added to CasC bundles for single-source updates

  • Plugin updates via cluster operation

For those who need a visual, check out the diagram below, which shows how the CloudBees CI Operations Center (the centralized control plane we talked about above as the “root”) restructures your Jenkins environment whether you deploy on premises or in the cloud.

For me, implementing the features above went a long way toward wrangling the unruly Jenkins environment I created and brought in order, visibility, and easy management that our admin could easily implement across multiple teams. 

These were just two woes I identified in my organization—and perhaps you experienced some of these challenges yourself.  But as I dug into the inefficiencies a bit more, I found a few additional areas that I knew could be better somehow.  In my next blog, I’ll bring up a few more woes, and maybe you will identify with these as well.

In the meantime, download the Massive ROI with Managed Jenkins eBook to learn more.