6 ms·

I'm curious for the people that use GitLab CI/CD, what's the pro / cons vs Jenkins and the like?

by Thaxll 9y ago

diggan 9y ago
A short while ago (eh, just noticed this was over a year ago...) I did a comparison between different testing solutions for all projects within the IPFS organization. Remember this was a year ago, so many things have changed but we ended up going with Jenkins and I'm now migrating projects from free usage of Travis/CircleCI to Jenkins. - Brief explanation: https://github.com/ipfs/infrastructure/issues/100#issuecomment-265439892 https://github.com/ipfs/infrastructure/issues/100#issuecomme... - Spreadsheet comparing features: https://docs.google.com/spreadsheets/d/11kTloM6d1CGu_ycmP3XzpteGpJtij-h6q07anM5ZuGs/edit#gid=0 https://docs.google.com/spreadsheets/d/11kTloM6d1CGu_ycmP3Xz... Check out those links and you should get a good overview
- boleary-gl 9y ago
  "Haven't really found any good way of integrating the Gitlab-CI with Github" Sounds like that is solved.
- smulc 9y ago
  Nice summary. Did you test support for handling multiple changes to a single project in parallel? The only CI Platform I've found that tries to handle this in any meaningful way is OpenStack Zuul (https://zuul-ci.org/ https://zuul-ci.org/) and https://docs.openstack.org/infra/zuul/user/gating.html#testing-in-parallel https://docs.openstack.org/infra/zuul/user/gating.html#testi... for details of the parallel support. Do others have this need? Or are people generally focusing on keeping CI runs short and landing changes in a serial fashion?
  - diggan 9y ago
    No, this was not a consideration, as we often have so many PRs open at one time, that this is probably not feasible. If I understand the process correctly, it would merge each PR in order from the first made until the most recent one. So the most recent one includes all the proposed changes. For ipfs/go-ipfs, that would involve doing 104 tests + builds for each PR. Rather, we test each branch as it was merged into master (in isolation), and when master changes, trigger builds for PRs that now are changed. The "Cross Project Testing" and "Cross-Project Dependencies" is something we're deeply in need of though, and already do somewhat. The dependencies are implicit now though (via npm or our golang package manager, gx) rather than explicit. If anyone have ideas for "cross project testing with dependencies" on Jenkins, I would be very happy to hear them.
- kkapelon 9y ago
  Very Nice! I did something similar but only for hosted solutions http://blog.codepipes.com/hosted-ci-comparison/hosted-ci-comparison.html http://blog.codepipes.com/hosted-ci-comparison/hosted-ci-com... I am preparing another blog post for on-premise (GoCD, Jenkins, Concourse etc.)
amenod 9y ago
We used both at previous and current job. As far as I'm concerned there's no reason to stick to Jenkins unless you really can't afford time to migrate. And even then you probably should. Main differences: - GL is waaaay easier to setup and maintain, both initially (installation, configuration and upgrades) and especially when configuring runners and per-project tasks - GL saves information about tasks in a file which is part of repo. This might seem counter-intuitive at first, but it makes sense when you realise that build process depends on version (if you want to be able to build old versions of your products). Also, this way config is part of source repo so backup is easier. - Jenkins can do anything - with a proper plugin. Hunting for the right plugins however is a neverending story. God forbid you ever have to reinstall Jenkins... Of course that's just my experience. Until GitLab came along we have used Jenkins for a few years and... well, it worked. But it's UX is not comparable to GitLab's.
Macha 9y ago
So I use Gitlab CI on my personal projects, and in work I was "the Jenkins guy" on our team for a good while, though I've since changed projects to one using an internal tool so my Jenkins knowledge is ~1yr outdated. Gitlab CI: ========== + No infrastructure required. I like to work on my private projects and not their servers. + Mostly-declarative syntax with a easy way out when required. Jenkins until recently only had imperative options (scripts in a UI/scripts in classic Pipeline) + Caching between builds is inbuilt, while in the past we had to roll our own with Jenkins - No easy way to share the same script between repos without copy/pasting your .gitlab-ci.yml. Jenkins: ======== + More options to display output. Need to have your tests list which ones passed and which failed? Done. + Credential Management is better, at least at the "early adopter" free tier I'm on for Gitlab. - The Legacy/Default UI is bad. The Blue Ocean UI is a bad UI in a winamp skin. - Integrating plugins designed with pre-workflow jenkins in mind to Jenkins Pipeline is a bit awkward, often requiring you to know which class is used internally in the plugin.
- sytse 9y ago
  Thanks for reviewing GitLab. We introduced a way to share scripts in the last version as a paid feature https://about.gitlab.com/2018/02/22/gitlab-10-5-released/#include-external-files-in-cicd-pipeline-definition https://about.gitlab.com/2018/02/22/gitlab-10-5-released/#in...

I'm curious for the people that use GitLab CI/CD, what's the pro / cons vs Jenkins and the like?

by Thaxll 9y ago

I'm curious for the people that use GitLab CI/CD, what's the pro / cons vs Jenkins and the like?

A short while ago (eh, just noticed this was over a year ago...) I did a comparison between different testing solutions for all projects within the IPFS organization. Remember this was a year ago, so many things have changed but we ended up going with Jenkins and I'm now migrating projects from free usage of Travis/CircleCI to Jenkins. - Brief explanation: https://github.com/ipfs/infrastructure/issues/100#issuecomment-265439892 https://github.com/ipfs/infrastructure/issues/100#issuecomme... - Spreadsheet comparing features: https://docs.google.com/spreadsheets/d/11kTloM6d1CGu_ycmP3XzpteGpJtij-h6q07anM5ZuGs/edit#gid=0 https://docs.google.com/spreadsheets/d/11kTloM6d1CGu_ycmP3Xz... Check out those links and you should get a good overview

boleary-gl 9y ago
"Haven't really found any good way of integrating the Gitlab-CI with Github" Sounds like that is solved.
smulc 9y ago
Nice summary. Did you test support for handling multiple changes to a single project in parallel? The only CI Platform I've found that tries to handle this in any meaningful way is OpenStack Zuul (https://zuul-ci.org/ https://zuul-ci.org/) and https://docs.openstack.org/infra/zuul/user/gating.html#testing-in-parallel https://docs.openstack.org/infra/zuul/user/gating.html#testi... for details of the parallel support. Do others have this need? Or are people generally focusing on keeping CI runs short and landing changes in a serial fashion?
- diggan 9y ago
  No, this was not a consideration, as we often have so many PRs open at one time, that this is probably not feasible. If I understand the process correctly, it would merge each PR in order from the first made until the most recent one. So the most recent one includes all the proposed changes. For ipfs/go-ipfs, that would involve doing 104 tests + builds for each PR. Rather, we test each branch as it was merged into master (in isolation), and when master changes, trigger builds for PRs that now are changed. The "Cross Project Testing" and "Cross-Project Dependencies" is something we're deeply in need of though, and already do somewhat. The dependencies are implicit now though (via npm or our golang package manager, gx) rather than explicit. If anyone have ideas for "cross project testing with dependencies" on Jenkins, I would be very happy to hear them.
kkapelon 9y ago
Very Nice! I did something similar but only for hosted solutions http://blog.codepipes.com/hosted-ci-comparison/hosted-ci-comparison.html http://blog.codepipes.com/hosted-ci-comparison/hosted-ci-com... I am preparing another blog post for on-premise (GoCD, Jenkins, Concourse etc.)

amenod 9y ago

We used both at previous and current job. As far as I'm concerned there's no reason to stick to Jenkins unless you really can't afford time to migrate. And even then you probably should. Main differences: - GL is waaaay easier to setup and maintain, both initially (installation, configuration and upgrades) and especially when configuring runners and per-project tasks - GL saves information about tasks in a file which is part of repo. This might seem counter-intuitive at first, but it makes sense when you realise that build process depends on version (if you want to be able to build old versions of your products). Also, this way config is part of source repo so backup is easier. - Jenkins can do anything - with a proper plugin. Hunting for the right plugins however is a neverending story. God forbid you ever have to reinstall Jenkins... Of course that's just my experience. Until GitLab came along we have used Jenkins for a few years and... well, it worked. But it's UX is not comparable to GitLab's.

Macha 9y ago

So I use Gitlab CI on my personal projects, and in work I was "the Jenkins guy" on our team for a good while, though I've since changed projects to one using an internal tool so my Jenkins knowledge is ~1yr outdated. Gitlab CI: ========== + No infrastructure required. I like to work on my private projects and not their servers. + Mostly-declarative syntax with a easy way out when required. Jenkins until recently only had imperative options (scripts in a UI/scripts in classic Pipeline) + Caching between builds is inbuilt, while in the past we had to roll our own with Jenkins - No easy way to share the same script between repos without copy/pasting your .gitlab-ci.yml. Jenkins: ======== + More options to display output. Need to have your tests list which ones passed and which failed? Done. + Credential Management is better, at least at the "early adopter" free tier I'm on for Gitlab. - The Legacy/Default UI is bad. The Blue Ocean UI is a bad UI in a winamp skin. - Integrating plugins designed with pre-workflow jenkins in mind to Jenkins Pipeline is a bit awkward, often requiring you to know which class is used internally in the plugin.

sytse 9y ago
Thanks for reviewing GitLab. We introduced a way to share scripts in the last version as a paid feature https://about.gitlab.com/2018/02/22/gitlab-10-5-released/#include-external-files-in-cicd-pipeline-definition https://about.gitlab.com/2018/02/22/gitlab-10-5-released/#in...