We have explored GitLab in the past and a lot of our CI/CD is heavily inspired from GitLab.
They seem to be consistently taking right decisions at the micro level. Their CI/CD design and execution is way more usable and reliable than <name suppressed> pipelines (still no manual stages, still no re-triggering, etc). Their design and integration with Kubernetes is also a great choice.
So on the micro picture, things are quite good. On the macro picture, they are building a universe. On the Issues front, they're trying to be like Trello (and in some places, reminds of Jira). They're trying to tie Issues with customer support, getting slightly in the way of Zendesk/Freshdesk. They're building deployment. Then monitoring - they support Prometheus. Now post-deployment/post-monitoring. And of course, they are competing on core git hosting as well.
Of course, they'll do a great job. Heck, if they get into the messenger domain, they'll pick a nice strategy and just integrate deeply with Slack maybe.
But the core of the problem is: None of these are instrumentable/hookable. Want to enforce some of your own organization policies before deployment? Want to use everything _except_ with your own monitoring tool? Sorry. If you use GitLab, you use their universe and everything that comes with it. There is no graceful integration with a broader set of tools.
Maybe for a small startup, just "doing things the GitLab way" and subscribing to all their micro choices (which are good) make sense. But organizations grow, and they'll outgrow these micro choices sooner than later. Then the lack of extensibility, hooks, etc. will bubble up.
All this is assuming GitLab continues to build out a perfect application platform with all the right choices (and all the version and time matrices of those choices). Hugely laudable work so far though!
> None of these are instrumentable/hookable. Want to enforce some of your own organization policies before deployment? Want to use everything _except_ with your own monitoring tool? Sorry. If you use GitLab, you use their universe and everything that comes with it. There is no graceful integration with a broader set of tools.
Huh? Gitlab has a huge list of integrations[1] and webhooks[2]. You can use Jira for issue tracking or Jenkins for CI, for example. If something is missing, it's open source, so the plugin can be added by the community if need be. The software itself is hugely configurable for different workflows and team structures. Can you be a little more specific on what Gitlab is doing poorly here?
I think there goal is to support you when you want to use non-GitLab tools. I guess there's probably always going to be hooks missing, but they do have things like webhooks. Might want to lodge a feature request for missing hooks, as I do think they're open to them.
I like gitlab, but a mixed open source / closed source product is always going to be a challenge in terms of hearts and minds. Take this quote from the article.
> The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source.
So is all the stuff that gitlab builds on, like git, or ruby, or linux, that's all pretty advanced stuff I'd say.
> The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source.
Did they actually say that...? I only went to the page to confirm this and it appears true. Sounds like next time I choose self-hosted Github alternative, I should exclude Gitlab from my options - based on their approach so far, it feels like they really do mean this kind of contemptuous attitude of "only basic stuff should be free software".
I used to cheer for Gitlab, but this is just way over the line.
And despite what some say, I really don't think it's that great a product - they seem to be focused on getting a million of things poorly than get their core fixed. Performance is still terrible, see what happens to your browser when you view a diff for a large merge request. Also, you there's a limit to the number of commits in the history you can browse - come on, my `git log` loads the whole history in a split second but you can't render it? And they clearly don't care - I reported many issues to them that got confirmed and most of the time those were just shrugged off. As long as you're not an EE user, you won't really get much more than the annoyance of having odd version numbers make the sidebar sticky and even ones undo that.
Wow that really is a poorly worded phrase. If someone from GL is reading this, please fix that, it makes you look pretty bad.
Just be honest and say you want to charge for advanced features, because there's little money to be made in open source and you're a business after all and want to pay your employees a living wage.
Advancedness is not a criteria in open sourcing or not open sourcing. There are advanced features that are open source, such as Review Apps[0]. There are basic features that are proprietary, such as File Locking[1]. The criteria we use to decide which version the features go in are documented on our stewardship page[2].
The formulation is a bit weird. I can't find it right now, but I recall reading in the past that features that are typically only useful when an instance has 100 or more users are the ones that are not made open source. That said, they've open sourced often requested features [0].
I had a similar reaction, that quote seems extremely ignorant and tone deaf. Open source is all about shattering that mentality from Day 1; making an open source POSIX compatible OS.
Is it just me or is gitlab becoming more and more bloatware?
Is it realy a good idea to bundle everything in one application?
Why do i need an integrated artifact management with solutions like sonatype nexus?
Is it worth it to add an "awesome environment for ops" on top of kubernetes? why add this complexity?
Dont get me wrong, i like gitlab and use it since the beginning.
I just have a problem with this "munch it all together" style of products.
Gitlab in a way suffers from being open source. Their open source product is so good and includes so many features (even a full featured CI/CD pipeline!), that they need something big to justify their paid version. So I don't blame them. You can disable a lot of stuff that eats away your memory.
It's their USP; there are already less full-featured open source solutions like Gogs and Gitea. Once you start adding features like pipelines, it's hard to draw a line between what goes and what doesn't. I guess this vision is where GitLab draws it.
Maybe more like all-in-one platform instead of bloatware. AWS as a stretch for an idea? Obviously they'll need to have high execution to be able to maintain such a diverse set of features. I rather like it right now for an end-to-end solution.
Slightly offtopic from what the article focuses on, but the thing that bothers me about all these built-in CI/CD things in software like Gitlab is that people seem to be perfectly content with building an artifact and then just ... pushing it out.
In traditional deployments that may be some kind of "copy this thing over SSH and make it go!", in Kubernetes-land it's more like "lets just modify this API-state to point at the new image tag!".
Neither of those produce a consistent record of changes applied and state mutation like that is very error-prone.
We actually use Gitlab's CI at work, but we have our own deployment solutions built on it that end up making git commits into the NixOS & Kontemplate repositories which then run their own pipelines to deploy.
This way we can always answer the question "what set of applications at which versions was deployed at $time?" and also roll back consistently.
This is awesome; it's something that I've slapped together out of disparate components (that've then gradually fallen apart) so many times I've lost count. Having a tool which can manage it all -- from commit, to builds, to deploys, to monitoring -- is a massive boon for small business (and personal projects).
Now I’m pretty sure GitLab has a focus problem. It’s already very complex with somewhat unrelated things. You can’t be everything for everybody.
This will even further decrease quality of individual parts of the system. It has been unusably slow for a long time. If they try to do everything, they will have way bigger quality issues than slowness.
I'm upvoting/adding this in my favorites if only for the pipeline diagrams.
Dunno whether their vision will pan out though. I do not use gitlab so I'm probably not that qualified to speak but I wouldn't like using one PaaS for all things CICD. I'd be afraid of locking myself in plus loosing a few degrees of flexibility.
I don't get the beyond part, especially monitoring.... will Gitlab only have a Prometheus view in their UI or do they want to create their own monitoring? And when using own monitoring... this is a bit crazy... we have from day to day more and better Prometheus for that.
We are indeed leveraging open source tools like Prometheus, and not seeking to build our own. We do believe however that the data and insights that Prometheus provides can be much more impactful to an organization if it is provided in the workflow that developers already use, rather than a separate tool/UI.
For example when looking at a CI/CD deploy to an environment, you can easily access important Prometheus metrics and in the future logs, from the same console.
This also allows us to build more intelligence into the platform, as GitLab is more aware of your application and its health. One example is to incorporate Prometheus monitoring to compare the performance of a new release in an incremental deployment, and automatically pausing it if key metrics have degraded.
Is anyone here using the Gitlab CI/CD for anything a bit more complex?
I'm especially interested in a pipeline with parallel executions of different kinds of tests, maybe some manual checkpoint in there, a more complex chain with execution on different kinds of hosts or containers.
We're got some pretty complex pipelines, so much so that we've reached quite a few limitations.
You can do all the things you've listed. But you can't build an arbitrarily complex DAG of tasks. Instead, you must order everything into a sequential list of 'stages'. Within a stage you have a list of jobs, which are run in parallel. This might be enough for your needs, but I'd like flexibility to express dependencies for each and every task, Say `t1 -> ((t2,t3),t4 -> t5) -> t6`, etc.
And it's a pain to propagate variables from one task to another, like say setting an environment variable in one task, and getting its value in a downstream task. You end up writing scripts to write them to a file, telling gitlab to make that file an 'artifact', and then reading it downstream.
And then there's the transient errors, all of which are listed on open issues. We're using the hosted gitlab.com, and on some of our CI pipelines, we have a dozen or some stages. The chances of a transient error, .e.g. a runner getting a 503 from gitlab.com, are pretty high.
Last time I checked (a few weeks ago), Gitlab's CI/CD system is great for most use cases as long as you can describe your pipeline as a list of non-interactive tasks -- some of which may be parallelized -- that each can run in a Docker container.
For one of the software projects I'm involved in, I have more complex needs. We release binaries for multiple platforms so our Jenkins master delegates certain tasks to slaves running on specific OSes. Then at the end the Jenkins master downloads the built artifacts from all slaves and publishes everything to our artifact hosting server. As far as I can tell, Gitlab CI does not support this.
In future CI jobs I may even require user interaction, e.g. I may ask a human to sign off a report. I don't think Gitlab CI can do this.
But if your needs aren't so complex then Gitlab CI is great. It's UX-philosophically similar to Travis and setting it up is super simple, as opposed to Jenkins which is a pain to use.
The pipelines for Flockademic are somewhat complex, and since it's open source, you can take a look at them: [0]. It's building four interrelated Node projects at the same time, running tests, deploying the back-end projects, then building the front-end project linking it to the back-end one, then running some end-to-end tests and other checks on the deployed code. And it does that for every branch.
No manual checkpoints and different kinds of hosts or containers though.
CNCF has a pretty complex CI/CD system called cross-cloud where we're deploying half a dozen CNCF projects on half a dozen different clouds. It's using GitLab and is all open source.
Yes, it attempts to detect the language/framework, and build it. It doesn't work for all languages, and is based on Heroku buildpacks so has similar limitations. If autodetect fails, but some Heroku buildpack would work, you can specify it manually. Or, just include a Dockerfile and it'll build that instead.
[+] [-] rdsubhas|8 years ago|reply
They seem to be consistently taking right decisions at the micro level. Their CI/CD design and execution is way more usable and reliable than <name suppressed> pipelines (still no manual stages, still no re-triggering, etc). Their design and integration with Kubernetes is also a great choice.
So on the micro picture, things are quite good. On the macro picture, they are building a universe. On the Issues front, they're trying to be like Trello (and in some places, reminds of Jira). They're trying to tie Issues with customer support, getting slightly in the way of Zendesk/Freshdesk. They're building deployment. Then monitoring - they support Prometheus. Now post-deployment/post-monitoring. And of course, they are competing on core git hosting as well.
Of course, they'll do a great job. Heck, if they get into the messenger domain, they'll pick a nice strategy and just integrate deeply with Slack maybe.
But the core of the problem is: None of these are instrumentable/hookable. Want to enforce some of your own organization policies before deployment? Want to use everything _except_ with your own monitoring tool? Sorry. If you use GitLab, you use their universe and everything that comes with it. There is no graceful integration with a broader set of tools.
Maybe for a small startup, just "doing things the GitLab way" and subscribing to all their micro choices (which are good) make sense. But organizations grow, and they'll outgrow these micro choices sooner than later. Then the lack of extensibility, hooks, etc. will bubble up.
All this is assuming GitLab continues to build out a perfect application platform with all the right choices (and all the version and time matrices of those choices). Hugely laudable work so far though!
[+] [-] Kihashi|8 years ago|reply
Huh? Gitlab has a huge list of integrations[1] and webhooks[2]. You can use Jira for issue tracking or Jenkins for CI, for example. If something is missing, it's open source, so the plugin can be added by the community if need be. The software itself is hugely configurable for different workflows and team structures. Can you be a little more specific on what Gitlab is doing poorly here?
[1]: https://docs.gitlab.com/ce/user/project/integrations/project... [2]: https://docs.gitlab.com/ce/user/project/integrations/webhook...
[+] [-] iamtew|8 years ago|reply
https://about.gitlab.com/2017/03/15/gitter-acquisition/
Edit: I first said "not too long ago" then realized it was just about a year ago.. Where is time going!?
[+] [-] Vinnl|8 years ago|reply
I think there goal is to support you when you want to use non-GitLab tools. I guess there's probably always going to be hooks missing, but they do have things like webhooks. Might want to lodge a feature request for missing hooks, as I do think they're open to them.
[+] [-] yAnonymous|8 years ago|reply
Like the other guy said: If you don't like them adding exclusive extra features, pay them for what they're already offering.
[+] [-] eadz|8 years ago|reply
> The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source.
So is all the stuff that gitlab builds on, like git, or ruby, or linux, that's all pretty advanced stuff I'd say.
[+] [-] d33|8 years ago|reply
Did they actually say that...? I only went to the page to confirm this and it appears true. Sounds like next time I choose self-hosted Github alternative, I should exclude Gitlab from my options - based on their approach so far, it feels like they really do mean this kind of contemptuous attitude of "only basic stuff should be free software". I used to cheer for Gitlab, but this is just way over the line.
And despite what some say, I really don't think it's that great a product - they seem to be focused on getting a million of things poorly than get their core fixed. Performance is still terrible, see what happens to your browser when you view a diff for a large merge request. Also, you there's a limit to the number of commits in the history you can browse - come on, my `git log` loads the whole history in a split second but you can't render it? And they clearly don't care - I reported many issues to them that got confirmed and most of the time those were just shrugged off. As long as you're not an EE user, you won't really get much more than the annoyance of having odd version numbers make the sidebar sticky and even ones undo that.
[+] [-] Cthulhu_|8 years ago|reply
Just be honest and say you want to charge for advanced features, because there's little money to be made in open source and you're a business after all and want to pay your employees a living wage.
[+] [-] Snappy|8 years ago|reply
Advancedness is not a criteria in open sourcing or not open sourcing. There are advanced features that are open source, such as Review Apps[0]. There are basic features that are proprietary, such as File Locking[1]. The criteria we use to decide which version the features go in are documented on our stewardship page[2].
[0] https://about.gitlab.com/features/review-apps/ [1] https://about.gitlab.com/features/file-locking/ [2] https://about.gitlab.com/stewardship/#what-features-are-ee-o...
[+] [-] Vinnl|8 years ago|reply
[0] https://gitlab.com/gitlab-org/gitlab-ce/issues/34591#note_56...
[+] [-] ebbv|8 years ago|reply
[+] [-] cabraca|8 years ago|reply
Dont get me wrong, i like gitlab and use it since the beginning. I just have a problem with this "munch it all together" style of products.
[+] [-] foepys|8 years ago|reply
[+] [-] Vinnl|8 years ago|reply
[+] [-] dfischer|8 years ago|reply
[+] [-] tazjin|8 years ago|reply
In traditional deployments that may be some kind of "copy this thing over SSH and make it go!", in Kubernetes-land it's more like "lets just modify this API-state to point at the new image tag!".
Neither of those produce a consistent record of changes applied and state mutation like that is very error-prone.
We actually use Gitlab's CI at work, but we have our own deployment solutions built on it that end up making git commits into the NixOS & Kontemplate repositories which then run their own pipelines to deploy.
This way we can always answer the question "what set of applications at which versions was deployed at $time?" and also roll back consistently.
[+] [-] akvadrako|8 years ago|reply
What is the fundamental difference between modifying your k8s deployment to point to a new tag and your solution?
You can easily roll back (except with database migrations) and easily see what version is deployed when.
[+] [-] ianwalter|8 years ago|reply
[+] [-] frio|8 years ago|reply
I look forward to the next releases of Gitlab!
[+] [-] Walkman|8 years ago|reply
[+] [-] zerogvt|8 years ago|reply
Dunno whether their vision will pan out though. I do not use gitlab so I'm probably not that qualified to speak but I wouldn't like using one PaaS for all things CICD. I'd be afraid of locking myself in plus loosing a few degrees of flexibility.
[+] [-] therealmarv|8 years ago|reply
[+] [-] joshlambert|8 years ago|reply
For example when looking at a CI/CD deploy to an environment, you can easily access important Prometheus metrics and in the future logs, from the same console.
This also allows us to build more intelligence into the platform, as GitLab is more aware of your application and its health. One example is to incorporate Prometheus monitoring to compare the performance of a new release in an incremental deployment, and automatically pausing it if key metrics have degraded.
[+] [-] Snappy|8 years ago|reply
[+] [-] oblio|8 years ago|reply
I'm especially interested in a pipeline with parallel executions of different kinds of tests, maybe some manual checkpoint in there, a more complex chain with execution on different kinds of hosts or containers.
[+] [-] leg100|8 years ago|reply
You can do all the things you've listed. But you can't build an arbitrarily complex DAG of tasks. Instead, you must order everything into a sequential list of 'stages'. Within a stage you have a list of jobs, which are run in parallel. This might be enough for your needs, but I'd like flexibility to express dependencies for each and every task, Say `t1 -> ((t2,t3),t4 -> t5) -> t6`, etc.
And it's a pain to propagate variables from one task to another, like say setting an environment variable in one task, and getting its value in a downstream task. You end up writing scripts to write them to a file, telling gitlab to make that file an 'artifact', and then reading it downstream.
And then there's the transient errors, all of which are listed on open issues. We're using the hosted gitlab.com, and on some of our CI pipelines, we have a dozen or some stages. The chances of a transient error, .e.g. a runner getting a 503 from gitlab.com, are pretty high.
[+] [-] FooBarWidget|8 years ago|reply
For one of the software projects I'm involved in, I have more complex needs. We release binaries for multiple platforms so our Jenkins master delegates certain tasks to slaves running on specific OSes. Then at the end the Jenkins master downloads the built artifacts from all slaves and publishes everything to our artifact hosting server. As far as I can tell, Gitlab CI does not support this.
In future CI jobs I may even require user interaction, e.g. I may ask a human to sign off a report. I don't think Gitlab CI can do this.
But if your needs aren't so complex then Gitlab CI is great. It's UX-philosophically similar to Travis and setting it up is super simple, as opposed to Jenkins which is a pain to use.
[+] [-] Vinnl|8 years ago|reply
No manual checkpoints and different kinds of hosts or containers though.
[0] https://gitlab.com/Flockademic/Flockademic/pipelines
[+] [-] dankohn1|8 years ago|reply
https://cncf.ci/
[+] [-] 9034725985|8 years ago|reply
Will it be able to look at a project and compile it? For example: https://gitlab.com/postgres/postgres/-/jobs
[+] [-] Snappy|8 years ago|reply
[+] [-] deadbunny|8 years ago|reply