5 ms·
Jenkins is endlessly flexible, but at the end of the day its complexity adds such an upfront cost that less flexible tools win outright when the metric you care
by orf 5y ago
Jenkins is endlessly flexible, but at the end of the day its complexity adds such an upfront cost that less flexible tools win outright when the metric you care about is the “ability to get shit done without giving a fuck about groovy sandboxing”.
A system like Gitlab-CI is less flexible than Jenkins but because it makes 99% of the use cases you have for a CI system take 99% less effort it wins hands down.
Combine it with a Kubernetes-based executor and you have a scalable, isolated, reproducible and flexible CI system that requires basically no maintenance and most importantly is about as approachable and understandable as you can possibly get for a CI system. It’s simple shell commands vs AbstractProxyCSPFactoryGroovyBean classes.
- bob1029 5y agoAfter a while it got easier for us to write our own code to automate things than to try and piece together a wordpress-like component system. We still have Jenkins running somewhere, but I can't remember the last time I needed to run a job on it.
- jameshart 5y agoIf you haven't looked in a while, it's probably not running, or if it is, it's seven incompatible plugin upgrades away from actually working.
- oblio 5y agoThe thing is, Gitlab & co. almost all mandate Docker. You don't use Docker, the list of options narrows down dramatically. You need to support non-Linux OSes, same thing. If your needs are limited, yeah, something other than Jenkins is better. If they're not... I don't think there's a better alternative to Jenkins.
- orf 5y agoGitlab CI doesn’t mandate anything - you can run it on a “bare metal” server. However if you use a kubernetes executor it mandates that your builds run inside a container image, which is fantastic for reproducibility and visibility. Everything is versioned and can be customised at the repository or branch level with very little effort. Of course this limits some more esoteric builds that might need dedicated hardware or for whatever reason cannot run inside a container, but you can mix executor types if you so please.
- oblio 5y agoDo they support Windows Docker containers?
- orf 5y agoYes: https://lmgtfy.app/?q=gitlab+ci+windows+docker https://lmgtfy.app/?q=gitlab+ci+windows+docker
- sytse 5y agoYes, GitLab CI supports Windows Docker containers, see https://docs.gitlab.com/runner/executors/docker.html#using-windows-containers https://docs.gitlab.com/runner/executors/docker.html#using-w...
- ArchOversight 5y agoGitlab CI does not mandate docker. The gitlab CI agent will happily execute directly on the host without starting docker containers.
- scrozart 5y agoGitlab doesn't mandate anything. Also, even if your CI pipeline does use Docker, it doesn't matter if "you don't use Docker" _as a team_. Your pipeline may name an image, and that's it. That's way different than maintaining your own Dockerfiles and images.
- fnord77 5y agowe've had great luck with gitlab-ci. Jenkins is just a nightmare.
- 2rsf 5y agoI see why Jenkins is complex, but a nightmare? I use and manage a rather complex setup and hardly ever had problems related to Jenkins itself. I do advice to limit users access to the internals of the framework (not the jobs but rather the core or plugin installations) and leave that the a small number of people
- noisy_boy 5y ago> Combine it with a Kubernetes-based executor and you have a scalable, isolated, reproducible and flexible CI system that requires basically no maintenance and most importantly is about as approachable and understandable as you can possibly get for a CI system You can also setup a docker image with all the Jenkins related bits installed (including any custom/specific setup) and then that can be integrated with whatever Kubernetes or Docker setup you need. Jenkins also has concept of slave executors and they can be deployed to any build nodes (fixed or on-demand). > It’s simple shell commands vs AbstractProxyCSPFactoryGroovyBean classes. No idea what this is about - you don't need to write Java or Groovy classes to run Jenkins jobs. One of the most common use of Jenkins is to run steps via scripts (Shell/Python/Perl/whatever). Sure the UI looks a bit dated but from what I have seen, it hardly needs much maintenance either.