Jenkins and BuildMaster are different products, that solve different problems, and both are commonly used as part of a modern DevOps Toolchain. A side-by-side comparison would be a bit like Word and Excel: both can be used to create forms that you’ll print out, but if that’s the only thing your business uses Microsoft Office for, you’re certainly not doing it right.
Already familiar with Jenkins? The terminology comparison may help you get a quicker understanding of BuildMaster.
This can really be boiled down to: Builds vs. Releases.
Fundamentally, Builds and Releases vary in two distinct ways: Builds meet developer or development needs, and Releases fulfill the IT organization requirements, and deliver end results. By separating tools into these unique, and separately functioning categories, you are able to address and solve, the individual problem or requirement associated with each.
Although CI and ARA are two distinct separate processes, to address two distinct problems, some seek a single, multi-purpose tool to do it all. Obviously, no such tool exists, but many will attempt to shoehorn Jenkins for this purpose; according to its makers, “ Jenkins is the Swiss army knife in the software delivery toolchain.”
Just as a Swiss army knife is no replacement for a toolbox, Jenkins is simply not suitable for implementing a modern DevOps process.
Like all Continuous Integration tools, Jenkins is focused on build automation. This is implemented through Jobs, which are designed to run a build script, and are comprised of the following:
Of course, since a build script could just be an arbitrary script, a job could be used to do anything. And thus, Jenkins could be used for anything… especially as a DevOps Swiss army knife!
But just as an all-purpose Job Scheduler would be a poor choice for build automation jobs, Jenkins is an equally-poor choice for an all-purpose job scheduler. It lacks the features all other job schedulers have because it was never designed as a job scheduler.
Moreover, both job schedulers and build automation tools are poor choices for application release automation, and deployment.
A build/release pipeline facilitates the process of deploying both large and mission-critical changes, and unscheduled emergency deployments of an application.
In Jenkins, a Pipeline is a special type of Job that’s implemented through a plugin originally called Workflows. Essentially, a Pipeline job is a sequence of steps that are grouped into stages and that may run on a particular node. Like a job, a step could “do anything”, but it’s designed for a single, discrete task, and generally is used to run other jobs; there are a handful of built-in steps for things such as running scripts and sending emails.
Jenkin’s Pipelines are very similar to BuildMaster’s Legacy Deployment Plans; Actions are like Steps, Action Groups are like Stages, and both Actions, and Action Groups, had a Node-like context.
However, neither are suitable on their own for release automation. A layer on top is needed for process orchestration, such as approval gates, manual intervention, security, and so on.
Although Jenkins is a poor choice for release automation, it’s definitely a proven build automation tool. This is exactly why BuildMaster has a tight integration with it; with the Jenkins extension, you can import build artifacts into BuildMaster, apply the necessary approvals, additional testing, and deploy to production.
Alternatively, you can use ProGet to host all your packages, binaries, and Jenkins Build Artifacts.
|Jobs||Applications||Jenkins jobs are typically a Maven projects or any of a variety of free-style projects (Visual Studio solutions, MSBuild scrips, make files, etc) while BuildMaster applications represent an entire standalone application.|
|Job Configuration||Deployment Plan|
|Pipelines||Deployment Plan||A pipeline in Jenkins is a type of job configuration|
|Job Triggers||Release Package Triggers|