Buddy and Jenkins find themselves on completely opposite ends of the CI/CD spectrum. So which one should you go for? It certainly is a question of context. There are some clear technical differences but how they relate to actual value is circumstantial and should be taken on a case by case basis. As such, this comparison will be broken down into two sections.
- The Technical Key technical differences that are worth understanding before making your choice.
- The Tactical - Differences that are influenced by the context in which the technology is used, and when each tool might be beneficial.
Between these dimensions, technical & tactical, we will build up a clear image of how these technologies behave and which one is the right choice for your organisation.
The Technical
The technical divide between these technologies is vast. To keep things composed and relevant, we'll dig into some key features and discuss how they measure up. For each section, we'll compare the features on offer by both platforms as well as any comments of our direct experience with these aspects of both platforms.
Let's get to it.
Summary
This table provides a high level summary of the discussion below, should you wish to see the differences at a glance.
Deployment
Deployment is a sensible place to begin. How difficult is it to get an instance of each tool up and running? Well, it's a somewhat one-sided example. Buddy is a SaaS offering, meaning there is nothing to get running on your side. You simply click a couple of buttons and you're away.
You'll need a platform on which to deploy it, such as an EC2 instance or a Kubernetes cluster.
Maintenance
Jenkins servers have been known to crash and fail regularly and have required tuning in the past. This is often an experience issue, rather than a problem with the tool. A properly configured Jenkins instance will run without fault for as long as it needs to.
This is another one sided example. Buddy is a managed offering, meaning you don't need to actively maintain it. This is covered as part of your subscription.
Integrations
Buddy comes prepackaged with a plethora of integrations that have been developed in house. As such, plugins don't interfere with one another and quality can be assured centrally. Deploying to AWS Lambda or to Kubernetes is a button click away.
Integrations in Jenkins come in the form of plugins. Some of them have been developed in house, many more have been developed by the open source community. If an integration doesn't exist, you can always create the plugin yourself. Alas, as many of us who have worked with Jenkins before know, these plugins can collide with one another in unexpected ways.
Pipelines
Finally, the star of the show. With Buddy, you have two options. Using the website or writing your
buddy.yamlbuddy.yaml- pipeline: "my-lambda-pipeline"
trigger_mode: "ON_EVERY_PUSH"
ref_name: "master"
ref_type: "BRANCH"
trigger_condition: "ALWAYS"
actions:
- action: "Execute: mvn clean install"
type: "BUILD"
working_directory: "/buddy/buddy-lambda-example-1"
docker_image_name: "library/maven"
docker_image_tag: "3.3.3"
execute_commands:
- "mvn clean install"
cached_dirs:
- "/root/.m2/repository"
mount_filesystem_path: "/buddy/buddy-lambda-example-1"
shell: "BASH"
trigger_condition: "ALWAYS"Jenkins has similar offerings. One can use the UI to create a pipeline, although this has recently fallen out of favour. It also offers pipeline as code in the form of a Jenkinsfile. There are two options for your Jenkinsfile. Declarative and scripted.
A declarative pipeline makes extensive use of the Jenkins DSL to generate pipelines, but doesn't play nicely when wishing to run custom groovy scripts. It is a higher level of abstraction than its scripted alternative, aimed at those wishing to create simple pipelines.
groovypipeline {
agent none
stages {
stage('Example Build') {
agent { docker 'maven:3-alpine' }
steps {
echo 'Hello, Maven'
sh 'mvn --version'
}
}
stage('Example Test') {
agent { docker 'openjdk:8-jre' }
steps {
echo 'Hello, JDK'
sh 'java -version'
}
}
}
}The scripted alternative is far more flexible, but lacks the clarity of the declarative pipeline. At its core, a Jenkinsfile is simply a groovy script. With a scripted Jenkinsfile, you've got much more flexibility. This approach is favoured when wishing to execute multiple custom groovy commands, or when making use of Jenkins global shared libraries functionality.
groovynode {
stage('Example') {
if(env.BRANCH_NAME == 'master') {
echo 'I only execute on the master branch'
} else {
echo 'I execute elsewhere'
}
}
}In the UI, Jenkins offers a description of each stage, along with the time it took for each stage to run. This updates in (almost) real time as the build progresses.
Buddy offers something very similar. When you click run, you can see a live updating screen that shows the output of each stage in your build.
From both of these user interfaces, you can dig into the specific logs for that section or see failure reasons.
Buddy does have a cool little feature that shows you how complete a stage is, based on its previous execution time. While Jenkins also offers this, in my experience it doesn't always line up with reality and it isn't as clear.
The Tactical
When choosing your ideal CI/CD tool, technical features aren't all that count. The maturity of your organisation and your priorities should come into play. While these are impacted by technical features, they deserve mentioning in their own right.
Summary
As with the technical section, a high level summary has been provided for easier reading. Each category has been expanded below, for a more in depth understanding.
Effort
It is a given that a SaaS solution poses far less setup complexity than a locally hosted alternative. It is possible to go from 0 to running with Buddy in minutes. Without a good understanding of Jenkins, this is highly unlikely. The question to ask yourself here is clear. Do we have the time and capability for this?
For some organisations that already have a mature Operations or Site Reliability function, this may not be a daunting task. Most companies don't, and for them, tools like Jenkins are not a trivial undertaking.
Pricing
Jenkins is a completely free offering. Setup, subscription and maintenance are completely free of subscription or licensing costs. By contrast, Buddy charges a monthly subscription.
Yet, there is a hidden cost to Jenkins. Salaries, overtime, setup delays, and vulnerabilities all present a difficult cost to quantify. You're entering into the arms race.
When compared against Buddy's subscription model, it is clear what is being sold - responsibility. This links back to the previous section. If you already have a sophisticated Operations or SRE function, then you're likely already paying this cost. Most companies don't have this.
If this isn't something you have, it might be wiser to go with the known quantity and start out with Buddy. You can always grow your own capability later, as the need arises.
Customisation
If a new, fancy technology came out next week, a Jenkins plugin would likely pop up quickly. It would be provided by a vast open source community. The quality assurance for this plugin would be at the discretion of the engineer who wrote it and there is no recourse for a critical vulnerability or bug. If this was a major concern, you could always develop your very own plugin.
And you'll be spending quite a bit of time on this tab!
With Buddy, the customisation options are more limited. You won't be able to build your own integration, but you can use the existing integrations to do more flexible things. For example, using the "Local Shell" integration to run some custom scripts in a Linux environment.
When Buddy do come out with a specific integration for this new technology, it will have been developed in house, checked for vulnerabilities and will be constantly updated as part of your support agreement. No need to keep it updated and no risk of it clashing with another integration.
Specialist Knowledge
Offices running Jenkins servers regularly run into this problem. It was installed some time ago, the vulnerabilities have stacked up and no one knows enough to make any changes. A working knowledge of Jenkins is required to get off of the ground in a sustainable way. Without it, you might be able to get up and running, but staying there will be difficult.
This is usually solved by engineers who have a good understanding of how Jenkins works under the hood. It is a complicated beast and requires time and effort. If you don't have anyone with these skills, the installation of a Jenkins instance is likely going to force the need for one. If you don't want to grow that capability, it mightnot be a wise choice.
Buddy is very different
BuddyCI is a SaaS offering with a very intuitive user interface. Its integrations come with sensible defaults and clear instructions. Without the maintenance and installation burden, the only learning requirement is working with the tool itself. This requires no in-depth knowledge of Buddy's internals whatsoever.
If you have a team of engineers and your current ambition is to simply develop features, a subscription fee to relieve your team of this burden might be the best foot forward.