A Quick CI/CD Space Overview
This space is congested. First of all, the most famous one of all is perhaps Jenkins. Who haven’t heard of Jenkins right?
Jenkins was born out of a fork of the old Hudson. Remember that?
Then we’ve got a bunch of new CI/CD tools that is mainly online & serverless or more appropriately a SAAS (Software As A Service) meaning you don’t require to run or manage your own CI/CD build servers infrastructure unlike Jenkins/Hudson etc. For example, there are Travis CI, CircleCI, Semaphore.
In terms of more commercial CI/CD products there have been Atlassian’s own Bamboo CI product.
Within the Microsoft space there is TFS (Team Foundation Server). I personally haven’t used it so don’t know how good it is.
There’s also JetBrain’s Team City. Again, i’ve never used it practically, but have seen many screenshots of how sleek it looks and heard many good reviews from developers who uses Team City within their companies/projects.
Look no further than GitLab’s own integrated CI system.
There’s also the niche market where a particular tools focuses on. For example, GoCD gives primary focus to the ‘CD’ concept.
Finally, then there comes GitHub’s own CI/CD solution. It was only a matter of time before GitHub rollout something within this space.
Enter GitHub Actions!
Why am i comparing specifically GitHub Actions against Jenkins then?
It turns out that there has been a lot of hype and talk around GitHub Actions will eventually kill off Jenkins.
In this post i am going to offer my own comparison of the two since i happen to use or have used both of them a lot in the past few years.
What this is not?
This is not a complete in-depth feature by feature comparison of why one is better than the other.
Such comparisons have been many times and are all over the internet. I mainly aim to offer my own perspective on it.
Overhead of managing Jenkins Cluster
Jenkins doesn’t offer a cloud service at the moment so to use Jenkins you have to run Jenkins yourself somewhere. This can either be directly as a Java artifact (
war or a
jar ) where we spin up an embedded Jetty container. Or you install the Jenkins binaries directly on a server. Or you can even run it as a Docker container but then you still have to manage the Docker container yourself.
Typically, it is very rare you would have a single instance Jenkins. Instead, you would have a Jenkins cluster where you would have one (sometimes more) Jenkins master that acts as the ‘controller’ and a set of ‘build agents’ that does the actual CI jobs building. This setup is especially common in large enterprises where there is a huge demand for CI workload (when you have large amount of projects & developers).
Like any other software system, managing a cluster in the form of a distributed system is very difficult and there is a lot of overhead that occur. You would need to think a lot about the performance of your Jenkins cluster like how much memory or disk space it is using. Do you have enough?
You also need to regularly backup your Jenkins cluster (in particular the Jenkins master) to save the configurations of Jenkins so that in the event of failure (failures can occur!) you can easily recover your Jenkins setup. Doing Jenkins backup is definitely not an easy job. In terms of Sys Admin this is definitely tedious. It will likely involve downtime impact to the usage of Jenkins. This definitely breaks Highly Available (HA) principles.
None of this for GitHub Actions
With GitHub Actions, since it is a cloud service, you don’t require to think about all these things. This might mean you don’t need any Sys Admins/Jenkins Administrators to manage your CI/CD system. Since it is a cloud service it can be easily self-managed by any other people (even developers themselves).
What about Developing Pipelines?
DevOps CI/CD Pipelines are everything these days. So how do we construct these ‘pipelines’ with these tools?
In Jenkins, they have this strong concept of a ‘pipeline’ where it allows you to construct a full CI/CD pipeline (in code too).
For example; using Jenkins Declarative Syntax to build a full SDLC pipeline:
On the other hand, GitHub Actions have the concept of ‘Workflows’.
Very similar but yet very different.
GitHub Actions workflows works off by giving you the ability to code individual actions or workflows in response to certain events that occur around the usage of GitHub.
Even though, it doesn’t have the strong concept of Jenkins pipelines in building ‘pipelines’ you can still easily construct a GitHub Actions workflow to model a full SDLC pipeline.
As an example, the below GitHub Actions workflow is the equivalent to the Jenkins Pipeline above.
However, the GitHub Actions idiomatic way is to use workflows as separate individual ‘workflows’ that each represent a single unit of work normally.
For example, when you submit a PR you can configure many ‘workflows’ to run on the event of when you opening a PR on GitHub. The workflows works off for numerous GitHub events where events can be opening/closing an issue, opening/closing a PR, plus many more.
As an example above, you easily see the workflows that gets run on the event of opening a new PR and you can also easily visualize each of your workflow’s progress:
GitHub Actions Usability Still an Infant
One of the key features of Jenkins with its pipelines features is its Stage View. This is where i feel Jenkins in particular is the dominant winner.
For instance, look at the below Jenkins Pipeline Stage View and you can clearly see & visualize how your SDLC pipeline is ‘flowing’.
It is certainly an area where Jenkins excel over GitHub Actions (for the time being at least). So from a usability point of view, it definite provides users a better experience.
GitHub Actions is quickly evolving this space too.
How does each interact with external systems?
As a CI/CD tool, it is very paramount that it can easily interact with external systems such as Task/Issue/Bugs tracking systems (like JIRA), Static Code Analysis tools (like SonarQube), Artifact Repositories (Containers Registries such as Docker Hub, Cloud Providers Container Registries etc, Nexus, Artifactory), and many more.
After all, the purpose of a CI/CD tool nowadays is to be easily ‘orchestrate’ a full Software Development Lifecycle (SDLC) ‘pipeline’.
Jenkins not just an CI server
In the past, Jenkins was viewed as just a CI (Continuous Integration) server since it was born out of a fork of the old Hudson project. However, the vast plugin library of Jenkins soon turn Jenkins into a multi-purpose “Automation Server’ where it can automate any IT related task in the form of ‘Jenkins Jobs’.
At present time, Jenkins as a full blown Automation Tool can automate any kind of SDLC pipeline from start to finish. Whatever you need (for example, whatever external systems you require to interact to), you can be rest assured that there would likely be a ready made available Jenkins plugin to help you do the job.
…but GitHub Actions Marketplace is too good to ignore
Just like how Jenkins plugins extend core Jenkins functionality, external custom built GitHub Actions help extend your own GitHub Actions workflows. These external third party custom built GitHub Actions are made available via GitHub’s Marketplace.
This marketplace is very good in my opinion such that it gives users an easy place to search for external already made GitHub Actions. Their documentation is not too bad either.
Integrated CI/CD VCS Solution might be a bad idea!
GitHub Actions is not the first integrated CI/CD solution with a VCS. It is certainly won’t be the last either. GitLab already was one of the first to offer a fully integrated VCS with CI/CD tools built in.
Why i believe an integrated solution is a bad idea compared to separate CI/CD tools from VCS is that if one of either your CI/CD service or your VCS goes down then you are pretty much … screwed.
For example, if GitHub Actions fails or you are unable to access GitHub as a whole then you have no access to your CI/CD jobs as well as your source code. This could happen though, albeit very rare since most softwares are built with a micro-service model in mind meaning that failure in one part would unlikely affect other parts. GitHub is certainly like this. Recently, i have witnessed that even the GitHub Actions service was down, i was still able to access my code base on GitHub VCS. Sure thing! But it is not a guarantee.
But i prefer to have a situation where by if my Jenkins server was down, i would still definitely have access to my source code on GitHub for example and vice-versa. That is, if GitHub was down, then i would still likely to be able to go onto Jenkins and still view my build jobs. What use would that be you might wonder? Well… i might just want to view the build logs of a particular build. For sure, both systems could fail then… yes… you are out of luck then.
All in all, i prefer to have that clear separation of purpose in terms of tooling. I truly acknowledge that going forward there would be many similar multi purpose tools that exist.
My Final Thoughts
I still love Jenkins today but i must admit that GitHub Actions is starting to take shape! Personally, i still think it has a long way to catch Jenkins up in terms of pure overall functionality but it is certainly getting there.
Whether it will completely destroy Jenkins or not one day, i really don’t know and can’t predict. Maybe it will, or maybe it won’t. Who knows? Only time will tell!
So what would i choose now then?
As a developer who is someone only wants to easily run and see their builds, i would choose Jenkins any day. I just love their Pipelines Stage View. Overall, from a usability point of view it is second to none.
However, as an engineer who needs to administer and maintain a CI/CD tool or need to quickly setup a half decent easily usable CI/CD tool for a new project then i definitely would not hesitate to give GitHub Actions a try instead.
As people say:
“Choose the right tool for the right job”
I would also add:
“Choose the right tool for the right job … for the right situation”