CI/CD

CI/CD 代表 Continuous Integration 和 Continuous Deployment。让我们快速回顾一下这两个术语的含义。

持续集成

“集成什么？”你可能会问自己。答案是源代码，确保由不同团队成员编写的代码尽可能频繁地合并到单一的默认分支中。这一点非常重要，以避免在孤立环境中开发功能。团队成员独立工作的时间越长，最终合并的规模就越大。大合并难以审查，并且存在极大的不确定性，即是否一切仍然正常工作。

为了减少在多个功能最终合并到默认分支时出现的“大爆炸”式意外，自动化，尤其是自动化测试至关重要。你越早将代码与团队其他人的代码合并，效果就越好。

在软件工程中，我们希望避免不确定、意外和麻烦这些负面因素！

持续部署（或持续交付）

CD 在 CI 的基础上更进一步。除了尽可能频繁地将代码合并到默认分支外，为什么不也尽可能频繁地部署到生产环境呢？如果每次向默认分支合并都部署到生产环境，会怎样？如果这听起来令人害怕，别担心。第一次想到这一点时感到有点害怕是完全正常的！

每个人在学习这个主题时都会问导师一个问题：“我的功能还没完成，怎么能部署到生产环境？”答案虽然复杂，但核心思想是：“只要你的代码没有被使用，就可以部署任意多的部分。”一种常见的隐藏未完成代码的模式称为 feature toggles（也称为 feature switch、feature flag、feature flipper、conditional feature 等）。本质上，我们可以将其理解为一个类似以下形式的 if...else... 语句：

1if (isFeatureOn("myFeature")) {
2    // 在此处执行 myFeature 的代码
3}

随着团队的 CI/CD 流水线逐渐成熟，feature toggles 也会变得越来越复杂。你最终会发现，这些 toggle 不再仅仅基于布尔值。例如，想象一个仅对每周至少访问一次网页应用且之前提供过 beta 版本反馈的加拿大用户启用的功能。你可以根据需要做到非常精细的程度，并且有各种服务和技术可以帮助你更轻松地管理这些 feature toggles。

章节活动概览

在上一章中，我们开发了必要的脚本来手动部署 Web 应用程序。现在，是时候自动化这一过程了，使得对 master 分支的每一次更改都能自动部署。

参考项目概览图表，本章我们将重点关注架构图中的以下部分：GitHub Actions 流水线中的“Deploy”任务。

为什么现在？

此时，我们的前端应用程序仅包含 Sapper 模板以及客户端代码可用的 Firebase SDK。因此，你可能会问：“为什么现在？我们还没有开发任何内容。为什么要花时间现在创建持续部署流水线？”

这里的座右铭是：

尽早部署。频繁部署。让它成为文化的一部分！

在只有单一服务且尚未有测试的情况下，创建部署流水线永远是最容易的。在后续章节中，我们将逐步增强部署流水线。

团队项目建议

目标是：每个开发团队都应达到这样的状态——新成员在第一天上班的晚上就能将他们的第一个代码变更部署到生产环境。

一方面，这迫使团队专注于自动化，以及日常流程的 效率、可靠性 和 可扩展性。另一方面，部署到生产环境不应是一个只有专家每隔几周才敢进行的可怕事件。在后续章节中，我们将讨论如何缓解对部署到生产环境的恐惧。