Adoption Journey Document

[mikecali]

Now that GitOps is getting a lot of traction, we got a lot of questions from different parties how to start their own GitOps journey.
I think this warrants a dedicated document of what are the things to consider before even thinking of adopting GitOps to avoid disaster or bad taste.

Something I have discussed with my colleagues are GitOps pre-requisites and we ended up with this list.

1. Communication Strategy (why are we doing this, how does it fit our context, how will we manage risk)
2. Automation Maturity - Infrastructure as Code at the minimum
3. Executive sponsor
4. Champions / CoP - a team that can ‘go first’
5. Standardisation (can’t have 20 x Git sources of truth)
6. Enablement strategy - Git enablement, Ansible enablement, DevSecOps Enablement
7. Matrix view of crawl / walk / run (ie start w infra, then apps, then network)
8. K8s has to be on the roadmap - how do we get ready for that
9. Start Small!

Happy to expound this and contribute if needed.

[mikecali]

I agree.
Looks good to me.

[mikecali]

@lloydchang The idea of the list I shared is to put a recommendation around what an organization needs to consider or lined up before getting into GitOps adoption.

My opinion is that the 2 points you added might be encapsulated under this: Matrix view of crawl/walk / run (ie start with infra, then apps, then network)?

[OpsM0nkey]

Could I also recommend that we add something about considering the right skill set at the start of the journey? GitOps is the primary enabler of a software driven operating model, so the ability to think like a software engineer (or at least understand SDLC principles) is vital - i.e branching, pull requests etc...
I think it's almost assumed knowledge, but there are tons on traditional infrastructure people out there there that can't comprehend the power of the pull request just yet...

[OpsM0nkey]

Good point @OpsM0nkey Related, not all software engineers use pull requests (PRs). PR isn't inherit in Git at all. PR is a feature in code review tools such as GitHub, GitLab, Bitbucket, Gitea.

It's a very good point - PRs aren't a feature of Git, but rather of the Git based platforms. But they're not just for code review (albeit, it's an important aspect) - they're a notification that a change is incoming and a discussion forum for the intended change. IMO, they're an important part of what makes GitOps so effective for scalable operations. When utilised properly, a PR takes away the need to maintain certain traditional ITIL change management practices (such as CAB) - ie the Pull Request is the Change Request, and all of its links, discussions and approvals provide the necessary assurances that a change is good to go.
That's not to take away from the main point of this thread, other than to say that understanding of software development practices (like branching, PRs) is an important consideration when adopting GitOps.

[mikecali]

I totally agree. Should we actually have a separate section called "GIT Best Practices"
I actually started thinking about it and here is the first stub of what I thought we can add.

GIT Best practice

Don’t commit code as an unrecognized author. Git needs to be a source of truth and allow auditing of all actions.
Ensure all secrets are stored encrypted. Use 3rd party secrets Management tools
Don't commit huge files or binaries into the repo. Consider using binary repository managers.
Use git ignore when appropriate and make it clear.
Clean up stale branches and Repos
Create a Branch naming convention that's scalable
Enable security alerts and cleanup old users
Scan for vulnerabilities and secret commits (Example AWS Keys)```

[OpsM0nkey]

@mikecali I like it 🙂

[mikecali]

@lloydchang @OpsM0nkey

I think this is really good now? I am happy with this list. Should we move this forward?

1. Start Small!
2. K8s has to be on the roadmap - how do we get ready for that (i.e. start w infra, then network)
3. Matrix view of crawl / walk / run (i.e. Independent deployability, Rapid application deployment)
4. Enablement strategy - Git enablement, Ansible enablement, DevSecOps Enablement
5. Standardisation (can’t have 20 x Git sources of truth)
6. Champions / CoP - a team that can ‘go first’
7. Executive sponsor
8. Automation Maturity - Infrastructure as Code at the minimum
9. Communication Strategy (why are we doing this, how does it fit our context, how will we manage risks

With the addition of Git Best Practices maybe? But I am not sure if this fits in the adoption journey document.

1. Don’t commit code as an unrecognized author. Git needs to be a source of truth and allow auditing of all actions.
2. Ensure all secrets are stored encrypted. Use 3rd party secrets Management tools
3. Don't commit huge files or binaries into the repo. Consider using binary repository managers.
4. Use git ignore when appropriate and make it clear.
5. Clean up stale branches and Repos
6. Create a Branch naming convention that's scalable
7. Enable security alerts and cleanup old users
8. Scan for vulnerabilities and secret commits (Example AWS Keys)

[mikecali]

@lloydchang yes of course.

How about this?

1. Start Small!
2. K8s has to be on the roadmap - how do we get ready for that (i.e. start w infra, then network)
3. Matrix view of crawl / walk / run (i.e. Independent deployability, Rapid application deployment)
4. Enablement strategy - Git enablement, Ansible enablement, DevSecOps Enablement
5. Standardisation (i.e. Choose a standard from the options in Argo CD and Flux CD to structure your repositories)
6. Champions / CoP - a team that can ‘go first’
7. Executive sponsor
8. Automation Maturity - Infrastructure as Code at the minimum
9. Communication Strategy (why are we doing this, how does it fit our context, how will we manage risks

@lloydchang @OpsM0nkey what do you think about this?

With the addition of Git Best Practices maybe? But I am not sure if this fits in the adoption journey document.

1. Don’t commit code as an unrecognized author. Git needs to be a source of truth and allow auditing of all actions.
2. Ensure all secrets are stored encrypted. Use 3rd party secrets Management tools
3. Don't commit huge files or binaries into the repo. Consider using binary repository managers.
4. Use git ignore when appropriate and make it clear.
5. Clean up stale branches and Repos
6. Create a Branch naming convention that's scalable
7. Enable security alerts and cleanup old users
8. Scan for vulnerabilities and secret commits (Example AWS Keys)

[lloydchang]

@mikecali Would you please take it from here? Thank you!

---

Hello @mikecali @OpsM0nkey @SimonDelord @waynedovey @glimpsovstar

Today, @scottrigby opened this topic during GitOps Working Group meeting.

Here is the outcome:

Feedback on Adoption Journey Document

#19
#43 note commit co-authors

• @chris-short: numbering these doesn't make sense
• @chris-short: There is no one way to adopt GitOps
• @todaywasawesome: could make a good Green paper
• @JaimeMagiera: perhaps better as a blog
• @scottrigby: I would like to see more paragraph content

Thanks all!