Continuous integration and DevOps are no longer about chasing efficiencies, but have matured into a true force multiplier for your team.
With all the changes in the industry and the rise of several new entrants, it is a great time to survey the landscape to re-evaluate if you should make a change. I wanted to share some of our findings in this first part of a two-part blog series. The second part will cover why we decided to migrate over to a new partner.
Jenkins: What's wrong with it?
We've used Jenkins at Quantum Mob since our founding. I even shared a way to use it in a Docker container. Jenkins is an old, trusty workhorse that slogs through tedious builds for you. It's been around since 2011, and you can tell just by looking at it.
Their pipeline / Jenkinsfile really took it up a notch and Jenkins is "free" too, which is always nice. Unfortunately, after using Jenkins for multiple years the issues with it just add up. Here’s a few that I’ve noticed:
- Due to security patches, it should be updated pretty frequently, but reinstalling Jenkins is non-trivial and can introduce errors on pipelines.
- Why are there so many plugins!? We literally have hundreds installed that we haven't heard of. And you'd have to update them daily to avoid those security vulnerability warnings.
- The UI is skinning a Swiss Army knife. Jenkins has so many features and possible use-cases there are just too many fields everywhere and most of them I neither want nor need to see.
- If you're using it to any scale, you immediately start noticing it hogging hard drive space. This could be dependencies being downloaded to workspaces or just orphaned docker images piling up. Either way, this is just another thing to manage.
- Mobile builds are more complex than most. You're going to probably need a couple secondary nodes (at least one with macOS and another with Android Studio installed). This means more hardware and more to manage.
CircleCI has also been around since 2011 and is well trusted by enterprise clients. It solves a lot of the headaches induced with Jenkins. It's cloud hosted, reliable and outsources the maintenance activities to them. Here are a few thoughts I have on Circle:
- They've added Mac nodes for mobile builds and even GPU for ML, which is a big plus for some people.
- Their YAML file works similarly to a Jenkinsfile. The idea of keeping a repeatable definition of your CI in source code is good. The bad side is there is a steep learning curve to know how to make these YAML files.
- While not everyone's top priority, Circle can become costly at a certain scale. Playing around with their cost calculator, for Quantum to move everyone over to this would cost around US$6,100 per year. Is that worth the time savings over nothing? Absolutely! Is it worth it over the time saved on Jenkins? It very well could be, but that's a calculation you have to consider with your situation.
While there are benefits to CircleCI, we didn't end up migrating over to them due to other discoveries I'll cover below.
GitHub Actions is relatively new on the scene with definite buzz behind it. The idea of having your source control bundled with a full-fledged CI system is appealing. Combined with their package management, you can start to see an offering where code goes in and packages are built and served.
Unfortunately for Actions, getting your builds deployed to something like AWS is a painful process. Their marketplace app for deploying to AWS requires a seriously overkill and complex setup for what we need.
Right now, I think actions are great for triggering other things but their marketplace will only keep growing and getting better. There is potential here and worth keeping an eye on this to see where it goes.
Buddy is something I came across recently and I was surprised that I'd never heard of it. They've taken a unique approach to tackling some of the built-in issues with CI/CD.
Buddy is cloud hosted like Circle, so most of those Jenkins issues melt away. But unlike Circle, they offer both YAML and an interface to create your pipelines. The addition of an interface to create the pipeline is incredibly useful. You no longer need to dig through extensive docs and examples to get a multistep pipeline integrating with other services and deploying to your cloud environment. You can always export it over to YAML too if you want to check in into source code.
Another feature that is a big win over Jenkins, it's one click to change which branch is deploying. If you want to test your feature branch in dev, go ahead.
I like their API, too. I've been able to provision pipelines through our own tooling, which can be quite handy.
At this point, I wanted to go with them as they're also reasonably priced than CircleCI, so it was an easy decision to make the switch to Buddy.
The future is bright for CI/CD as it continues to blend into the background and amplify effort. There are now options out there that save you and your team time. Don't keep fighting your tools, find one that fights for you. Let me know if you have any questions around tooling.
In Part II of this series, I will dive into more details about how to get up and running with Buddy. Hopefully you will find them useful when making a decision for your organization.