In October 2022, I wrote a blog post entitled “Scaling Jenkins for the Enterprise”. Within it, I described the “Islands of Jenkins” problem organizations face. Essentially, this problem stems from companies using an open-source Jenkins installation for each team, but with little-to-no IT governance. This could result with dozens or hundreds of rogue Jenkins instances. Now that you are familiar with the Islands of Jenkins, I want to explain the problem in more detail. Additionally, I’ll detail how CloudBees CI can provide you with further relief.
What is Jenkins?
If you’re an experienced Jenkins user, feel free to jump to the next section.
If you’re fairly new to, or unfamiliar with Jenkins then essentially Jenkins is an open-source automation server that helps to automate parts of the software development process. It provides hundreds of plugins to support building, deploying, and automating any project. Additionally, Jenkins itself can be used to automate tasks including building, testing, and deploying software. Furthermore, it also facilitates continuous integration (CI) and continuous delivery (CD). Fundamentally, Jenkins is a key software tool used in DevOps practices.
Jenkins key features:
- Support for a wide range of project types, including web applications, mobile applications, and system administration tasks.
- A web-based user interface that makes it easy to set up, configure build and deployment pipelines.
- Downloadable, open-source software allowing users to install it inside any infrastructure (behind the firewall or in the cloud).
- The ability to run tasks concurrently on multiple machines, enabling faster builds and deployments.
- Integration with a variety of tools and services, including version control systems, testing frameworks, and deployment tools.
Jenkins is written in Java and is highly extensible, making it easy to create custom plugins to support specific needs. It is widely used by developers, DevOps engineers, and system administrators to automate tasks and streamline the software development process.
How “Islands of Jenkins” Start
When companies use the open source Jenkins software for building software typically, the initiative is done by a development team member who needs to solve a problem. These developers, who are mostly members of Agile development teams and are self organizing.
Shiva’s Story
A developer (let’s call him Shiva) needs the ability to test his team’s builds and integrate the code they create. Because Shiva is the technical team lead, he is often given architectural challenges to help solve. Shiva doesn’t have a great relationship with many people in the IT organization, but he knows many of them from past projects. Because of this, Shiva has done some shadow IT work for his development team. And he’s done this by using infrastructure provided to him for another purpose to install Jenkins.
Shiva knows the benefits of having a Jenkins controller that’s just for his team will allow him to manage performance and feedback from the team. If the Jenkins controller becomes slow, he will be able to gauge that against work being done by the team. Shiva can discuss this at his daily standup meetings with his team. And if Shiva had a good relationship with IT, he may share this information with the IT staff. However since Shiva doesn’t have a good relationship with IT staff members, he may just keep this information to himself and attempt to fix any problems that arise.
Sally’s Story
Now, let’s flip the narrative and view it from the IT side of the business. Sally is a systems administrator in the IT group at the same company. She has worked with Shiva in the past. And because she has high standards for change management and documentation, she doesn’t appreciate Shiva overstepping his role as a developer to:
- Make changes to infrastructure or,
- setup infrastructure that is not easily transferable to the production environment.
Sally’s boss, Alex, finds that there has been a security vulnerability announced in the open source version of Jenkins. Sally is tasked to patch the company’s Jenkins controllers. Alex knows from previous experience that there are three versions of Jenkins installed in the company because he set them up years before. He also helps to manage them. However, Alex is not aware of Shiva’s Jenkins machine that has been in use for the past three months. Neither does Sally. So, Sally makes a change management plan based upon company policy. She completes the updates for the three Jenkins instances over the course of two weeks. However, Shiva’s Jenkins instance is not updated. Now, Shiva’s system is vulnerable to attack.
The Vast Unknown Of The Island of Jenkins
Now, consider that three person story in an large organization, or within a company hosting virtual machines. This problem could be magnified threefold. Consequently, it can lead to “islands” of unknown Jenkins instances that IT is responsible for managing.
Not only is this a waste of software developer time, it also highlights severe communication issues between software development teams and IT operations. The DevOps model attempts to resolve this conflict by asking teams to work collaboratively and an improved culture of shared responsibility and communication. However, the reality is that this scenario happens all too often.
While Alex, Sally and Shiva are not real people in this example, they are 100% real people in the real world of Islands of Jenkins. So how do you solve this problem?
The DevOps Fix for Islands of Jenkins
Everybody’s definition of DevOps is a bit different. Even the standard definition inside the industry of DevOps professionals changes every few years. What’s more? If you ask one thought leader vs. another, you’ll probably get two definitions. However, the one constant I’ve seen by thought leaders over the years is the one I shared in the What is DevOps video below… This video, talks about a few important, less-technical, components that would help solve the problem described above.
The definition of DevOps is the concept of “people working better together” is the point I made above with Shiva and Sally. So, if Shiva and Sally had a great relationship, Shiva would be open to discussing his need of a Jenkins controller with Sally. This would allow Sally to:
- Organize that infrastructure request.
- Document the need.
- Ensure that it is Jenkins managed by her team.
- The correct attention and due-diligence is given to that environment.
In short, the fact that Shiva and Sally have a good relationship enables the systems that both teams have put in place to work. The phrase “culture eats strategy for breakfast” applies well in this example. Why? Because that deepened relationship between Shiva and Sally enables so many good things to happen in the organization.
The CloudBees CI Fix for Islands of Jenkins
IT teams are increasingly asked to do more with less and to help companies beat marketplace competition. That’s why there has to be some level of applicable scale to Sally and Shiva’s problem. One solution is to enable Sally to manage the infrastructure and Jenkins more easily with the adoption of CloudBees CI.
CloudBees CI Features And Tools
CloudBees CI, was known formerly as Jenkins Enterprise. It is a continuous integration (CI) platform built on top of the open source version of Jenkins. CloudBees CI is designed to help organizations automate the build, test, and deployment of software projects. Additionally, it is used across a variety of industries.
CloudBees CI also offers a range of features and tools to support the development process. These include:
- Support for multiple languages and frameworks.
- Integration with a variety of tools and services.
- The ability to scale build and test environments as needed.
CloudBees CI is a powerful and feature-rich platform helping organizations to:
- Automate and streamline their software development and delivery processes.
- Improve the quality and reliability of their software.
We’ve seen how CloudBees CI can help Shiva, but how can it help Sally? Well, CloudBees CI has the ability to manage multiple Jenkins controllers but still apply governance and management from a single pane of glass. Thus, each Jenkins controller can be customized to the plugins and needs of the particular team that’s using it. In parallel, Sally can ensure updates are applied in a timely manner and these changes are logged in their change management process.
Scaling Jenkins with CloudBees CI and SPK
Because Jenkins is so widely used by large and small organizations, it’s inevitable that there will be scaling problems. CloudBees CI provides the platform to support that scalability and the compliance needs that your organization has. SPK is a proud CloudBees partner and recently won CloudBees 2022 Service Partner of the Year.
With CloudBees CI, you get unlimited licensing of controllers. This means you can readily scale your environment to meet your organization’s needs and job demands. SPK and Associates is a certified CI and CD/RO CloudBees partner and we can help you to install, manage and maintain your CloudBees enterprise architecture.
Contact us here to speak with our CloudBees and DevOps experts.
