第 4 章 生命周期管理
生命周期管理关心的是随着时间的推移更新和发展一个正在运行的系统。我们已经完成了硬件配置和安装基本软件平台的引导步骤(第 3 章)，所以现在将注意力转向持续升级在该平台上运行的软件。作为提醒，我们假设基础平台包括运行在每个服务器和交换机上的 Linux，加上 Docker、Kubernetes 和 Helm，以及 SD-Fabric 控制网络。
虽然可以狭隘的看待生命周期管理，并假设我们想要推出的软件已经经历了离线集成和测试过程(这是厂商发布其新版本产品的传统模式)，但我们采取了一种更广泛的方法，从开发过程开始创建新特性和功能。包括"创新"步骤在内形成了如图 17 所示的闭环，云行业告诉我们，这将帮助我们以更快的速度推出新特性。
图 17. 以提高特性发布速度为目标的良性循环。
当然，并不是每个企业都拥有和云提供商一样的开发人员大军，但并不意味着企业就失去了这个机会。创新可以来自许多来源，包括开源，所以真正的目标是使集成和部署民主化，这正是本章介绍的生命周期管理子系统的目标。
4.1 设计概述
图 18 提供了流水线/工具链的概述，这组成了生命周期管理的两个部分，持续集成(CI)和持续部署(CD)，并扩展了在第 2 章中的概要介绍。需要关注的关键是中间的镜像和配置存储库，代表了两个部分之间的"接口": CI 生成 Docker 镜像和 Helm Charts，并存储在各自的存储库中，而 CD 消费 Docker 镜像和 Helm Charts，从各自的存储库中取出。
图 18. CI/CD 流水线概述。
配置存储库(Config Repo)还包含由资源配置(Resource Provisioning)生成的基础架构构件的声明性规范，特别是 Terraform 模板和变量文件[1]。虽然 3.1 节介绍的资源配置"手动"和"数据输入"步骤发生在 CI/CD 流水线之外，但配置的最终输出是签入配置存储库(Config Repo)的"基础设施即代码(Infrastructure-as-Code)"。这些文件是生命周期管理的输入，意味着每当这些文件发生变化时，Terraform 就会作为 CI/CD 的一部分被调用。换句话说，CI/CD 使底层云平台中的软件相关组件和运行在该平台上的微服务工作负载保持最新。
[1] 我们通常使用术语"Config Repo"表示一个或多个存储库，存储所有与配置相关的文件。在实践中，可能有一个存储库存储 Helm Charts，另一个存储 Terraform 模板。
这个概要介绍中有三个要点。首先，通过在 CI 和 CD(以及资源配置和 CD)之间传递定义良好的工件，所有三个子系统都是松散耦合的，并且能够独立执行各自的任务。其次，成功构建和部署系统所需的所有可靠状态都包含在流水线中，特别是作为配置存储库(Config Repo)中的声明性规范。这是"配置即代码(Configuration-as-Code)"(有时也被称为 GitOps)的基石，也是本书实现 CI/CD 的云原生方法。最后，运营商有机会对流水线进行灵活配置，如图中的"部署门控(Deployment Gate)"所示，控制什么功能在何时部署。这个主题在侧边栏和本章的其他地方都有讨论。
持续交付 vs 持续部署(Continuous Delivery vs Deployment)
你还会听到 CD 指的是"持续交付(Continuous Delivery)"而不是"持续部署(Continuous Deployment)"，但我们感兴趣的是完整的端到端过程，所以本书中 CD 总是暗示后者。但请记住，"持续(continuous)"并不一定意味着"立即(instantaneous)"，可以在 CI/CD 流水线中注入各种门控功能，以控制何时以及如何推出升级。重要的是，流水线中所有阶段都是自动化的。
那么，"持续交付(Continuous Delivery)"到底是什么意思呢？可以说，当与"持续集成(Continuous Integration)"结合在一起时，它是多余的，因为由流水线的 CI 部分产生的工件集(例如 Docker 镜像)正是正在交付的东西。除非需要部署这些工件，否则没有"下一步"。这很棘手，但有些人会认为 CI 仅限于测试新代码，而持续交付对应于最后的"发布工件"步骤。出于我们的目的，我们将"发布工件"归入流水线的 CI 部分。
延伸阅读:
Weaveworks. Guide to GitOps.
图 18 最左边显示的第三个存储库是代码存储库(Code Repo)。虽然没有明确指出，但开发人员正在将新特性和 Bug 修复不断签入这个存储库，然后触发 CI/CD 流水线。针对这些签入代码运行一组测试和代码评审，并将这些测试/评审的输出报告发送给开发人员，开发人员据此修改。(图 18 中的虚线暗示了这些开发测试反馈循环。)
图 18 最右边显示了部署目标集，其中 Staging 和 Production 是两个示例。我们的想法是，首先将新版本软件部署到一组预发(Staging)集群中，在一段时间内，它将承受实际的工作负载，然后在预发(Staging)部署让我们确信升级是可靠的之后，再将其部署到生产(Production)集群中。
这是对实际情况的简化描述。通常，在任何给定时间都可以部署两个以上不同版本的云软件。发生这种情况的一个原因是升级通常是渐进式的(例如，在一段较长的时间内每次只部署几个站点)，这意味着即使是生产系统也在"Staging"新版本中扮演着角色。例如，一个新版本可能首先部署在 10%的生产机器上，只有被认为是可靠的，才被推广到下一个 25%，以此类推。具体的发布策略体现为可配置参数，详见 4.4 节。
最后，图 18 所示的两个 CI 阶段定义了测试(Testing) 组件。一个是针对签入代码存储库(Code Repo)的每个补丁集运行的一组组件级测试，这些测试作为集成的门禁，只有先通过这一轮初步测试，才能将补丁完全合并到代码存储库(Code Repo)中。一旦合并，流水线将跨所有组件运行构建，然后在质量保证(QA, Quality Assurance) 集群上进行第二轮测试。通过这些测试将决定是否部署，但是请注意，测试也发生在预发(Staging)集群中，作为流水线 CD 端的一部分。人们可能很自然的想知道在生产(Production)集群中运行软件后，如何继续测试？当然，这种情况也会发生，但我们倾向于称之为监控和遥测(以及随后的诊断)，而不是测试，这是第 6 章的主题。
我们将在接下来的章节中更详细的探讨图 18 中的每个阶段，但在深入研究各个机制时，在头脑中保持高层次的、以特性为中心的视角是有帮助的。毕竟，CI/CD 流水线只是一种精细的机制，帮助我们管理希望云支持的特性集。每个特性都从开发中开始，这与图 18 中集成门控(Integration Gate)剩下的所有内容相对应。一旦候选特性成熟到可以正式被代码存储库的主分支所接受(例如，合并)，就进入了集成阶段，在此期间，该特性将与所有其他候选特性(包括新特性和旧特性)结合起来进行评估。最后，只要某个特定的特性子集被认为是稳定的，并且被证明是有价值的，就会被部署并最终在生产中运行。因为测试在一组特性的整个生命周期中处于中心位置，所以我们从这里开始。
4.2 测试策略
我们生命周期管理的目标是提高特性发布速度，但必须与交付高质量(可靠、可伸缩性和满足性能需求)的代码相平衡。确保代码质量需要经受一系列测试，但"快速"做到这一点的关键是有效使用自动化。本节介绍了一种测试自动化的方法，但是我们首先讨论的是整体的测试策略。
在 Cloud/DevOps 环境中进行测试的最佳实践是采用左移(Shift Left) 策略，该策略在开发周期的早期引入测试，也就是在图 18 所示的流水线左侧。要应用这一原则，首先必须了解需要什么类型的测试，然后可以设置自动化这些测试所需的基础设施。
4.2.1 测试类别
关于测试类型，有很多关于 QA 的词汇，但不幸的是，这些定义通常是模糊、重叠的，并且并不总是被一致使用。下面给出了满足我们目的的简单分类，根据 CI/CD 流水线中发生的三个阶段(相对于图 18)组织了不同类别的测试:
- 集成门控(Integration Gate): 这些测试针对每次签入的补丁集运行，因此必须快速完成，并意味着它们的范围有限。合并前测试有两类:
- 单元测试(Unit Tests): 由开发人员编写的测试，专门测试单个模块。目标是通过对模块的公共接口执行"测试调用"来覆盖尽可能多的代码路径。
- 冒烟测试(Smoke Tests): 功能测试的一种形式，通常针对一组相关模块运行，但通过简单/粗略的方式(这样它们可以运行得更快)运行。"冒烟测试"一词的词源据说来自于硬件测试，比如，"当你打开盒子时，烟雾会从盒子里冒出来吗?"
- QA 集群: 这些测试定期运行(例如，一天一次，一周一次)，因此可以覆盖范围更广。它们通常测试整个子系统，或者在某些情况下，测试整个系统。有两类合并后/部署前测试:
- 集成测试(Integration Tests): 确保一个或多个子系统正确运行，并遵循已知的不变性。除了端到端(跨模块)功能之外，这些测试还使用了集成机制。
- 性能测试(Performance Tests): 类似于一定范围内(例如，在子系统级别)的功能测试，但是测量可量化的性能参数，包括扩展工作负载的能力，而不是正确性。
- 预发集群(Staging Cluster): 在推出到生产环境之前，候选版本要在预发集群上运行很长一段时间(例如，几天)。这些测试在一个完整且完全集成的系统上运行，通常用于发现内存泄漏以及其他随时间和工作负载变化的问题。此阶段只运行一种类型的测试:
- 浸泡测试(Soak Tests): 有时被称为金丝雀测试(Canary Tests) ，这些测试通过人工生成流量以及来自真实用户的请求相结合，在完整系统上处理真实工作负载。因为集成和部署了整个系统，所以这些测试也用于验证 CI/CD 机制，例如，签入配置存储库(Config Repo)的规格定义等。
图 19 总结了测试的顺序，突出了它们之间跨生命周期时间线的关系。注意，最左边的测试通常作为开发过程的一部分重复进行，而最右边的测试则是生产部署持续监控的一部分。为了简单起见，图中显示了在部署之前运行的浸泡测试，但是在实践中，系统的新版本可能会持续不断的推出。
图 19. 沿着特性发布时间轴的测试顺序，由 CI/CD 流水线实现。
制定测试策略的挑战之一是决定给定测试是否属于决定合并补丁的冒烟测试集，还是补丁合并到代码存储库后，但在部署之前发生的集成测试集。并没有严格的规则，这是一种权衡。我们都希望尽可能早的测试新软件，但是完全集成需要时间和资源(即运行候选软件的真实平台)。
与这种权衡相关的，是测试基础设施需要的虚拟资源(例如，预先配置了很多底层平台的 VM)和物理资源(例如，忠实代表最终目标硬件的小集群)的组合。同样，这并不是硬性的规则，但早期(Smoke)测试倾向于使用预先配置的虚拟资源，而后期(Integration)测试倾向于在具有代表性的硬件或干净的 VM 上运行，使用从头构建的软件。
你也会注意到，在这个简单的分类中，没有提到回归测试，但我们的观点是，回归测试的设计是为了确保 Bug 一旦被识别和修复，就不会再次引入代码中，这意味着它是新测试的常见来源，可以添加到 Unit、Smoke、Integration、Performance 或 Soak 测试中。实际上，大多数测试都是回归测试，与它们在 CI/CD 流水线中运行的位置无关。
4.2.2 测试框架
关于测试框架，图 20 显示了来自 Aether 的示例。具体细节会有很大不同，取决于需要测试的功能类型。在 Aether 中，相关组件显示在右边，但重新排列以突出子系统之间自顶向下的依赖关系，相应的测试自动化工具显示在左边，可以把它们看作特定领域测试类的框架(例如，NG40 将 5G 工作负载发送到 SD-Core 和 SD-RAN 上，而 TestVectors 将数据包注入交换机)。
图 20. Aether 测试框架示例。
图 20 显示的某些框架是与相应的软件组件共同开发的。TestVectors 和 TestON 就是这样，它们分别把定制的工作负载发送到 Stratum (SwitchOS)和 ONOS (NetworkOS)上，两者都是开源的，因此可以深入了解构建测试框架的挑战。相比之下，NG40 是用于模拟符合 3GPP 标准的蜂窝网络流量的专有框架，由于其复杂性及其遵循 3GPP 标准的价值，是一个封闭的商业产品。
Selenium 和 Robot 是五个例子中最常见的，都是开源项目，拥有活跃的开发人员社区。Selenium 是用于自动化 web 应用测试的工具，而 Robot 则是用于向任何定义良好的接口生成请求的更通用的工具。开发人员可以编写扩展、库、驱动和插件来分别测试用户门户和运行时 API 的特定特性的意义上说，这两个系统都是框架[2]。它们都说明了测试框架的目的，即提供一种方法(1)自动化执行一系列测试;(2)收集、归档测试结果;(3)对测试结果进行评价和分析。此外，当这些框架被用于测试具有可伸缩性的系统(如云服务)时，是否有必要使它们也具有可伸缩性?
[2] Selenium 实际上可以作为库使用，可以在 Robot 框架内调用它，如果考虑在 Web GUI 上的一组 HTML 定义的元素(如文本框、按钮、下拉菜单等)上调用 HTTP 操作，这就比较有用。
最后，如前一小节所讨论的，每个测试框架都需要一组资源，用于运行测试套件(生成工作负载)和正在测试的子系统。对于后者，理想状态是为每个开发团队生成目标集群的完整副本，但在云中按需实例化虚拟环境更划算。幸运的是，由于正在开发的软件是容器化的，而且 Kubernetes 可以在 VM 中运行，因此可以直接支持虚拟测试环境，也就意味着可以为不频繁(例如每日)的集成测试预留专用硬件。
