Jenkins PTSD: How One Developer Ditched the Butler For Good

If Jenkins was created to solve the pain point of automating the CI process, why does it require so much scripting? The purpose of automation is to run or operate by using machines or computers instead of people, but with the huge startup cost associated with creating a Jenkins pipeline, can you still call Jenkins an automated CI tool?

The Security Blanket of the Butler

Prior to Harness, I worked a lot with the little butler we call Jenkins. He was always a friendly face that greeted me as I went to check on my pipeline builds. I would spend hours with this butler tweaking different configurations and code, praying for a successful green pipeline.

Jenkins was all I knew when it came to CI tooling. Every project I worked on would have a Jenkinsfile that laid out the stages. Sometimes it would be hacked together and we would use magic, as we called it, to successfully run the pipeline. When I went to manually script out my first pipeline from scratch, I didn’t know how to start. I sat embarrassed as I had worked with many Jenkinsfiles before - maintaining, troubleshooting, and creating additional steps - but to my dismay, I didn’t know how to start. Creating these pipelines requires a lot more work than you may think. It may seem like an easy scripting task, but the amount of steps and dependencies involved makes it long and arduous.

Simply put: Jenkins is an old tool, and there are many alternatives to consider. It was designed before the cloud era, which is evident in the idiosyncratic steps you have to go through installing it via an automated script because it was designed for a manual installation. Jenkins is not a tool built to leverage automation as it is hard to set up, create, maintain, and automate.  

A couple months ago I was preparing to give a demo of the new pipeline my team had built out. The pipeline had an infrastructure piece where, with automation, it stood up a brand new cluster with all the necessary applications, including Jenkins. Within this new environment, I had to give a demo - but as I was trying to deploy the sample application via Jenkins, I got an error where it was not able to pull the correct git repository. 

I started to troubleshoot. All the connections were in place and there wasn’t anything wrong with the Jenkinsfile. I couldn’t figure out what was wrong. While comparing with a different Jenkins instance that had been set up previously, I noticed that there was a checkbox that hadn’t been checked off in the new instance. That one manual checkbox was what kept me from successfully running the pipeline. Because Jenkins relies on plugins for every little task being performed, all your t’s must be crossed and i’s dotted before a successful run. 

Maybe It's Time to Retire, Mr. Butler

All of this could be avoided with Harness. I’m not just saying this because I work for Harness but because when I saw the capabilities of the platform, the inner nerd in me squealed. The features of Harness really got rid of all the pain points that I had felt as a software consultant. 

The onboarding process of putting an application on Harness couldn’t be more intuitive and simple. You create connectors to your cluster, git repository, and artifact repository and you’re on your merry way! There is no need to create thousand line Jenkinsfiles where one little symbol could cause your entire pipeline to fail, or even the need to log into the terrible UI Jenkins has.

In the standard view of Jenkins, you watch the wall of text zoom past your screen as the pipeline is being run, only to have to comb through it when you reach an error message. The Blue Ocean view isn’t that much better as it is laggy, and the logs never fit in the little pop-up where it’s supposed to. You have to return to the standard view to do everything else.

With Harness, everything is intuitive. You see the functionality you want, you click it, and there you have it. It just makes sense. To deploy an application in Harness, you first create an application. A Harness application represents a group of microservices. Then, within the application, you create services, which represent your microservices. Environments, which represent your deployment infrastructures. Workflows, which define the deployment orchestration steps.

Pipelines, which define multiple workflows and approvals. Infrastructure provisioners, which define blueprints from known IaC technologies to enable workflows to provision infrastructure. And if needed, triggers, which automate deployments using a variety of conditions. Each of these entities provides an easy-to-use interface where you can fill in all the necessary information. There is no need to define these variables in a Jenkinsfile or even worry about creating a Jenkinsfile! Harness eliminates all that work. 

The juxtaposition between Jenkins and Harness is like night and day. With Harness, the technology has finally caught up with the modern computing world. Tools like Jenkins are outdated and cannot compete with the new features and implementations that are provided by the Harness software delivery platform. Even though Jenkins is an automated CI tool, it does not perform the way true automation should, like Harness. Get your free trial now, and see why people are firing their butler.

Want to learn more? See our comparison of Jenkins vs Harness.