This is more of a question for edX engineers. I know you guys are using GoCD internally for deploying part of the edx.org infrastructure. I am currently shopping for a lightweight CI/CD solution and GoCD has appeared in my radar, along with Concourse. I was wondering if you had benchmarked both tools, and what were the reasons for picking GoCD?
At the time GoCD was picked, Concourse was new enough that I’m not sure it was even noticed as an option (and wouldn’t have been considered mature enough even if it was noticed). Jenkins was already in use for CI, but its support for pipelines was very immature at the time (and stayed that way for another year or two) so it wasn’t considered suitable as our CD solution.
Needing to manage both Jenkins and GoCD is less than ideal, so we periodically revisit this decision. Now that Jenkins pipelines have matured and we’re experimenting with Kubernetes in production, Jenkins and Gitlab CI are both candidates for replacing GoCD at some point in the future. Concourse has some nice aspects to it, but 33% of commits are from a single developer and last I looked it still lacked some significant features compared to the competition that were taking a while to fill in. It certainly isn’t ruled out from consideration when we do seriously look at moving off of GoCD, though.
2 Likes
Thanks for the explanations @jmbowman! In my experience, Gitlab CI is not suitable for lightweight CI/CD, but otherwise it’s been a great tool that just blows the competition out of the water.
@regis so, I’ve tried GoCD, Jenkins, GitlabCI in the past. I had a feeling while using GoCD that it’s built more for Java based applications. It might just be me, but I never liked it to be honest.
Jenkins on the other hands is really powerful, but unless you’ve got an engineer doing all the devops stuff, I think you’ll spend more time managing the Jenkins instance itself and that outweighs the usefulness.
GitlabCI was really powerful and simple. Except of the usual outages, where no runners are available to do your thing. You can have a docker based ECS container launched with your env pre-configured and it’s just plain and simple and once it’s configured, I don’t think we ever spent time on it managing it. It’s just that when you’re doing parallel builds, the outages aren’t uncommon and it doesn’t have an elastic agent-runner config the last time I checked.
Now, here’s something new - Github Actions - really powerful, automated, SaaS based CI/CD, dedicated runners with elastic configuration (launch as many runners you like) integrates within your GitHub source code, They charge for it, but I think you get some large number of hours free and unless you’re doing massive large scale deployment, that’ll suffice. Believe me or not, Microsoft and GitHub investing so much on this, it’s going to be massive in the future.
There’s one more. If you’re looking for something purpose built for K8s and Docker - I’d close my eyes and go with Codefresh. I don’t know if the pricing will suit you or not, but they’ve spent years coming up with CI/CD as SaaS which is purpose built for K8s and containers and they’ve already overcome some of the challenges you face. And it’s got built in Helm support.
It’s been a long time since I’ve used some of them like GitlabCI so, things might have changed. But, I think if you’re tight on resources go with something simple like Github Actions or Codefresh - if you want something for containerised apps. That being said, i really liked Gitlab CI when we were using it. It’s really simple and lightweight and like some of the good ones, the pipelines can be configured as code.
1 Like