在建立你的第一个CI/CD管道之前你应该知道什么

方石剑
138 阅读11分钟

在建立你的第一个CI/CD管道之前，你应该知道什么？

你想建立你的第一个自动部署管道，构建、测试和部署代码变化到你的目标云环境。你已经花了好几天时间阅读文档和博客，以弄清楚你的自动部署管道应该包括什么。但这一切似乎真的让人不知所措。他们提到了各种工具，如AWS、Azure、GitHub Actions、Ansible、Jenkins、CircleCI、Terraform和Kubernetes--这个名单是无穷无尽的。而你不确定哪一个是你最初的自动部署管道所必需的。

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

这样一个最低限度的可行管道的必要组成部分是什么？

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

本文重点阐述了你应该如何去回答上述问题背后的思考过程，以便你能迅速开始建立你的第一个交付管道。

假设

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

  • 你想在云上托管你的应用程序。
  • 像你这样的初创企业希望优化速度，同时保留灵活性，以便在你扩展时定制你的管道。

对CI/CD定义的快速回顾

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

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

持续部署就像持续交付，只是部署的触发也是自动化的。

所以。

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

初始CD管道应该自动处理什么？

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

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

前提条件

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

第一阶段：解决持续集成问题

  1. 从你的VCS中拉出该分支的最新代码。
  2. 在该分支的代码上运行单元测试，以检查应用程序是否因推入该分支的新提交而损坏。
  3. 只要有你配置的事件发生，就触发分支代码的构建。
  4. 使用构建工具在服务器上运行代码的构建。
  5. 作为构建过程的一部分，创建一个或多个代码的构建工件。
  6. 将构建工件存储在一个安全和可访问的云位置。

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

  1. 启用触发构建构件/应用程序部署到目标云环境（测试/分期/生产等）。
  2. 在手动触发部署时，它会自动将应用程序部署到目标环境，而不需要任何停机时间。
  3. 提供一个简单的方法来确定部署是否成功或失败，并给出细节。

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

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

由于实施管道的每一步都要花费时间，因此值得对你想自动化的每一步进行成本效益分析，除了上一节中提到的那些步骤。根据我们的经验，在开始的时候，大多数应用程序不需要一个完全自动化的CD工作流程，因为以下几点。

  • 使用基础设施即代码配置和管理资源
  • 回滚部署
  • 多地区或多云部署
  • 自动扩展以动态添加或删除实例
  • 管理许多测试阶段，如性能测试、UI测试等。

注意：在确定你的最小可行CD管道的职责时，要认识到你可能需要根据你的应用程序的使用情况增加一个或多个步骤。例如，一个支付处理程序可能比一个雇员离职管理软件对不良部署更敏感。在这种情况下，前者的最小可行CD管道应该有一个步骤来快速回滚一个糟糕的部署，而后者一开始就可以跳过它。

最小可行的CD管道有哪些必要的组成部分？

考虑到初始管道需要做什么，让我们来看看建立这样一个管道的必要组件。

  1. 一个版本控制系统（VCS），如GitHub和GitLab
  2. 一个托管你的应用基础设施的公共云供应商，如AWS、Azure和GCP
  3. 一个CI工具。在应用程序代码上构建和运行测试
  4. 一个CD工具。将应用程序代码部署到目标环境中。

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

对于你的初始CD管道的每一个组成部分，你有大量的工具可以选择。我们建议你选择具有以下特点的工具。

  • 完全管理。一个完全管理的服务会管理其工作所需的资源，以及任何基础设施，所以你不需要投入时间和人员去做。只有当你的应用程序需要严格的合规性，要求对你的代码或数据进行严格的控制和规范的访问时，你才应该考虑在建立你的初始交付管道时进行自我托管。
  • 易于扩展。可以通过使用代码或与第三方库集成，轻松修改和扩展。
  • 丰富的插件生态系统。 广泛的插件库提供支持，以加速你的管道的自动化。
  • 解决你的管道的一个或多个阶段。一个工具解决的步骤越多，你需要集成的工具就越少，以建立你的管道。例如，GitHub同时提供了一个版本控制系统和与自己的CI/CD的直接集成。
  • 成本。工具的价格结构应该在你的预算范围内，即使在你扩大规模后也是如此。

推荐的最小可行管线

在建立你的第一个交付管道时，你有两个类别可以选择。

第1类：作为代码的管道

作为代码的管道意味着你在部署管道中配置步骤--构建、测试和部署，并将代码存储在仓库中，如Git。它使你能够跟踪和管理这些配置的变化，就像你管理你的应用程序代码一样--使用版本控制和拉动请求。

我们建议你选择下面三个选项中的一个。

优点

  • 他们使你能够直接从他们的平台上构建、测试和部署，而不需要与任何其他工具集成。
  • 他们都提供了这两点。
    • 完全管理的服务：他们提供、管理和扩展你的构建服务器，以持续扩展并同时处理多个构建，这样你的构建就不会被留在队列中等待。
    • 自我托管的运行器：你可以将你的构建指向你指定的机器上运行。这可以是你自己在防火墙后面托管的服务器，或在你管理的私有云上。
  • 与云和平台无关。
  • 常见任务的内置模板。

缺点

  • 在编写部署管道时，有一个陡峭的学习曲线。需要时间来学习如何用正确的语法和模块正确地编写管道。
  • 这些管道可以达到1000行以上的代码，更新和维护它们可能成为一个令人头痛的问题。
  • 只有当你的团队也使用其他Atlassian工具如Jira和Confluence时，才会选择BitBucket，因为它能顺利地与它们整合。

注意：像AWS CodePipeline和Azure Pipeline这样的解决方案也是管道作为代码的例子，而且很容易设置。然而，它们不是可定制的，因为与非AWS或非Azure工具/库的集成很困难。它们还使你完全依赖于特定的云供应商。当你建立你的第一个管道时，保持你的选择是开放的，你想如何发展你的管道，然后决定你是否想完全依赖一个特定的云供应商，这可能是更明智的。

类型2：发布自动化平台

发布自动化平台消除了为创建管道而编写代码的需要。它们在管道作为代码的基础上提供了一个抽象层。这种抽象性进一步简化了管道的创建和管理。

Argonaut就是这样一个工具。你可以在5分钟内让你的第一个CI/CD管道在你自己的云中运行。

你应该如何发展你的管线

一旦你建立了一个最初的管道，请跟踪你仍在手动做什么，以及多长时间做一次。你可以通过自动化以下工作来发展你的初始管道。

  • 代码覆盖率分析。在构建步骤中添加一个代码覆盖率工具，以确定测试所覆盖的代码百分比，如果低于某个阈值，则构建失败。假设开发人员已经添加了有用的测试，这可以确保代码质量。
  • 多种环境。在你的本地开发环境中，很难测试你的应用程序如何与其他服务、队列和数据库互动。在部署到生产环境之前，使用暂存环境来测试。
  • 安全集成。使用像Snyk这样的工具来监控你的应用程序的依赖性，以防止出现漏洞。
  • 快速部署回滚。使用一种部署策略，确保如果你的应用程序在部署后马上无法使用，你可以简单地选择你想恢复的最后一个版本，并立即回滚到该版本。由于该版本之前已经过测试，它不应该再一次经历管道阶段。你可以选择各种部署方法，如金丝雀推出、蓝色/绿色部署等。
  • 快速热修复发布。一些生产中的错误可能需要你绕过测试等管道阶段来提交和推送修复。虽然有风险，但你需要配置你的管道，使其支持在几秒钟内部署一个热修复。
  • GitOps实践。随着你的软件规模的扩大，你应该采用GitOpspractices- Git来控制和管理你的基础设施和应用配置。

总结

在产品开发的早期阶段，当你与时间赛跑来发布产品更新时，你可能会被诱惑推迟CI/CD管道的自动化。虽然向客户发送新功能是首要任务，但采取小步骤建立一个持续的CI/CD管道将帮助你更快、更可靠地发布功能。

  • 一次只做一个步骤的自动化。不要试图在第一天就建立一个成熟的管道。
  • 在其他任务之前将最重复的任务自动化，如部署回滚之前的构建步骤。
  • 选择能解决你当前需求的工具，快速上手，并且不锁定你，这样你就能在扩展时轻松修改你的管道。

CI/CD 应用 管线（软件）

经Priyanshu Chhazed许可发表于DZone。在此查看原文。

avatar
文章
阅读
粉丝