By Dan Garfield, Chief Technology Evangelist, Codefresh

Jenkins, a stalwart tool for automating the build and test cycle for software, has been showing its age for a while. In speaking with software teams from TBS, AT&T, Bosch, and many others, we've collected a list of reasons why they've finally moved on from Jenkins and onto Codefresh.

1) Jenkins plugins are a source of constant problems and Codefresh's container-based pipelines are dramatically easier to manage

Ask any Jenkins admin about how they upgrade plugins and you will get an earful. Jenkins uses a global shared-library plugin model that leads to common conflicts, mis-matched versions, and breaks unsuspecting pipelines. As one Reddit user put it:

"You can have a really bad time with Jenkins if you assume you can just install plugins Willy-nilly and everything is going to be perfect."

Jenkins plugins are also centrally managed by an admin. If users want a new (or old) version, they need to file a ticket and work with the admin to get it installed and coordinate with all other users of the instance to make sure they don't conflict.

Codefresh on the other hand uses container-based pipelines. That means every Docker image is in essence a de facto plugin for Codefresh. Want to curl something? `alpine-curl` is already a thing. Want to use Terraform? Use the official release `hashicorp/terraform:12.1`. This also puts the people creating pipelines firmly in the driver's seat. Users can specify the version they want for any tool and expect to get it without any conflicts.

Jenkins users are used to the experience that someone else upgrades a plugin and breaks their pipeline without meaning to. This can't ever happen in Codefresh because each pipeline step can specify the version of whatever software it needs to use.

The container-based approach also means you can treat Docker images as functions that operate independent of the steps around them. Tools often rely on libraries with specific versions and if you want to use a tool that relies on Python 2 with a tool that uses Python 3 you now have to deal with version managers. Codefresh's container-based pipelines can use any version of any software in each step and they operate completely independently.

In fact, the container-based pipeline approach is so robust and scalable that it's leading many Jenkins users to try to make their pipelines container-based even though Jenkins wasn't designed for it. Which leads us to the next point.

2) Caching in Codefresh is automatic, easy, and fast

The main challenge with container-based pipelines is figuring out how to move things between steps. The strength of containers is their isolation, but this is also their challenge. Jenkins users building container-based pipelines often resort to mounting S3 buckets and pushing data around or using plugins that zip/unzip the workspace. Needless to say, this is not efficient.

Codefresh mounts a shared volume across the entire pipeline and every step (and therefore every container) will by default operate in that shared volume. This volume has dual purposes. 1) To make it easy to move information between steps and 2) to provide an automated caching layer.

I do a lot of pipeline conversions for users migrating to Codefresh and I find that usually 50%-70% of the legacy pipeline code is just to deal with creating and managing cache. Codefresh handles this caching in the background without any fuss. Do your build and its components are automatically cached. Download a large binary? It's automatically saved on the volume and remounted later.

This caching model has long been a favorite, as one user put it:

"Codefresh's caching model is better than anything else out there. It's really impressive!"

Caching is also important from a security perspective, when and how to handle the cache in a way that is intelligent but doesn't leak secrets is hard in Jenkins. The user is responsible for building all the logic. But in Codefresh it's handled automatically using best practice's so users don't have to worry about it.

3) Having CI and CD in the same platform is enormously beneficial

The problem of provenance is constant in DevOps. How do you tell that a deployment artifact is really what it says it is? How do you know where it came from? What if you want to know who worked on it?

Because Jenkins is a CI tool, it's really only designed to build. Sure, some users have scripted their way to continuous delivery glory but even with plugins Jenkins isn't aware of deployment environments in the same way Codefresh is.

Codefresh actually connects to deployment environments and shows what's currently running as well as where it came from, how it was built, who worked on it, and what code changed. Codefresh is a true CD platform with built in deployment steps, advanced deployment strategies like canary and blue/green, as well as full traceability, audit log, and approval flow going all the way back to code changes in Git.

That means developers spend less time trying to track down changes and answer questions about production and more time writing code.

Bottom line, Jenkins has long been DevOps duct tape. Forward thinking teams are moving to Codefresh because it saves them time and makes them more efficient.

Erik Osterman, a bit of a DevOps celebrity well known for contributions to Terraform, uses Codefresh exclusively. His company focuses on release engineering for cloud-native applications.

"Codefresh is really designed for the modern software delivery process.  It has excellent integrations into all the deployment environments we use, such s Kubernetes.  We used Jenkins in the past because it was flexible, but we can do everything we did with Jenkins plus a lot more with Codefresh."

With Jenkins even facing an uncertain future with its sponsoring company giving away the maintenance of the aging tool to a foundation, it's no wonder so many companies are migrating away to Codefresh.

##

About the Author

Dan Garfield is a full-stack engineer, kubernaut, and has long running experience with Istio and Helm. He's contributed to a number of open source projects. As a Google Developer Expert, and ex-Atlassian, he's travelled the globe teaching and guiding teams adopting Kubernetes. Ask him about his raspberry-pi powered chicken coop.