8 ms·
This is why we left Gitlab. DevOps become center part of Gitlab which we don’t use and need any of those feature. We all need a code storage, code review, issu
by sercand 4y ago
This is why we left Gitlab.
DevOps become center part of Gitlab which we don’t use and need any of those feature. We all need a code storage, code review, issue tracking and the CI/CD. We would pay advance features of those (epics, multiple assignee, etc) but we have to pay super expensive top tier which includes unnecessary DevOps stuff. We left and happy so far.
We are using Kubernetes and custom DevOps tools but don’t want to handle things the way that Gitlab does.
- i_like_waiting 4y agoWhere did you go instead?
- 100011_100001 4y agoThis is happening everywhere. The current industry cycle is one of scope expansion, moving away from the do one thing well paradigm. This will lead to bloated software that do a little bit of everything but not very well, which will trigger the next industry cycle, of doing one thing well paradigm.
- andrei 4y agoI've heard this talked about before, and I believe there's a phrase for it, but I don't remember. Do you happen to know?
- teknofobi 4y agoBundling and Unbundling https://stratechery.com/outline/bundling-and-unbundling https://stratechery.com/outline/bundling-and-unbundling
- pojzon 4y agoIve started working with Gitlab in last few months for new contract and this was exactly what hit me hard. Gitlab has too many half-baked features. Ive hit those issues at least a dosen times. From the top of my head: - Environment variables dont work with triggers - MS Teams integration does not support multiple channels - Masking doesnt work for all variables - Code AutoDeploy quite often just breaks for no reason.. - Kubernetes integration is super poor I would prefer to have fewer fearures that actually work well and have good support instead of bunch of stuff you have to sometimes wait years for to be fixed (looking at their issue tracker).
- kjohnstonGTLB 4y agoGitLab Product Leader here - we do focus on MVCs and have built a lot of breadth in our product, that's something we are proud of. I do think we do a good job of pivoting and removing features where appropriate. For example we started with a not-secure-enough mechanism for attaching Kubernetes clusters and shifted to the more secure GitLab Agent for Kubernetes[1], deprecating the certificate method. We also started with a "must install Prometheus and Elk on your cluster" Observability solution and are now (after our acquisition of Opstrace) working to make observability on-by-default[2]. [1] https://docs.gitlab.com/ee/user/clusters/agent/ https://docs.gitlab.com/ee/user/clusters/agent/ [2] https://about.gitlab.com/direction/monitor/observability/#principles https://about.gitlab.com/direction/monitor/observability/#pr...
- rrauenza 4y agoHere’s another one of those maddening issues: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3376 https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3376 I’ve had to write a wrapper script around each command that polls the cicd job Id and kills its subprocesses properly if the job is cancelled.
- deastman 4y agoHello - I am the product manager for GitLab Runner. The SIGTERM-related issues have been quite complex due to the different execution environments in which the Runner can operate. Can you add the details of your use case and workaround to the issue below? We need to take another look at this functionality, given the various reports of inconsistent behavior with long-running processes. https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27443 https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27443
- rrauenza 4y agoCentOS7. I've also asked the SCM team at my employer to get us added as a paying customer who would like this looked at, to help prioritize. I don't know if you just need to do process groups or walk the subprocess tree or what... but generally, this is a solved problem on Linux for things that manage subprocesses... assuming the processes don't manually do something silly like daemonizing themselves. (That's not my use case.) Linux should be the easiest case. edit: What is most frustrating is this issue appears to have been opened ~4 years ago.
- systemvoltage 4y agoWhat's the distinction between DevOps and CI/CD? I thought CI/CD is DevOps.
- deleted 4y ago[deleted]
- abdusco 4y agoCI/CD is part of Devops. It also includes monitoring systems, keeping them up, maintenance, upgrades necessary to keep the software working.
- itslennysfault 4y agoDevOps is a methodology.
- systemvoltage 4y agoWell, I was trying to clarify this statement from OP: > DevOps become center part of Gitlab which we don’t use and need any of those feature. We all need a code storage, code review, issue tracking and the CI/CD. It reads to me like this: "We don't use DevOps features in Gitlab, but we use CI/CD pipelines in Gitlab". So it is contradicting. As they responded, CI/CD is a subset of DevOps methodology. I've used Gitlab and didn't know there were more DevOps tools other than their CI/CD features and runners. I am still slightly confused.
- sercand 4y agoDevOps is whole set of tools. Gitlab includes features like monitoring, code scanning, Kubernetes integration, docker registry, cloud security and protections. And those are $1188 per year per person. By CI/CD I mean good old Jenkins that runs on a computer in the office that builds iOS Apps and uploads them to Apple AppStore (of course current generation of CI/CD is much better). Gitlab CI/CD and runners were there much before this "Gitlab is the one DevOps platform" saga. Everyone in our company including HR, marketing, design people were also using Gitlab for task tracking. Therefore we need those fancy issue tracking features for better management. This features are in the tier that $1188/year per person. For the features we don't use is not something that we could afford.
- mountainriver 4y agoYeah this is a really bad direction for gitlab. All of their devops features are terrible. They don’t pay their engineers which is why everything is poorly built. They should have just focused on being the best vcs. Oh and you get what you pay for. Want to hire a bunch of mediocre engineers? you’ll get a bunch of half baked features
- andrewstuart2 4y agoI'm honestly of the opposite opinion. I have used GitLab for 10 years now and have yet to find something as useful as GitLab's CI/CD, and I've tried (not always by choice) a ton of different options. Mainly it's because I strongly prefer to orient most of my flow around Kubernetes deployments and namespaces tied to git metadata like commit sha or branch name, and thus far, I haven't found a better more interested way of doing so than GitLab.
- deleted 4y ago[deleted]
- thinkpad13 4y agoI agree with this so what you guys use for the issue, epics, burndownchart and such?
- okamiueru 4y agoIs it really "center part"? I'll admit there is some unnecessary clutter here and there, but it's easy enough to ignore. What I don't understand is who these features are for, and who uses them. We use the CI/CD parts, but other than that manage everything through k8s, and I wouldn't dare let GitLab a handle it. And, the whole "one click devops", or what it was called, is even more puzzling.
- robinshen 4y agoThis is exactly what I am doing for OneDev: https://github.com/theonedev/onedev https://github.com/theonedev/onedev