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

41–50 of 72 posts

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

#41

Post by akvadrako »

tazjin wrote: post #34
akvadrako wrote: post #32

Earlier quoted context omitted.

That doesn't explain it. You always need some global variable saying what the current state is. In your case, maybe it's the branch pointer in your git tree. In the k8s deployment, it's a tag value.

No, those don't contain the same information. Our Kontemplate repository contains the state of an entire cluster, including all versions and all configuration. A tag value is a single piece of mutable data that is in no relation to the other relevant data.

The tag points to the current version of your docker image, which contains the current configuration, except secrets which you don't want in a repo. Older deployments point to the older docker images which contain the older versions.

Still don't see any advantage to justify the additional complexity in your system.

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

#42

Post by dominotw »

mariusmg wrote: post #38
Cthulhu_ wrote: post #19

Earlier quoted context omitted.

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.

>it makes you look pretty bad. But they are being honest, they are saying what they are thinking....

Being honest and 'looking petty bad' are not contradictory.

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

#43

Post by oblio »

leg100 wrote: post #39
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.

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

Can you nest stages?

Say I want something like this:

  1. Sequential: stage "build", build-type agent.

  2. Sequential: stage "tests" (this is just a wrapper/container)

    2.1 Parallel: stage "integration tests #1", integration #1-type agent

    2.2 Parallel: stage "integration tests #2, integration #2-type agent

    2.3 Parallel: stage "deploy and functional tests" (this is just a wrapper/container)

       2.3.1 Sequential: stage "deploy", deploy-type agent

       2.3.2 Sequential: stage "functional tests", functional-type agent
Is it doable?

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

#44

Post by ebbv »

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.

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.

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

#45

Post by oblio »

mariusmg wrote: post #38
Cthulhu_ wrote: post #19

Earlier quoted context omitted.

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.

>it makes you look pretty bad. But they are being honest, they are saying what they are thinking....

They could rephrase it to: "we consider this an enterprise usage pattern for our software so this feature will be included in the paid Enterprise Edition".

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

#46

Post by tazjin »

akvadrako wrote: post #41
tazjin wrote: post #34

Earlier quoted context omitted.

No, those don't contain the same information. Our Kontemplate repository contains the state of an entire cluster, including all versions and all configuration. A tag value is a single piece of mutable data that is in no relation to the other relevant data.

The tag points to the current version of your docker image, which contains the current configuration, except secrets which you don't want in a repo. Older deployments point to the older docker images which contain the older versions. Still don't see any advantage to justify the additional complexity in your system.

We have more than one service, more than one environment, and auditability requirements (due to being a financial institution).

I find it more complex to try and keep track of remote state modifications than to have a single source of truth, but whatever floats your boat ;-)

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

#47

Post by slgeorge »

zingmars wrote: post #26
FooBarWidget wrote: post #10

Earlier quoted context omitted.

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.

The item it would solve is that if you "pay" then you can more directly influence their road-map. As a customer they want you to be happy and to remain one, that gives you the ability to influence direction. Individually, it may not be a lot, but in aggregate customers have power.

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

#48

Post by FooBarWidget »

zingmars wrote: post #26
FooBarWidget wrote: post #10

Earlier quoted context omitted.

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.

The more you pay them the less they have a reason to make things bloated for the sake of making it sellable to enterpises.

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

#49

Post by Already__Taken »

Cthulhu_ wrote: post #19
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.

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.

It says all those things your comment does. This is what happens when you dump an entire transcript of an hour long video, someone takes one poorly phrased line.

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

#50

Post by Chico75 »

oblio wrote: post #43
leg100 wrote: post #39

Earlier quoted context omitted.

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

Can you nest stages? Say I want something like this: 1. Sequential: stage "build", build-type agent. 2. Sequential: stage "tests" (this is just a wrapper/container) 2.1 Parallel: stage "integration tests #1", integration #1-type agent 2.2 Parallel: stage "integration tests #2, integration #2-type agent 2.3 Parallel: stage "deploy and functional tests" (this is just a wrapper/container) 2.3.1 Sequential: stage "deploy…

No, you can define jobs and stages. Stages run one after the others and all jobs inside the same stage will run in parallel, that's it, unless you start triggering remote jobs but then it becomes a lot let maintainable.
Post reply on HN