《Google SRE工作手册》系列读书分享之 GitOps实践之渐进式交付（视频+文字版）

引言

本期分享主题是 GitOps 实践之渐进式交付，本期分享内容为 GitOps 与渐进式交付、k8s 内置机制浅析以及使用 ArgoCD/CODING 实施渐进式交付。

一、GitOps与渐进式交付

（1）Release Engineering Principles

The basic principles of release engineering are as follows:

发布工程的基本原则如下:

Reproducible builds 可复现的构建

The build system should be able to take the build inputs(source codeassetsand so on)and produce repeatable artifacts.The code built from the same inputs last week should produce the same output this week.

构建系统应该能够接受构建输入(源代码、资源等)并产生可重复的工件。从上周相同的输入构建的代码应该产生本周相同的输出。

Automated builds 自动化构建

Once code is checked inautomation should produce build artifacts and upload them to a storage system.

一旦代码被检入，自动化应该产生构建工件并将其上传到存储系统。

Automated tests 自动化测试

Once the automated build system builds artifactsa test suite of some kind should ensure they function.

一旦自动化构建系统构建了工件，一种测试套件应该确保它们的功能。

Automated deployments 自动化部署

Deployments should be performed by computers not humans.

部署应该由计算机执行，而不是人类。

Small deployments 小规模部署

Build artifacts should contain small,self-contained changes.

构建工件应该包含小而独立的更改。

Cl/CD coupled with release automation can deliver continuous improvements to the development cycle, as shown in Figure 16-1.When releases are automated,you can release more often.For software with a nontrivial rate of chanae.releasina more often means fewer chanaes are bunded in anv aiven release artifact.Smaller, self contained release artifacts make it cheaper and easier to roll back any given release artifact in the event of a bug Ouicker release cadences mean that bua fixes reach users faster.

CI/CD与发布自动化相结合可以在开发周期中实现持续改进，如图16-1所示。当发布被自动化时，您可以更频繁地进行发布。对于具有较高变更率的软件来说，更频繁的发布意味着在任何给定的发布工件中捆绑的变更更少。更小、自包含的发布工件使得在出现错误时回滚任何给定的发布工件更加廉价和容易。更快的发布节奏意味着错误修复能够更快地到达用户手中。

（2）Balancing Release Velocity and Reliability

Release velocity(hereafter called“shippina”)and reliabillity are often treated as opposina aoalsThe business wants to ship new features and product improvements as quickly as possible with 100% reliability! While that goal is not achievable(as 100% is never the right target for reliability; see Implementing SLOs)it is possible to ship as quickly as possible while meeting specific reliability goals for a given product.

发布速度(以下简称为“发布”)和可靠性通常被视为相反的目标。企业希望以尽可能快的速度发布新功能和产品改进，同时保持100%的可靠性!虽然这个目标是不可实现的(因为100%从未是可靠性的正确目标;参见实施SLOs)，但可以在满足给定产品的特定可靠性目标的同时尽可能快地进行发布。

The first step toward this goal is understanding the impact of shipping on software reliability In Google's experience,a majority of incidents are triggered by binary or configuration pushes(see Results of Postmortem Analysis). Many kinds of software changes can result in a system failure-for examplechanges in the behavior of an underlying componentchanges