Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beyond CI/CD: GitLab's DevOps Vision (2017)

about.gitlab.com

Post reply on HN
Print view View original

21–30 of 72 posts

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#21

Post by akvadrako »

tazjin wrote: post #7

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…

Sorry but it's not clear what you are saying.

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.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#22

Post by Vinnl »

rdsubhas wrote: post #14

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 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 t…

> None of these are instrumentable/hookable.

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.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#23

Post by Vinnl »

cabraca wrote: post #3

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 a…

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.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#24

Post by d33 »

eadz wrote: post #18

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.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#25

Post by Vinnl »

oblio wrote: post #2

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.

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.

[0] https://gitlab.com/Flockademic/Flockademic/pipelines

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#26

Post by zingmars »

FooBarWidget wrote: post #10
foepys wrote: post #6

Earlier quoted context omitted.

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.

Corollary: do you hate Gitlab becoming bloatware and integrated suites? Then pay them! Even if you only use their open source offering, pay them. And not just "pity money" like 100 USD per year, but really pay them as if they're a serious commercial software vendor. Yeah I know people won't do that. But think about this for a second. It does not apply only to Gitlab but to lots of independent open source software ven…

How is that going to solve anything? The more you pay them the more bloated version you're going to get. In fact, if you want to travel lite the community edition is actually your best choice there.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#27

Post by dankohn1 »

akvadrako wrote: post #21
tazjin wrote: post #7

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…

Sorry but it's not clear what you are saying. 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.

The idea of keeping all state around your deployments in git is being called GitOps: https://www.weave.works/blog/gitops-operations-by-pull-reque...

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#28

Post by dankohn1 »

oblio wrote: post #2

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.

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.

https://cncf.ci/

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#29

Post by zingmars »

FooBarWidget wrote: post #5
oblio wrote: post #2

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.

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 slav…

You could achieve something like this with tags - https://docs.gitlab.com/ee/ci/yaml/#tags. Though you will need to define each machine individually in the CI file.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#30

Post by marcinzm »

akvadrako wrote: post #21
tazjin wrote: post #7

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…

Sorry but it's not clear what you are saying. 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.

Infrastructure as Code is a useful thing and this is essentially building on top of that idea. For example, you can spin up an exact copy of any environment automatically including all software running on it. If something utterly takes out an environment you can spin up a new copy of it and be certain it's identical to what was there before. You can rollback and manage multiple pieces of software at once if there's dependencies between them. You have an automatic and immutable audit log of who did what and when. Using git you can keep track of all infrastructure related changes in one place instead of trying to piece together information from multiple sources when debugging.
Post reply on HN