想搭建一条自动部署流水线，用来构建、测试并将新版本部署到目标环境。也许您已经花费数天时间阅读文档和博客，来弄清楚自动部署流水线应该包含哪些内容；但脑袋总归是懵的，让推荐的工具挑花了眼，诸如：AWS、Azure、GitHub Actions、Ansible、Jenkins、CircleCI、Terraform和Kubernetes——简直是没完没了。那么初始的自动部署流水线最重要的是什么？
- 第一个持续交付流水线需要做什么和不做什么？
- 这种最小可行流水线的必要组成部分是什么？
- 哪些工具是您初始流水线的正确选择？
本文重点阐述了面对上述问题的思考过程，以便您可以快速开始构建第一条交付流水线。
假设
- 想在云上托管应用程序。
- 尽快拿出成果，同时为未来扩展留有弹性。
CI/CD 概念回顾
持续集成是尽可能频繁地将更改合并到主分支的过程。然后通过创建构建并针对构建运行自动化测试来验证这些更改。
持续交付是持续集成的扩展，因为它会在构建阶段之后自动将所有代码更改部署到测试和/或生产环境。这意味着虽然您的构建和测试是自动化的，但部署触发器（例如单击按钮）是手动的。但是一旦开始部署，就不需要人工干预了。
持续部署类似于持续交付，只是部署的触发器也是自动化的。
所以，
这篇文章的其余部分使用 CD 来指代持续交付和持续部署。您的思考过程和用于搭建它们的工具选择将是一样的。
初始 CD 流水线应该自动化什么？
在决定您的初始流水线（也称为最小可行流水线）应该是什么时，指导原则是解决当下问题并将理论问题留给未来。小步快走，不要贪大求全。
您的小目标应该由应用程序功能来决定，但下面列出的是最必要的步骤 - 分为两个阶段。
先决条件
构建任何 CI/CD 流水线的先决条件是开发人员定期将其代码提交到中央存储库。对于长期未合并到主分支的功能分支，开发人员应通过尽可能频繁地合并上游来使其保持最新。
第 1 阶段：解决持续集成问题
- 从 VCS 中提取分支的最新代码。
- 在分支上运行单元测试，确认新提交的代码没造成损坏。
- 每当配置的事件发生时，触发分支代码的构建。
- 使用构建工具在服务器上运行代码构建。
- 作为构建过程的一部分，创建对应的一个或多个构建制品。
- 将构建制品存储在安全且可访问的云位置
第 2 阶段：解决持续交付问题
- 启用触发器，将构建制品/应用程序部署到目标云环境（测试/预发/生产等）。
- 在手动触发部署时，它会自动将应用程序部署到目标环境，而无需任何停机时间。
- 提供一种简单的方法来确定部署是成功还是失败，并提供详细信息。
注意：您的初始流水线不需要实现持续部署。
初始 CD 流水线不应该做什么？
由于实现流水线的每个步骤都需要花费时间，因此值得对您希望自动化的每个步骤进行成本效益分析，而不是上一节中提到的步骤。根据经验，最初阶段，大多数应用程序不需要完全自动化的 CD 工作流程来完成以下工作：
- 使用【基础架构即代码】来供应和管理资源
- 部署回滚
- 多区域或多云部署
- 自动缩放以动态添加或删除实例
- 管理许多测试阶段，如性能测试、UI 测试等
注意：在确定最小可行 CD 流水线的职责时，可能需要根据应用程序的需求来添加一个或多个步骤。例如，支付处理软件可能比员工休假管理软件对错误的部署更敏感；在这种情况下，前者的最小可行 CD 流水线应该有一个步骤来快速回滚错误的部署，而后者可以先跳过它。
最小可行 CD 流水线的必要组件是什么？
根据初始流水线要达到的要求，来看构建这样一个流水线的必要组件。
- 版本控制系统 (VCS)，例如GitHub和GitLab
- 托管您的应用程序基础设施的公共云提供商，例如AWS、Azure和GCP
- CI 工具：在应用程序代码上构建和运行测试
- CD 工具：将应用程序代码部署到目标环境
为您的初始流水线选择正确工具的关键标准
对于初始 CD 流水线的每个组件，您都有大量工具可供选择。我们建议您选择具有以下特征的工具：
- 完全托管：完全托管的服务管理完成其工作所需的资源[以及任何基础架构]，因此您无需投入时间和人员来完成它。只有当您的应用程序需要严格的合规性并要求对您的代码或数据进行严格控制和规范访问时，您才应该在构建初始交付流水线时考虑自行管理。
- 易于扩展：可以通过二次开发或与集成第三方库来轻松修改和扩展。
- 丰富的插件生态系统：具有广泛的插件库，可为加速流水线自动化提供支持。
- 支持流水线的一个或多个阶段：工具支持的步骤越多，构建流水线所需的工具就越少。例如，GitHub 既提供了版本控制系统，也提供集成了自己的 CI/CD。
- 成本：工具的定价结构应该符合您的预算，即使日后扩展时也是如此。
推荐的最小可行流水线
在构建您的第一个交付流水线时，您有两个类别可供选择。
类型 1：流水线即代码
流水线即代码，意味着您使用存储库（例如 Git）中的代码来设定部署流水线中的步骤 - 构建、测试和部署。它使您能够以与管理应用程序代码相同的方式跟踪和管理对这些配置的更改——使用版本控制和拉取请求。
我们建议您选择下面指定的三个选项之一。
| 版本控制 | 持续集成/部署 |
|---|---|
| GitHub | GitHub Actions |
| GitLab | GitLab 流水线 |
| bitbucket | BitBucket 流水线 |
优点
- 能够直接从其平台构建、测试和部署，而无需与任何其他工具集成。
- 均支持：
- 完全托管的服务：他们提供、管理和扩展您的构建服务器以连续扩展并同时处理多个构建，这样您的构建就不会在队列中等待。
- 自管的运行器：可以指定的机器上运行构建。可以是您将自己托管在防火墙后面，或您管理的私有云上的服务器。
- 独立于云和平台。
- 用于常见任务的内置模板。
缺点
- 编写部署流水线时涉及陡峭的学习曲线。需要时间学习如何使用正确的语法和模块正确编写出来。
- 这些流水线的代码可能多达 1000 多行，更新和维护让人头疼。
- 仅当使用 Jira 和 Confluence 等其他 Atlassian 工具时才选 BitBucket，因为它们可以无缝集成。
注意：AWS CodePipeline和Azure Pipeline等解决方案也是流水线即代码的典范，并且易于设置；但它们无法定制，因为与非 AWS 或非 Azure 工具/库的集成相当困难。它们还使您绑定特定的云提供商。搭第一条流水线时，建议不用过早决策是否绑定云提供商。
类型 2：交付自动化平台
交付自动化平台无需编写代码来创建流水线。它们在“流水线上即代码”之上提供了一层抽象，简化了流水线的创建和管理。
Argonaut就是这样一种工具。五分钟即可在自己的云上运行一个 CI/CD 流水线。
流水线的演进
建立初始流水线后，跟踪仍然手动执行的操作以及频率。可以通过以下工作的自动化，来改进流水线：
- 代码覆盖率分析：在构建步骤中添加代码覆盖率工具，以确定测试覆盖的代码百分比，如果低于某个阈值，则构建失败。假设开发人员添加了有用的测试，则此步骤可以确保代码质量。
- 多环境：很难在本地开发环境中测试您的应用程序如何与其他服务、队列和数据库交互。在部署到生产环境之前，使用预发环境对此进行测试。
- 安全集成：使用Snyk等工具来监控您的应用程序依赖项是否存在漏洞。
- 快速部署回滚：使用一种部署策略，确保发现应用程序部署导致的失效时，只需选定想恢复的上一个版本，即可回滚到该版本。由于该版本已经过测试，就不需要再走流水线的构建等阶段。您可以从各种部署方法中进行选择，例如金丝雀部署、蓝/绿部署等。
- 快速修补程序发布：一些生产错误可能需要您通过绕过流水线阶段（如测试）来提交和推送修复程序。虽然存在风险，但您需要配置流水线，使其支持在几秒钟内部署修补程序。
- GitOps 实践：随着您的软件扩展，您应该采用GitOps实践——Git 来控制和管理您的基础设施和应用程序配置。
总结
在产品开发的早期阶段，争分夺秒地发布产品更新时，可能会倾向于推迟自动化 CI/CD 流水线。虽然交付新功能是重中之重，但采取小步快走来构建持续 CI/CD 流水线，可以更快、更可靠地发布功能。
- 一步一步自动化。不要试图在第一天就建立成熟的流水线。
- 优先自动化重复频率最高的任务，例如部署回滚之前的构建步骤。
- 选择能够解决您当前需求、快速上手，且不会被绑架的工具，这样您就可以在扩展时轻松修改流水线。
附：
常见的工业流水线，附动图
