search

open-gitops / project

Repository for top-level information about the OpenGitOps project
Other
887 stars 36 forks source link

Adopters and certifications #133

Open roberthstrand opened 1 year ago

roberthstrand commented 1 year ago

The file project/ADOPTERS.md has been empty for a while now. Before adding my company, I was wondering if we wanted to combine this with one of the ideas we had earlier about having a certification for GitOps?

Unless I'm mistaken, I think the idea was brought up while we discussed the principles. The principles took priority, and creating a certification process will most likely take some effort on our part. Do we have the bandwidth for that?

I wouldn't mind taking this on, if this is something that the project still think is useful.

christianh814 commented 1 year ago

+1 for certification. I still believe it's something useful (and an ultimate goal if I'm not mistaken)

wouter2397 commented 1 year ago

I'm a big fan of creating a sort of GitOps maturity model. I think this helps organizations to start small and move step by step to the ultimate goal (certification).

edit: Another question that pops up for me. Are we talking about a certification for users/organizations on how to implement GitOps or a certification of software if they meet the GitOps principles?

roberthstrand commented 1 year ago

I'm a big fan of creating a sort of GitOps maturity model. I think this helps organizations to start small and move step by step to the ultimate goal (certification).

Sounds good, but I'd say that would be more potential content that could be produced rather than steps needed to get a certification. I'm very happy to help gather some thoughts on a maturity model and publish it.

edit: Another question that pops up for me. Are we talking about a certification for users/organizations on how to implement GitOps or a certification of software if they meet the GitOps principles?

I think the target should be organizations, more specifically services or products. Something to back up any claims that they follow GitOps as a process. Examples, any app delivery tool that claims it is a GitOps tool, or managed services from companies claiming to deliver a GitOps offering.

If any company have adopted GitOps internally, in full or partly, they should probably just be able to claim a spot as an adopter. If they have read everything produced by the working group or project, and still misunderstood what GitOps is, that is not that bad. What I personally would like to avoid is to have GitOps getting thrown around as a buzz word, and then someone is selling a solution that is not GitOps.

For full transparency, I am building solutions based on GitOps, which is partly why I this, but I have been interesting in adding certifications to the project since I joined the working group.

wouter2397 commented 1 year ago

I think both use cases can benefit from this but have a different point of view.

1) GitOps software/service certification

2) GitOps implementation maturity model

The first use case helps to add value to the term GitOps and make sure software is using GitOps the right way.

Second one for helping organisations implement GitOps internally. For myself I see a lot of organizations struggling on how to properly implement GitOps.

So if everyone agrees I think we should do something for both use cases but manage them separately.

And personally I'm willing to contribute to both use cases.

roberthstrand commented 1 year ago

That makes sense to me.

I suggest we take some time and talk about the maturity model, how we want to implement it, and then create tasks so that we can assign them to anyone interested.

The software/service certification is something we need to discuss how we want to implement. Do we want to create a standard form for it, then have a committee that approves it? How do we do quality checking? What does being certified mean, and does it expire?

I can bring both of these up at the next twice monthly, with is the December 7th.

scottrigby commented 1 year ago

Hey everyone, this is great!

Adopters

@roberthstrand to your first point in this issue, it would be good to help get the ball rolling for folks. It would be fantastic if you – and any others? – have bandwidth to work with folks to help them get listed in ADOPTERS.md. I still think the Example Organization listing there would be a good format to try to follow. If helpful, we could create a short lived adopters sub-group under @open-gitops/content to help jump start a good initial list?

Maturity model

This idea has come up in past WG meeting, and I still think it's a good one.

@roberthstrand and @wouter2397 I like your descriptions of this above. Though I'd caution tying this too tightly to the ADOPTERS list. Organizations may wish to describe their GitOps adoption journey in different ways.

@wouter2397 I like your suggestion to model a draft on Cloud Native Maturity Model Prologue. 💡 Suggestion: It may be a good idea to to connect with from the Cartografos Working Group, to better understand what their process was like in developing this.

Conformance and Certification

Can we use this terminology for disambiguation with end user certification programs? I believe this is what was meant in GitOps WG Mission Statement 🙂 Right?

  1. Conformance:

    I think what was described in comments above as "certification" for software/tools to be called "conformance".

    This would be assessment by the WG of how software/tools do, don't, are able to, are not able to (etc) follow the GitOps principles. This should include important notes on default and optional configuration, special precautions that should be taken for specific tools, caveats to bear in mind, etc.

  2. Certifications:

    End user training certifications.

    💡 Suggestion: The WG should develop criteria for these, so that orgs wishing to provide GitOps certifications can be held to standards set by the WG.

    💡 Suggestion: We may also want to connect with CD Foundation and Linux Foundation about LF trainings – Introduction to GitOps (LFS169) and GitOps: Continuous Delivery on Kubernetes with Flux (LFS269) – which came out of the CDF's GitOps Summit last year (see blog post: Linux Foundation Launches GitOps Training).

wouter2397 commented 1 year ago

As discussed in slack I will setup an initial draft of the Prologue document for the GitOps maturity model. The Cloud Native Maturity Model will function als the template/inspiration for this.

I will do my best to have a initial draft available for the next WG meeting for everyone to comment on to discuss in more detail what we want in there. Based on those comments we can update it to work towards a final v1.0 version.

roberthstrand commented 1 year ago

As discussed in slack I will setup an initial draft of the Prologue document for the GitOps maturity model. The Cloud Native Maturity Model will function als the template/inspiration for this.

I will do my best to have a initial draft available for the next WG meeting for everyone to comment on to discuss in more detail what we want in there. Based on those comments we can update it to work towards a final v1.0 version.

If you need any help, I'm happy to help 😊

scottrigby commented 1 month ago

hi @wouter2397 and everyone. We've updated ADOPTERS.md to include an incentive. Check out the new badge, described at the top of that doc. Would love your thoughts too.

There's more work to be done. In general - as GitOps has continued becoming more and more accepted as a north star for CD - the OpenGitOps project contributors and maintainers are rolling up our sleeves to get some more helpful documents in place for folks. Would definitely love to continue collaborating with you on some of this.