Notes from reading GitOps Cloud-native Continuous Deployment eBook
justingarfield opened this issue · 0 comments
justingarfield commented
- 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"