Is Jenkins Really Free? The Costs of Low Visibility


Iris Chubb

Iris Chubb


Chocolatey in the Enterprise: Privatization & Internalization 27th February, 2023

What is Maven and How Does it Work With Jenkins? 19th October, 2021


Is Jenkins Really Free? The Costs of Low Visibility

Posted on .

Jenkins is a really popular free automation tool, but poor visibility often undermines its potential. Poor visibility into Jenkins installs and projects creates chaos, can disrupt work, and increases risk.


Visibility is often the most important factor in implementing successful DevOps in your organization. Good visibility will allow for smooth, consistent, and high-quality releases, while bad visibility accomplishes the exact opposite.  According to the 2019 DevOps Visibility Report, 84% of organizations stated that DevOps visibility is important to them. 

So basically, visibility is really really important! Ironically, one of the most popular DevOps tools out there, Jenkins, severely lacks visibility.

In this blog, I’ll outline the problems Jenkins has with visibility as well as some solutions to get more visibility into your DevOps process.   

ProblemJenkins Project Ownership is Unclear 

Unlike dedicated CI/CD tools, Jenkins does not have “applications” or “releases.” Instead, everything has to be its own project (what used to be called jobs). Though there is a plugin for folders and views, you can’t categorize or organize Jenkins projects easily or clearly without work. This inevitably leads to confusion over who owns Jenkin’s project. You could accidentally work on someone else’s project and mess it up, delete it, or someone else can mess with your project and potentially lock the entire Jenkins instance. Good luck finding out who to blame 😐. 

Effect: Instance Locking 

Instances may lock if someone makes a mistake on a project that isn’t theirs. Unfortunately, given the lack of proper tools to easily organize Jenkins projects, a mistake that locks an instance is only a typo or misclick away. The likelihood of an instance lock occurring scales exponentially as you pack on more and more projects.  

💥Impact: All Jenkins Work Halts 

As you work out the who and what of the changes that locked the project, all work is halted and valuable time is lost. Lack of visibility leads to confusion, which slows down work and could risk more than just lost time. When visibility is obscured between users, teams, and installs, Jenkins instances become legacy/outmoded much faster. 

Problem: Information you may need for auditing or rollbacks are not centralized 

Go ahead and try Googling how to audit or roll back in Jenkins. Seriously, give it a quick Google, I’ll wait… 

I’m guessing you found people who had projects accidentally deleted or some other reason to roll back changes just to be told the only way to do that is to download plugins. Humans are prone to errors making Jenkin’s lack of internal auditing tools extremely irritating.  

EffectYou rely on people’s memories rather than on a tool 

Turns out humans are error-prone and aren’t great at remembering details. Unfortunately, without centralized information or auditing tools, people’s memories are often your best shot at getting that Jenkins project up and running again.    

💥ImpactRisk increases 

Human memory is hopelessly outmatched when compared to software logs. The functionality and success of a project depending on someone’s memory of a specific change is a terrifying prospect and all too common occurrence for Jenkins users.  

Visibility = Viability: BuildMaster 

Jenkins is a CI server that can do general-purpose automation and is designed as a powerful tool for automation experts. Meanwhile, BuildMaster is a Continuous Delivery (CD) tool that orchestrates application release and deployment and can integrate with tools like Jenkins for CI (or do its own CI). It’s also designed for the whole team, and not just the experts. 

We have an in-depth blog post comparing Jenkins and BuildMaster if you’re curious!  

Solution: BuildMaster offers Visibility 

BuildMaster excels at issue tracking and providing visibility across the entire team. BuildMaster automatically tracks the state of code and updates issues statutes in your tracker accordingly. Your team always knows the true state of a change request and so can always execute the process perfectly. The state of the code, updates, and changes are all displayed on a single dashboard. 

Jenkins has its limitations, but we still think it’s a great tool! If you’re used to Jenkins and want to keep using it, go for it! BuildMaster will import artifacts directly from Jenkins and then handle all of the deployment complexity. It can also automatically queue builds in Jenkins, which means you can have BuildMaster use Jenkins behind the scenes. Importing an artifact ensures BuildMaster will be able to deploy it to future stages whether Jenkins is accessible or not, and you can capture these artifacts in BuildMaster using the Jenkins::Import-Artifact operation. 

You can use the Jenkins Build Number output variable to capture actual Jenkins build numbers, which will help create a visible association between the BuildMaster build and Jenkins. Not only is this great for visibility (a core part of DevOps), but it also helps simplify audits by creating an easy-to-find “paper trail. 

Solution: Plan Version Control and Rollback 

BuildMaster maintains a history of edits and allows rollback to any plan version, similar to a “revert” in source control. Version history is maintained for both build plans and modules. 

Comparing Versions: A list of all versions of a plan and options to compare any previous versions with the current are displayed in BuildMaster. You can also do a side-by-side comparison of any global plan or plan from any application visible to a user. 

Plan Rollback: BuildMaster does not have a special “rollback plan” that’s used only in emergencies. Since such a plan would only get tested in rare cases (i.e. when something went wrong), chances are it will be out of date and likely make things even worse. BuildMaster can easily roll back plans and create a new version of the plan with the same contents as the rollback target. 

Remove the Risk of Poor Visibility 

If your team has visibility into releases, you can be confident that the code you have developed meets your quality standards. Furthermore, with more visibility, you can fix any potential problems that arrive efficiently and get deployments out faster!   

Remove the risk of poor visibility by either Downloading BuildMaster and using it for CI/CD or integrating Jenkins and letting BuildMaster provide the visibility component that Jenkins is lacking.

Iris Chubb

Iris Chubb