One of the first questions I asked in my job interview at Inedo was “Why/How is BuildMaster better than Jenkins?” As a seasoned Jenkins user, I wanted to know how any commercial product could possibly compete with the free and open-source continuous integration (CI) server that basically everyone is using.

The answer surprised me, and I realized my question was almost like asking “Why/How is Google Chrome better than Microsoft Word? ” They’re both first-rate in their space, and they both can be used to accomplish the same tasks, but clearly one is better than the other at some things. In a nutshell:

Jenkins is a CI server that can do general-purpose automation, and is designed as a power tool for automation experts.

BuildMaster is Continuous Delivery (CD) tool that orchestrates application release and deployment, and can integrate with tools like Jenkins for CI (or do it’s own CI). It’s also designed for the whole team, and not just the experts.

In this article, I’ll show you how Jenkins and BuildMaster directly compete BUT ALSO how you can use BuildMaster WITH Jenkins for the best of both worlds.

Head-to-head Comparison

A head-to-head comparison is difficult, because the two tools are different and solve similar problems in different ways. But I’ll do my best to show how Features, Core Competencies, and the Automation Engine compare.

Features: Plug-in vs Built-in

It’s inaccurate and unfair to compare the features of Jenkins with most other tools, because Jenkins is plugin-driven. Of course, BuildMaster has plugins as well, but that mostly is to integrate with other tools.

Because of Jenkins plugins, it can literally do everything. It can do CI, CD, testing, run PowerShell scripts, and much more, all via plugins. You can even create a whole new UI with plugins, which is what the “BlueOcean” plugin has done.

However, these plugins create a love/hate relationship with Jenkins, because often plugins are minimally functional, especially when compared with a dedicated tool.

All BuildMaster features are designed as much for the casual user as for the power-user. BuildMaster can be your only CI/CD tool, but we also designed it to integrate with nearly every other DevOps tool you might be using. It’s mature enough for experts but accessible enough to enable self-service for non-experts. It works just as well for teams of two as for organizations of two thousand. Get a full run-down of BuildMaster’s features.

Core Competencies: CI vs CI/CD

Jenkins is a general-purpose automation tool with CI strength. Or perhaps it’s more accurate to say that Jenkins is a CI tool that has become an automation generalist due to its plugins. Without doubt, its core competencies are CI and automated testing.

But for Jenkins functionality outside CI and testing? Nothing can be every single thing at once. There are things Jenkins is very good at, and things that it can do but will never excel at.

By contrast, since version 1.0, BuildMaster has been a CI/CD tool. We built and improved it to perform exceptionally at end-to-end DevOps tasks. CD has been an essential function of BuildMaster from its inception.

Under-the-hood: Automation Engine

Jenkins does all its work via Projects and the Pipelines plugin (now a standard part of Jenkins). Jenkins Pipelines is the Jenkins execution engine, and it really cannot be changed with other plugins. And using Jenkins Pipelines requires learning Groovy-based DSL, and learning the ins-and-outs of Jenkins Pipelines is hard not just for inexperienced coders but even for seasoned engineers.

Oh, and Jenkins Pipelines aren’t CD pipelines. Although they’re called the same thing, Pipelines in Jenkins (note the capital P) does not describe a release pipeline like you may desire and will find in BuildMaster.

BuildMaster’s automation engine is based in OtterScript, capable of running thousands of different operations and scripts on thousands of different servers. OtterScript is a rather easy DSL to learn, because you don’t have to learn it to use it! OtterScript can be viewed, read, and edited either in text mode (the traditional code look) or in visual mode (essentially a drag-n-drop GUI). The GIF below is from Otter, but the OtterScript visual mode interface for BuildMaster is identical

Additionally, BuildMaster’s deployment pipelines are actual CD pipelines, designed to let you build a repeatable release process by defining the servers and environments that your builds will be deployed to and to set up the manual and automatic approvals required at each stage of the process. Out of the box, BuildMaster is ready to deploy your applications; not fancy footwork required like in Jenkins.

Why Jenkins Isn’t the Best Choice for End-to-end CI/CD

There are five main reasons that trying to do all your CI/CD with Jenkins isn’t the best choice.

1. Jenkins is extraordinarily powerful, but only if you have an expert on staff all the time. And becoming a Jenkins expert takes lots of time.
2. Because it takes so long to become an expert in Jenkins, you probably only have one expert, who then becomes a bottleneck. You’re also losing all their other capabilities to Jenkins, not to mention that it will be costly to replace them if they leave.
3. Jenkins is free and open-source and has plugins galore. But because anyone can theoretically do anything in Jenkins, self-service can be quite risky. It’s very easy for someone to introduce a plugin with a nasty surprise inside or to break a dependency.
4. Poor visibility is a Jenkins reality, especially for non-experts. Accidentally locking an instance and not knowing how to find rollback info (or whether it even exists) are common, because everything in Jenkins has to be its own Project.
5. Scaling Jenkins—that is, Jenkins growing easily alongside your organization’s staff and workload—is very difficult, based on the previous four points.

Why Jenkins and BuildMaster Make a Great Combo

Don’t dump Jenkins! Replacing it entirely would cost too much, and your team already knows Jenkins.

Instead, combine it with BuildMaster! Did you know that most BuildMaster customers already do this? That’s because combining these two, dedicated tools gives you better CI/CD overall.

What does this look like? For a full rundown of integrating BuildMaster and Jenkins, you’ll want to check out our Docs page. But here’s the “meat and potatoes.”

Import Build

Jenkins can be configured to not only compile your application’s source code and run automated tests against it but also to capture “artifacts” of that process. These artifacts typically include whatever files the compiler output, i.e., your compiled application.

Developers used to Jenkins CI can keep building and testing code with it, and BuildMaster can capture those builds and push them through deployment pipelines for release.

Import Build Artifacts

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.

Note that you can use the JenkinsBuildNumber 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.”

Automatically Queue Builds

This essentially puts BuildMaster in charge of Jenkins; BuildMaster asks Jenkins specifically for what it needs, instead of dealing with every Jenkins project based on every code commit.

Jenkins kicks off a build on every single commit (takes code, compiles, saves), so how to know which one is an RC? BuildMaster can trigger a “project” to build an RC build by passing parameters into Jenkins (e.g., takes code, compiles, does a bunch of complex testing maybe once a day, saves, THEN sends it over into BuildMaster).

This also can speed up Jenkins, as keeping too much build history data in Jenkins is an often-cited source of slow performance. Furthermore, BuildMaster can keep lots of logs without slowing down, and the logs will be more useful because they will only be about builds headed further down the pipeline.

Using the Jenkins::Queue-Build operation, you can queue builds in Jenkins for such purposes as:

• kicking off a “Release Configuration” build that instructs the compiler to optimize for speed and does not include debugging symbols.
• injecting contextual information from BuildMaster (release number, etc.) into the application code after it’s checked-out but prior to being built by Jenkins; you can then display this information once the application is running in an environment.
• linking from Jenkins back to the application or build in BuildMaster, so you can have cross-links in both system.
• executing a project in Jenkins that performs automated tests after performing a deployment from BuildMaster.

Deploying Jenkins Artifacts

No matter how they end up in BuildMaster, BuildMaster can deploy Jenkins artifacts through its superb release pipelines to any number of servers/targets, just by using the Deploy-Artifact operation.

Sometimes a Swiss Army Knife Just Won’t Cut It

According to its makers, “Jenkins is the Swiss army knife in the software delivery toolchain.” While a Swiss army knife can do a lot, it often can’t compare to the dedicated tool for the job you’re facing.

Let Jenkins do what it’s great at—Continuous Integration and testing—and pair it with a true Continuous Delivery solution like BuildMaster to do CI/CD the right way.