In the world of Continuous Integration and Continuous Deployment, CircleCI and Jenkins are two names that people mention early in the discussion. Despite negative sentiment that can surround either of them due to their age, they’re still effective tools that can help your organization deploy faster and more reliably. Both of them have many similarities and differences.
These can be mundane, such as the placement of certain UI elements, or crucial to your business, such as the price and available plugins. Let’s take a closer look at the two of them and discuss their similarities and differences.
We will cover:
Jenkins is an open-source automation server that is used for the continuous integration and continuous delivery of software. It automates various tasks such as building, testing, and deploying applications.
It is easily extendable due to its vast ecosystem of plugins, making it easy to integrate to version control systems like Git, build tools like Maven/Gradle, and deployment platforms like AWS and Docker.
Jenkins has a distributed architecture, making it easy to distribute workloads across multiple machines, speeding up the execution of jobs. This feature is really neat when it comes to large projects that are heavily tested and deployed.
Jenkins has been around since 2011. Due to its age, it’s no surprise that the creators developed Jenkins as a self-hosted application. AWS EC2 wasn’t even available until 2008, and by then, Jenkins’ predecessor, “Hudson,” was already well-established and deployed widely. Other services, such as JFrog, that provide a managed Jenkins environment, you’ll usually find Jenkins installed on bare metal servers, VMs, cloud instances, and containers. The setup is fairly straightforward for all these methods, but the management varies in complexity based on the deployment size.
A single Jenkins host is effortless to manage, but things can get unwieldy once you start creeping into double and triple digits. You can see the complexity of managing Jenkins at scale in their docs.
Unlike Jenkins, CircleCI is a Software-as-a-Service-first solution for continuous integration and delivery. They are similar in terms of capabilities. There is a self-managed version, but since the considerations involved with that are similar to the ones involved with Jenkins, we’ll stay focused on the SaaS version.
Like any SaaS product, infrastructure, scaling, and resilience management concerns are practically non-existent. CircleCI can experience outages; they have promised to reduce those.
Overall, if you aren’t concerned with being responsible for the number of 9s of uptime your deployment solution has, CircleCI is definitely the more straightforward solution to manage. Of course, if there are downtime issues for Jenkins, as it is self-hosted, you will be the one that has to solve them without any help from an external team.
Let’s take a closer look at the two tools.
Configuration Files
Self-hosted vs. SaaS is a complicated debate, but it has pretty clear pros and cons. The real concerns between these solutions involve the actual usage of the products. Overall, you’ll get practitioners that love or hate both or either solution. Overall, sentiment leans towards CircleCI due to its YAML-based configuration file. Jenkins’ Groovy syntax is very powerful, but it’s also proprietary. You probably won’t find too many native methods for Groovy in your favorite programming language. Let’s take a look at each.
With Jenkins you can configure both declarative and scripted pipeline, the difference between them being the fact that in declarative pipelines (those that start with the word pipeline), you cannot inject code directly, in the scripted ones (those that start with the word node), you can do that.
Even though, declarative pipelines may seem limiting, they are actually not, as with them, you can access environment variables, add conditional logic to the statements, and you can easily add error handling and logging.
Let’s take a look at a Jenkins declarative pipeline.
Jenkins
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building the application...'
// Add your build commands here
}
}
stage('Test') {
steps {
echo 'Running tests...'
// Add your test commands here
}
}
stage('Deploy') {
steps {
echo 'Deploying the application...'
// Add your deployment commands here
}
}
}
}CircleCI
version: 2.1
jobs:
build:
docker:
- image: <your-build-image>
steps:
- checkout
- run:
name: Build the application
command: |
echo 'Building the application...'
# Add your build commands here
test:
docker:
- image: <your-test-image>
steps:
- checkout
- run:
name: Run tests
command: |
echo 'Running tests...'
# Add your test commands here
deploy:
docker:
- image: <your-deployment-image>
steps:
- checkout
- run:
name: Deploy the application
command: |
echo 'Deploying the application...'
# Add your deployment commands here
workflows:
version: 2
build-test-deploy:
jobs:
- build
- test:
requires:
- build
- deploy:
requires:
- testThe content of the two files is similar despite the syntax differences. A significant benefit of using YAML is the native tools available in many programming languages if you need to generate these files dynamically. YAML will be more verbose, but Groovy can get a little complicated. Many engineers lament having to learn Groovy, but those who know it can create very powerful deployment scripts.
Overall, either one should be accessible to a seasoned engineer and should not be a significant hindrance.
User Interface
The two user interfaces are similar. Jenkins feels dated and very “Web 1”, even though there are attempts to make it look better (e.g., BlueOcean plugin), while CircleCI has a more modern feel.
The functional differences are there, sometimes more subtle than others, but they definitely exist. Developer sentiment between the two will typically lean toward CircleCI unless the developer has extensive experience with Jenkins.
Overall, except when monitoring your deployments, you probably won’t visit the UI as much as the command line.
Jenkins
CircleCI
Plugins and Extensibility
CircleCI and Jenkins both support most of the tools you’ll use in a typical deployment. Git providers, cloud providers, container orchestration systems, build systems, etc. The major difference is that Jenkins supports nearly anything you can imagine, while CircleCI is more focused.
Since Jenkins has direct access to SSH, if you want to run some complicated bash script to do some crazy hack to keep a server going, you got it! For this reason, I typically call Jenkins the “sledgehammer” of CI tools.
Unfortunately, as said in the comics, “With great power comes great responsibility.” This power with Jenkins can lead to massive security and reliability concerns. If an engineer has admin access to Jenkins, they can potentially do anything, including take down your production systems.
This is why it is really important to ensure proper access management, as the same engineer can even destroy the whole Jenkins installation. CircleCI is also very powerful, but its guardrails are a little easier to control because you don’t have nearly the security footprint to manage.
Since the SaaS version is separated from your production environment, building the controls necessary to prevent disaster is much easier.
Pricing
The major pro to Jenkins is the price. The software is completely free! Being free is obviously a huge selling point to the CFOs in the room. If you aren’t managing it at scale, the CapEx and OpEx involved are surprisingly minimal. It can be run as a container on a Kubernetes cluster and is largely hands-off.
Overall, Jenkins is a winner on price, but when a company introduces massive scale and resilience concerns, its self-hosted deployment method and cost can quickly lose their luster.
CircleCI, on the other hand, offers four levels of pricing which can be checked out here. Needless to say, CircleCI has a free tier that gives you five users and up to 6000 build minutes.
Infrastructure Deployments
Jenkins and CircleCI are excellent deployment tools for application code, but if you want to deploy infrastructure, they aren’t necessarily the best option. When you need self-service environments, drift detection, Terraform state management, and more, these two options don’t quite cut it.
Sure, you can bolt together products and get them close, but you spend a lot of engineering time and risk a much larger footprint vs. a solution specifically built for this purpose. Spacelift is that solution.
When comparing software products that do the same thing, the answer to this question is “It depends”.
If you are searching for a SaaS product that has an easy setup and configuration, uses a modern language (YAML) for declaring the pipeline workflows, and also offers a strong integration ecosystem, then CircleCI will be the winner for you.
On the other hand, Jenkins will win if you want something free (pay just for the infrastructure underneath it) that is highly customizable, offers an extensive plugin ecosystem, and is 100% self-managed.
The choice between CircleCI and Jenkins will also depend on the tool familiarity, the specific needs of your project, the level of control you need, and of course, the infrastructure preferences. Whenever you are choosing a software tool, it is best to evaluate by doing trials and then deciding which one aligns better with your needs.
Right now, there are many popular alternatives to Jenkins, and selecting the best one would be really hard.
Apart from CircleCI, good alternatives are GitHub Actions, GitLab CI/CD, TravisCI, and Azure Pipelines.
Below you can find a comparison table with the key features.
Jenkins and CircleCI are powerful CI/CD tools that offer distinct advantages when it comes to building your workflow. They excel at the application level, but when you need to deploy infrastructure-as-code at scale, having a tool that acts less like a sledgehammer and more like a scalpel will be the best fit.
With Spacelift, you have all the tools necessary to deploy your IaC without the bloat of app deployment build tools. So check it out today for a free trial and a custom-tailored personal demo!
The Most Flexible CI/CD Automation Tool
Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.
