在设置你的第一个 CI/CD 管道之前你应该知道什么？

您想要设置您的第一个自动部署管道，用于构建、测试并将代码更改部署到您的目标云环境。您已经花了几天时间阅读文档和博客来弄清楚您的自动部署管道应该包含哪些内容。但这一切似乎真的势不可挡。他们提到了各种工具，如AWS、Azure、GitHub Actions、Ansible、Jenkins、CircleCI、Terraform和Kubernetes——名单不胜枚举。而且您不确定初始自动部署管道需要哪一个。

❓您的第一个持续交付管道需要做什么和不做什么？

❓这种最小可行管道的必要组成部分是什么？

❓哪些工具是您初始管道的正确选择？

本文重点阐述了您应该如何回答上述问题的思考过程，以便您可以快速开始构建您的第一个交付管道。

01

假设

这篇文章推荐了构建您的第一个 CI/CD 管道的思考过程，假设如下：

您想在云上托管您的应用程序。

像您这样的初创公司希望优化速度，同时保留在扩展时自定义管道的灵活性。

02

CI/CD 定义的快速回顾

持续集成是尽可能频繁地将更改合并到主分支的过程。然后通过创建构建并针对构建运行自动化测试来验证这些更改。

持续交付是持续集成的扩展，因为它会在构建阶段后自动将所有代码更改部署到测试和/或生产环境。这意味着虽然您的构建和测试是自动化的，但部署触发器（比如单击按钮）是手动的。但是一旦开始部署，就不需要人工干预了。

持续部署类似于持续交付，只是部署的触发器也是自动化的。

所以，

持续交付是持续部署的一部分。

持续集成是持续交付和持续部署的一部分。

这篇文章的其余部分使用 CD 来指代持续交付和持续部署。您的思考过程和设置它们的工具选择将是相同的。

03

初始 CD 流水线应该自动化什么？

在决定您的初始管道（也称为最小可行管道）应该是什么时的指导原则是解决当前问题并将理论问题留给未来。采取小步骤，不要试图在一开始就建立一个完全成熟的管道。

虽然您的小步骤应该是您的应用程序用例的功能，但下面列出的是最必要的步骤 - 分为两个阶段。

先决条件

构建任何 CI/CD 管道的先决条件是开发人员定期将其代码提交到中央存储库。对于长期未合并到主分支的功能分支，开发人员应通过尽可能频繁地合并上游来使其保持最新。

第 1 阶段：解决持续集成

从您的 VCS 中提取分支的最新代码。

对分支代码运行单元测试，以检查应用程序没有因为新提交推送到分支而损坏。

每当您配置的事件发生时，触发分支代码的构建。

使用构建工具在服务器上运行代码构建。

作为构建过程的一部分，创建代码的一个或多个构建工件。

将构建工件存储在安全且可访问的云位置。

第 2 阶段：解决持续交付问题

启用触发将构建工件/应用程序部署到目标云环境（测试/登台/生产等）。

在手动触发部署时，它会自动将应用程序部署到目标环境，而无需任何停机时间。

提供一种简单的方法来确定部署是成功还是失败，并提供详细信息。

注意：您的初始管道不需要实施持续部署。

04

初始 CD 管道不应该做什么？

由于实施管道的每个步骤都需要花费时间，因此值得对您希望自动化的每个步骤进行成本效益分析，而不是上一节中提到的步骤。根据我们的经验，一开始，大多数应用程序不需要完全自动化的 CD 工作流程来完成以下工作：

使用基础架构即代码配置和管理资源

回滚部署

多区域或多云部署

自动缩放以动态添加或删除实例

管理许多测试阶段，如性能测试、UI 测试等

注意：在确定最小可行 CD 管道的职责时，请认识到您可能需要根据应用程序的用例添加一个或多个步骤。例如，支付处理应用程序可能比员工休假管理软件对错误部署更敏感。在这种情况下，前者的最小可行 CD 管道应该有一个步骤来快速回滚错误的部署，而后者可以先跳过它。

05

最小可行 CD 管道的必要组件是什么？

鉴于初始管道需要做什么，让我们看一下构建这样一个管道的必要组件。

版本控制系统 (VCS)，例如GitHub和GitLab

托管您的应用程序基础设施的公共云提供商，例如AWS、Azure和GCP

CI 工具：在应用程序代码上构建和运行测试

CD 工具：将应用程序代码部署到目标环境

06

为您的初始管道选择正确工具的关键标准

对于初始 CD 管道的每个组件，您都有大量工具可供选择。我们建议您选择具有以下特征的工具：

完全托管：完全托管的服务管理完成其工作所需的资源以及任何基础架构，因此您无需投入时间和人员来完成它。只有当您的应用程序需要严格的合规性并要求对您的代码或数据进行严格控制和规范访问时，您才应该在构建初始交付管道时考虑自托管。

易于扩展：可以通过使用代码或与第三方库集成轻松修改和扩展。

丰富的插件生态系统： 广泛的插件池为加速管道自动化提供支持。

解决管道的一个或多个阶段：工具解决的步骤越多，构建管道所需的工具就越少。例如，GitHub 既提供了版本控制系统，也提供了与自己的 CI/CD 的直接集成。

成本：工具的定价结构应该符合您的预算，即使在您扩展后也是如此。

07

推荐的最小可行管道

在构建您的第一个交付管道时，您有两个类别可供选择。

类型 1：管道即代码

管道即代码意味着您使用存储在存储库（例如 Git）中的代码配置部署管道中的步骤 - 构建、测试和部署。它使您能够以与管理应用程序代码相同的方式跟踪和管理对这些配置的更改——使用版本控制和拉取请求。

我们建议您选择下面指定的三个选项之一。

GitHub for VCS 和GitHub Actions for CI/CD

用于 VCS 的 GitLab 和用于CI/CD 的GitLab 管道

用于 VCS 的 BitBucket 和用于CI/CD 的BitBucket 管道

优点

它们使您能够直接从其平台构建、测试和部署，而无需与任何其他工具集成。

他们都提供：

◎完全托管的服务：他们提供、管理和扩展您的构建服务器以连续扩展并同时处理多个构建，这样您的构建就不会在队列中等待。

◎自托管运行器：您可以将构建指向您指定的机器上运行。这可以是您在防火墙后面或您管理的私有云上托管自己的服务器。

独立于云和平台。

用于常见任务的内置模板。

缺点

编写部署管道时涉及陡峭的学习曲线。学习如何使用正确的语法和模块正确编写一个需要时间。

这些管道可以达到 1000 多行代码，更新和维护它们可能会让人头疼。

仅当您的团队还使用 Jira 和 Confluence 等其他 Atlassian 工具时才选择 BitBucket，因为它可以与它们顺利集成。

注意：AWS CodePipeline和Azure Pipeline等解决方案也是管道即代码的示例，并且易于设置。但是，它们不可定制，因为与非 AWS 或非 Azure 工具/库的集成很困难。它们还使您完全依赖特定的云提供商。当您设置您的第一个管道时，您可能更明智地保留您希望如何发展您的管道的选项，然后决定您是否希望完全依赖特定的云提供商。

类型 2：发布自动化平台

发布自动化平台无需编写代码来创建管道。它们在管道上作为代码提供了一层抽象。这种抽象进一步简化了管道的创建和管理。

Argonaut就是这样一种工具。您可以在不到五分钟的时间内在您自己的云中运行您的第一个 CI/CD 管道。

08

你应该如何发展你的管道

建立初始管道后，请跟踪您仍然手动执行的操作以及频率。您可以通过自动化以下操作来改进您的初始管道：

代码覆盖分析：在构建步骤中添加代码覆盖工具以确定测试覆盖的代码百分比，如果低于某个阈值，则构建失败。假设开发人员添加了有用的测试，这可以确保代码质量。

多种环境：很难在本地开发环境中测试您的应用程序如何与其他服务、队列和数据库交互。在部署到生产环境之前，使用暂存环境对此进行测试。

安全集成：使用Snyk等工具来监控您的应用程序依赖项是否存在漏洞。

快速部署回滚：使用一种部署策略，确保如果您的应用程序在部署后立即无法使用，您只需选择要将其恢复到的最后一个版本，然后立即回滚到该版本。由于该版本之前已经过测试，因此它不应该再次经历流水线阶段。您可以从各种部署方法中进行选择，例如金丝雀部署、蓝/绿部署等。

快速修复发布：一些生产错误可能需要您通过绕过管道阶段（如测试）来提交和推送修复。虽然有风险，但您需要配置管道，使其支持在几秒钟内部署修补程序。

GitOps 实践：随着您的软件扩展，您应该采用GitOps实践——Git 来控制和管理您的基础设施和应用程序配置。

○使用基础架构即代码工具（例如Terraform）来管理您的基础架构。

○为 Kubernetes使用ArgoCD或Flux ，为您的无服务器 Lambda 应用程序使用无服务器堆栈。

09

总结

在产品开发的早期阶段，当您争分夺秒地发布产品更新时，您可能会倾向于推迟自动化 CI/CD 管道。虽然向您的客户提供新功能是重中之重，但在构建持续的 CI/CD 管道方面采取一些小步骤将帮助您更快、更可靠地发布功能。

一步一步自动化。不要试图在第一天就建立成熟的管道。

在其他人之前自动执行最重复的任务，例如部署回滚之前的构建步骤。

选择能够解决您当前需求、快速上手且不会让您陷入困境的工具，这样您就可以在扩展时轻松修改管道。