总结

本章涵盖了以下内容：

• 持续交付的核心思想是应用始终处于可发布状态 — 部署管道从代码提交到可发布软件，应尽可能自动化。
• 交付管道完成执行后，将获得一个制品（容器镜像） — 可用于在生产环境中部署应用。
• 每个发布候选（Release Candidate）应可唯一识别 — 使用 Git 提交哈希可确保唯一性、可追溯性和自动化。语义版本控制可作为向用户和客户传达的显示名称。
• 提交阶段结束后，发布候选被交付到制品仓库 — 验收阶段在生产类环境中部署应用并运行功能和非功能测试。全部通过后，发布候选即为生产就绪。
• Kustomize 配置定制方法基于基础（Base）和覆盖层（Overlay）的概念 — 覆盖层构建在基础清单之上，通过补丁定制。
• 可定义补丁自定义环境变量、卷挂载的 Secret、CPU 和内存资源、ConfigMap 和 Ingress — 实现不同环境的差异化配置。
• 部署管道的最后一部分是生产阶段 — 更新部署清单为最新发布版本并最终部署。
• 部署可以是基于推送（Push-based）或基于拉取（Pull-based）的 — GitOps 是一套运营和管理软件系统的实践方法。
• GitOps 基于四项原则 — 系统部署应是声明式的、版本化和不可变的、自动拉取的、持续协调的。
• Argo CD 是运行在集群中的软件代理 — 自动从源仓库拉取期望状态并在期望状态与集群状态不一致时将其应用到集群，以此实现持续部署。