CI/CD——它适合你吗？

序言：软件实践仅在特定上下文中才是最佳选择

你是否曾参加过一个会议，演讲者对一个新流程充满热情？他们认为每个人都应该使用这个流程。通常，我怀疑这个流程是否适用于我的团队，但演讲者似乎暗示我没有完全理解他们想要传达的内容；也许我只需要开始尝试做出改变，才能意识到它的价值。虽然这可能是真的，但多年来我认识到，许多推销流程变革的人，他们为自己的软件开发团队带来了巨大的价值回报，但他们推销的解决方案可能不适用于其他软件开发团队。演讲者并不是想向我推销我不需要的东西，他们也不是不诚实的，他们通常只是从单一上下文来考虑他们的解决方案。

我所说的上下文是什么意思？上下文是指生产和部署软件的流程、人员、工具、网络、语言、部署模型和文化。在一种上下文中最佳的实践，在另一种上下文中可能不是最佳的，就像建造房屋的最佳实践可能与建造桥梁或摩天大楼的最佳实践不同。上下文的某些方面对某些最佳实践的影响大于其他方面。例如：

• 你的部署模型是影响你所选择流程的一个方面。当你部署到 Web 应用程序时，可以使用 CI/CD 流程，但当部署软件到飞机发动机中嵌入的芯片时，则无法使用 CI/CD。
• 对于所有成员都在同一地点并在同一时间开始工作的 Scrum 团队来说，站会可能是理想的；但对于四个坐在同一张桌子上进行结对编程的团队来说，这是一种时间浪费。

本系列文章将逐一审视软件实践，以突出每种实践可能适用和不适用的上下文，或者甚至可能适得其反的上下文。

这是一个受上下文约束的最佳实践示例。大学毕业后，一位开发人员多年来一直在创建静态网站，修改 HTML 页面和 JavaScript，并将代码更改提交到 GitHub，同时还维护着一个 Web 服务器，并使用 FileZilla 将文件更改上传到网站。但他后来发现了 Netlify，它使用 JamStack 流程，这使得他可以非常轻松地将更改提交到 GitHub，并进行验证、编译、优化和自动部署到生产网站。现在他告诉所有人，他们应该将 JamStack 和 Netlify 用于所有 Web 开发。也许他们应该这样做，如果他们正在部署静态公共网站。但有些开发人员正在部署内部网站。有些开发人员有数据库更改以及对其他团队代码的依赖。有些开发人员拥有任务关键型应用程序，无法承担因生产错误而导致十秒停机的风险。这些都是不同的上下文，Netlify/JamStack 方法对于这些上下文可能并不理想。

简而言之，任何“最佳实践”都适用于特定上下文，不太可能适用于所有上下文。我们需要识别适用于我们上下文的最佳实践。有些人对他们关于最佳实践的观念固执己见。他们认为一个流程应该始终应用于所有软件上下文，但就我个人而言，我认为可能没有永远是最佳的软件实践。我认为在许多上下文中，一些流程建议是糟糕的选择。

后续文章将逐一探讨流程，解释为什么这些流程在某些上下文中是糟糕的选择。将被证明在某些上下文中是糟糕选择的流程建议列表包括：Scrum、TDD、结对编程、持续部署（CD）、故事点、速度、代码审查、回顾、目标管理（MBO）和指标。

主要内容：CI/CD 适合你吗？

CI/CD 是“持续集成”和“持续交付”，也是“持续部署”的缩写。通常，也许总是，CI 需要在任何一个 CD 之前实现。CI 指的是编码人员频繁地将代码更改推送到共享团队仓库，通常每天多次。在许多上下文中，一旦将代码推送到共享代码库完成，就会开始构建软件。在某些上下文中，共享仓库的构建可能会定期进行，例如每小时一次。自动化构建的好处是快速识别两个开发人员所做的代码更改相互冲突的情况。

除了运行构建之外，许多 CI 管道还会对代码执行其他任务。这些任务包括“静态代码分析”，也称为“代码 Linting”，用于确定代码是否遵循代码格式标准和命名约定，以及检查代码是否存在逻辑错误和导致安全漏洞的错误。静态代码分析可以检测是否引入了新的未经批准的第三方库，或者代码复杂性级别是否超过了容忍度，或者仅仅是某个方法中的代码行数是否超过了公司标准。如果代码编译并通过了静态代码分析检查，那么它可能会执行一套单元测试和集成测试，以验证应用程序中没有现有逻辑被最新的代码更改破坏。

CI 包含两种实践：频繁的代码推送和自动化构建。频繁代码推送的一些好处包括：

• 如果开发人员所做的更改与已提交的其他开发人员的更改冲突，他们可以更快地获得反馈。
• 当开发人员所使用的代码库更新，并且对代码所做的更改数量较少时，基于共享仓库的构建更不容易与来自其他开发人员的更改冲突。
• 当开发人员频繁签入时，审查其他开发人员的代码更容易，因为需要审查的代码更改可能更少。
• 由于代码审查花费的时间更少，因此它们对审查代码的开发人员流程的干扰也更少。
• 由于代码审查花费的时间更少，其他开发人员更愿意进行代码审查，并且更愿意尽快进行。

自动化构建的一些好处包括：

• 如果推送到共享仓库的代码导致构建失败，可以相对快速地响应。
• 静态代码分析工具提供相对快速的反馈以识别问题。
• 如果代码更改在应用程序中创建了错误，单元测试和集成测试提供相对快速的反馈。

CI 对许多软件开发团队非常有益且无价，但它不一定在所有软件开发上下文中都有益。一些可能从 CI 中获得很少价值的上下文包括：

• 当项目中只有一个开发人员，并且 CI 环境尚不存在时。
• 当开发人员正在探索一种新的编程语言进行开发时。在这种情况下，设置 CI 所需的时间可能不值得为可能被放弃的东西付出。
• 当编码语言是脚本语言且没有编译步骤时。
• 当团队当前没有自动化构建，并在其本地机器上创建其产品的编译版本以部署到生产环境时。

你是否应该进行流程变更？

在评估任何流程（如 CI）是否适合你时，最重要的评估因素是：

• 实施该流程或实践是否值得我们（或我）的时间？
• 该流程是否会提高我们的产品质量？

如果该流程不能提高质量，这意味着它不能减少错误或减少安全漏洞或提高应用程序性能；并且实施该流程所花费的时间比不实施该流程所节省的时间要多得多，那么你可能不应该实施它。

你应该考虑 CI 吗？

根据 CI 的这一定义和评估标准，我认为大多数开发团队都应该考虑将 CI 实施到他们的开发流程中。

CD 的优点和缺点

CI/CD 的另一个方面是 CD。CD 代表“持续交付”或“持续部署”或两者兼而有之。这两个术语都暗示成功的软件构建会自动推送到可以测试或使用的环境中，但有些团队更喜欢将“交付”用于非生产环境，并将“部署”保留用于“生产”环境。此外，有些团队在软件成功构建后并不会真正自动将软件部署到环境中。相反，部署到环境需要授权人员点击按钮才能继续。

CD 的采用率低于 CI，部分原因是 CI 通常是 CD 的先决条件，但主要原因是 CD 对于许多软件产品来说不是一个好的部署策略。事实上，对于嵌入芯片并放置在飞机、汽车、冰箱、火箭和许多其他设备中的软件，CD 甚至是不可能的。对于大多数桌面应用程序以及通过应用商店交付给手机和其他设备的应用程序，CD 也不实用。CI/CD 最可能在 Web 应用程序和 Web API 的部署中发挥作用。

持续交付到非生产环境的一些好处包括：

• 它迫使你将所有东西都编码。这意味着你需要弄清楚如何自动化并自动应用特定于环境的配置值。你可能需要学习如何使用容器来简化部署以及版本控制和自动化 DevOps 的所有方面。
• 它创造了可能性。例如，一旦你花时间创建了一个管道，你的自动化构建可以流入已部署的环境，你就会发现现在可以轻松地针对测试环境自动化你的渗透测试和压力测试。
• 开发人员可以在部署环境中测试一些在开发人员环境中无法测试的更改（也称为：在我的机器上工作），例如：
  • 与应用程序中的线程行为相关的更改
  • 与多个设备的用户同时使用应用程序相关的更改
  • 对应用程序可伸缩性进行压力测试
  • 测试受安全机制（如 OAuth 和 TLS）影响的功能
• 开发人员可以更快地将新功能部署到可运行的环境中，以造福他人。
• 开发人员可以轻松部署到测试环境，而无需等待 DevOps 团队或 IT 团队为他们执行任务。
• 创建全新的环境变得更容易。也许你目前只有生产和测试环境。现在，如果所有部署组件都已自动化，你可以相对轻松地添加 QA 环境或临时环境。

持续部署到生产环境的一些好处包括：

• 开发人员可以更快地将新功能和修复部署到生产环境。这对于静态网站非常有价值。这是大多数 JamStack 站点的核心功能。
• 开发人员可以部署，而无需等待 DevOps 团队或 IT 团队为他们执行任务。

持续交付到非生产环境的一些挑战包括：

• 将更改应用于数据库与代码更改协调一致。
• 中断其他人正在进行的测试。
• 当多个团队部署到共享测试环境且某些更改依赖于顺序时，确保正确的部署顺序。

持续部署到生产环境的一些障碍包括：

• 软件需要烧录到物理芯片中。
• 软件需要通过应用商店发布。
• 在生产之前需要漫长的集成测试和/或手动测试，这通常是因为需要确保软件在用于维持生命时是正确的。
• 公司希望在客户与软件互动之前发现任何问题。

你应该考虑 CI/CD 吗？

你应该采用 CI 和/或 CD 吗？这是一个你需要自己回答的问题。你不仅应该考虑 CI/CD 可能为你的开发流程带来的好处和价值，还应该始终考虑采用一个流程是否比你可以做出的其他改变更有价值。仅仅因为我们认识到实施特定改变的价值，并不意味着我们应该立即实施它。也许对你的公司来说，在实施 CI/CD 之前完成你正在进行的项目更有价值。也许等待六周，等到 TeamCity 和 Octopus Deploy 的免费培训课程可用，如果你正在考虑使用这些工具进行 CI/CD，会更有价值。也许你正在考虑从 Subversion 迁移到 Git。如果是这样，你可能应该在构建 CI/CD 解决方案之前进行该更改，否则你可能需要完全重建你的 CI/CD 管道。此外，从手动构建到 CI/CD 不太可能在短时间内完成。这是一个你将随着时间的推移逐步实施和采用更多方面的过程。

我相信大多数开发团队都应该考虑将“持续交付”实施到他们的开发流程中。“持续部署”到生产环境可能主要对部署静态网站的团队有价值，也许还有一些数据量较少或不重要的数据的网站。

历史

• 2021 年 7 月 12 日：初始版本