This blog came at the request of several customers who found our story compelling but wanted to share it with a wider audience inside their organization, including team members who use Jenkins.
I’ll start by saying this: at Harness, we use Jenkins internally, and as of today, all our customers use Jenkins. Any new entrant to the CI/CD space will always be compared to what currently exists, as you’ll see in this blog the overlap between Jenkins and Harness is minimal.
A good place to start with any product comparison is first impressions, or what users first see when they log in.
Let’s begin with the Jenkins homepage. What descriptors or labels are used the most frequently? Yep, “build.” It’s used five times and more than any other term.
Next, let’s do the same for Harness. This time “Deployment” is the most common descriptor, and it’s used six times.
In short, use Jenkins for builds and Harness for deployments. Sounds simple, right?
Continuous Integration vs. Delivery
Our customers typically use Jenkins for Continuous Integration use cases (build & test) that helps them take code to artifact. Harness was specifically designed for Continuous Delivery and taking those artifacts into production. In fact, Harness built (no pun intended) native integration with Jenkins so our customers can master CI/CD. Below is how we would summarize the two different solutions:
What About Jenkins Pipelines?
I’ve downloaded it, played with it, and listened to feedback from customers on it. Blue Ocean is a huge visual improvement over the original Jenkins skin, and the ability to use declarative pipelines is nice so you can structure and manage all of your existing Jenkins jobs (custom scripts) as pipeline stages.
Jenkins is excellent at script orchestration. However, scripts don’t script themselves and require big time & dime to build, implement, and maintain. Scripting may be entirely manageable for simple, small, well-defined environments, but for mid-market and enterprises, it’s often a never-ending journey that gets very expensive.
Scripting Continuous Delivery Is Tough
CD is way more than spinning up a few compute nodes and copying files. Once you create artifacts from code, you’ve got things to manage like secrets, environments, release strategies (blue/green, and canary), as well as the verification and rollback of deployments if anything fails. Throw in some governance, audit trails, access control, approvals, reporting, and the number of CD scripts/time/dime starts to add up rapidly.
With Jenkins, you still need to create & maintain scripts in each of the above areas so they can be orchestrated by Jenkins. Yes, you can download 3rd party plugins to shortcut some of these, but you’re essentially building your own CD platform from scratch.
CD As-A-Service With Harness
With Harness, we’ve templatized 95% of the above CD requirements, capabilities, and integrations so everything works together. This allows us to offer CD-As-A-Service so you don’t have to build a bespoke CD platform yourself. Think of Harness as a turnkey CD solution that developers can use from day one vs. a CD toolkit they need to build.
Reuse Jenkins Jobs & Shell Scripts within Harness
The good news is that whatever you’ve done to-date with Jenkins (and shell scripts) it can be reused and migrated to Harness in minutes for Continuous Delivery.
Harness treats Jenkins as a first-class citizen and has native support in addition to other CI platforms (Bamboo, Travis, …) so you can manage and reference all your existing Jenkins masters.
In addition, you can reference any Jenkins jobs or shell scripts as steps in Harness workflows:
Again, one of our early customers Build.com was able to migrate their existing Jenkins jobs and CD scripts to Harness on day one of their evaluation.
Automatic Verification and Rollback of Deployments
Besides deployment automation, the most obvious difference between Jenkins and Harness is our Continuous Verification capability that allows customers to automatically verify production deployments through the use of unsupervised machine learning.
Simply put, Harness connects to your existing monitoring ecosystem (AppDynamics, New Relic, Dynatrace, Splunk, ELK, Sumo, …) and automatically analyzes all time-series metrics and unstructured log data to detect performance and quality regressions instantly. Think of this as your DevOps feedback loop when a new deployment hits production.
Instead of engineers or team leads manually looking at charts and log entries for hours, Harness is able to automate this task and flag anomalies instantly. We can even go one better and automatically rollback the service/app to the last working version. Learn how Build.com achieved this in 32 seconds.
Here’s a quick glance at what continuous verification looks like for unstructured log data in Splunk:
Jenkins for CI, Harness for CD
It’s certainly true you can build a CD platform yourself using Jenkins and scripts. An entry-level CD platform will probably take 3-4 FTE engineers 1-year to build and another 1-2 FTEs to maintain each year as your apps, services, and stacks evolve. In the enterprise, you can easily multiply those numbers by 5 or 6 depending on the scale and stacks you have.
Harness is an alternative option that can deliver with CD As-A-Service to your developers and teams. We work well with all existing CI platforms and have the integrations to work with what you have today, and more importantly, tomorrow. As an example, we shipped AWS Lambda support back in October of 2017 and we’ll ship Microsoft Azure support later this year along with a list of other platforms.
Being British, I’d like to think of Jenkins and Harness as Fish and Chips (they taste pretty good together).