Notes from reading GitOps Cloud-native Continuous Deployment eBook

[Justin Garfield]

• Want Pull-based Deployments w/ Operator to have better security
  • This is discussed quite controversially. The folks at Codefresh believe that this is a huge disadvantage since dynamic changes of resources triggered by controllers are being blocked to be dynamic.
• Entertain "Preview Environments" either with Branch-based or PR-based
  • Be sure to add the possibility to limit or delete a deployment explicitly if it runs havoc
• There is a common misunderstanding when talking about trunk-based development. Branches aren’t always evil. As long as the used branch is short-lived and maintained by one person only17, branches are considered fine.
• Use KinD to automatically test your roll-outs before actually going to production.
• "We recommend using only a single environment and avoiding stage propagation altogether."
  • If you really need multiple stages (e.g., Dev, Staging, Production, etc.) with a deployment environment for each, you could handle it by integrating changes from one stage to another using branches and merges.
• Please, don’t bypass the repository and automatically update the new image directly in the target environment. Beware, we do GitOps to have full control and observability using the single source of truth — the environment repository, so version pinning is inevitable to achieve this.
• Page 22 - Where should I put deployment manifests?...Try and understand this more...currently confused by wording.
• "For the local Kubernetes cluster, we recommend using KinD"
• "gotk" prefix == "GitOps Toolkit"