lloydchang

@aliusmiles I agree with you that the documentation needs to be updated. In particular, the sentence > [Notification controller validates the authenticity of the payload using HMAC](https://github.com/fluxcd/website/blame/main/content/en/docs/guides/webhook-receivers.md#L165) is misleading. This...

A suggestion is to **invert your list** so it begins with "Start Small!" towards bigger "Communication Strategy": > 1. Start Small! > 2. K8s has to be on the roadmap...

@mikecali @sunil390 @OpsM0nkey @scottrigby I recommend adding "Independent deployability" and "Rapid application deployment" to the adoption journey document as numbers 2 and 3. --- Hence the list becomes: 1. Start...

Thank you @mikecali > "(ie start w infra, then apps, then network)" Two out of the three examples, "start w infra" "and "then network", aren't in the scope of GitOps'...

@mikecali As for: > 5. Standardisation (can’t have 20 x Git sources of truth) I recommend the Standardisation example be changed to: > 5. Standardisation (i.e. Choose a standard from...

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

Depending on the Git implementation in use for GitOps, there may need to be a walkthrough. For example: > **Basic Gerrit Walkthrough — For GitHub Users** > Note: This document...

@mikecali Can > Standardisation (can’t have 20 x Git sources of truth) change to: > Standardisation (i.e. Choose a standard from the options in Argo CD and Flux CD to...

@mikecali LGTM re: Adoption Journey Document: "1. Start Small! _[...]_ 9. Communication Strategy..." As for Git best practices, I wouldn't create it because less is more. There is already a...

@OpsM0nkey wrote: > 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...