Live data from Hacker News

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

about.gitlab.com

1–10 of 72 posts

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

#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.

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

#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 all together" style of products.

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

#4
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.

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

#5
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 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.

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

#6
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…

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.

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

#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 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.

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

#8
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…

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.

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

#9
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.

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

#10
post #6
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…

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 vendors too.

Post reply on HN