非运维专属，开发人员的 CI/CD 使用指南

好像 DevOps 的定义还不够复杂似的，它经常与它的误解小伙伴一起被人挂在嘴边：持续集成、持续交付和持续部署。就像一个古老的皇帝，需要一位演说家记住和讲出他的头衔/名字，滑稽的是，CI/CD/CD 总是被人一起提及。你可以参与到这样的对话中，但是一旦你将话题转到持续集成、持续交付和持续部署，你就会连续不断地说出这么一大长串，让每个人(包括你自己)都很恼火。或者在 AWS 这样的环境中你可以简称它为 CI/CD/CD，初级和非技术人员都会认为你是某种字母表专家。

不仅这个“东西”的名字令人困惑，而且它的定义也是模棱两可。如果你问管理者，他们会告诉你如何为客户创造价值。如果你问开发人员，他们会开始滔滔不绝地说一些工具、流程和代码。如果你问营销人员，他们会告诉你，这是解决组织中所有问题的方法。如果你问销售人员，他们会告诉你节省的时间、指标和公司的潜在收益。如果你问敏捷教练，他们可能会让你更加困惑，大喊 CI 不是 CD, 这个 CD 不是……那个 CD。

“哪个 CD ？”

“别担心。事实上，就叫它 CI/CD 吧。”

“那这个 CD 是持续交付的 CD 还是持续部署的 CD（Continuous Delivery or Deployment）？”

“依赖于具体情况（Depends）吧。”

“持续依赖（Continuous Depends）？”【译注：此处保留原文，请读者体会原文的小趣味】

“打扰了，告辞”

那么，当我们的英雄战队肩负起执行这个神秘过程的任务时，我们该从哪里着手呢？

一个实用的定义

当我第一次尝试解决这个问题时，看了一些系列视频，在里面有一个 CTO，他试图解释持续集成、持续交付和持续部署。其中有一半是图表/线条，另一半是他完全不停地在叨叨 CI/CD 这个咒语。到最后，我觉得他就是想轻松地赚这份钱。

为了节省开发人员的时间和挫折感，让我给出了一个持续集成、持续交付和持续部署(CI/CD)的实用定义：

CI/CD 有一个半自动到全自动的过程，凭此过程在旧代码中安全地添加新代码并将其发布给用户。

对，没错，我们可以在这个锅里放入各种定义、切面和敏捷宣言的引用，就像你可以在鸡肉面汤里倒入橙汁一样。但是我们不会。为什么？因为从开发人员的角度来看，这就是你在日常实现要做的事情。

“我有我当前的代码。我想安全地添加(删除)一些新代码。我希望部署这些新变更。我希望这件事尽可能自动地完成。”

这个定义使你更加专注于它本身。事实上，有了它，我敢打赌你能想出各种可能的方法来实现它。

一些实用的目标

好的，我们找到了一个合适的关注点。然而，在构建你的第一个“CI/CD 流水线”时，它涉及到将代码从本地迁移到部署时的所有事情，你需要记住三个主要目标。我们可以方便地使用 CI/CD/CD 三重唱来对这些目标进行分类。我们将把它们作为你在构建自己的 CI/CD 流水线时可以问自己的问题：

1. 为了确保来自多个开发人员的新代码可以安全地添加到现有代码中，需要做些什么？(又名持续集成)

考虑一下测试、版本控制、代码评审和构建。

2. 为了确保我们的代码库可以在任何时候发布到我们的生产环境中，需要做些什么？(又名持续交付)

考虑一下质量保证(QA)测试、产品经理评审、用户测试和反馈，以及各种测试代码的环境(例如，部署到开发或准生产环境中，在发布之前测试所有内容)。

3.需要做什么才能使我们的代码在更新时自动部署？(又名持续部署)

设想一下脚本和流程，它们将监控代码库中的 Git 分支，并在更改和批准之后自动部署它。

现在，如果你感到有点不知所措，可能是因为这些目标在上午九点从一个雄心勃勃的经理嘴里说出来时显得很宏伟，它们不是条例……它们是目标。完成之后，每个组织和团队看上去都会有些不同。例如，如果你是个一人军团，你的 CI/CD 流水线可能是这样的:

a)有一个 github 代码库(持续集成)

b)在合并新代码之前，运行单元测试(持续集成)

c)将新代码部署到准生产环境(已部署了模拟生产环境的基础设施)，并确保其运转正常(持续交付)

d)如果©通过，将新代码合并到主分支中，并将其自动部署到生产环境中(持续部署)

然而，如果你是一个拥有更多部署和测试需求的大型团队，那么你的 CI/CD 流水线将包含更多的步骤和细节。但是首要的、最终的目标还是一样的：

有一个半自动到全自动的过程，凭此过程在旧代码中安全地添加新代码并将其发布给用户。

一个实用的方法

“定义和目标都很好，但是我从哪里开始呢？”

即使我们已经对定义和目标有了更清晰的认识，那么如何坐下来真正做到这一点呢？首先，我假设你有某种代码库(软件)，你在本地开发代码，并最终部署到某个地方供用户使用。第二，让我问你一个问题：

你目前采取哪些步骤将代码库从本地机器发布到生产基础设施或托管解决方案？

按照以下步骤来回答上面的问题:

1. 列出将代码从本地发布到生产环境所需的所有步骤。

把这个列表写下来，就好像你要手动去做一样。“我会对它进行测试。然后我再让人评审一下。然后我们再合并它。”等等等等。

2. 基于这个列表，哪些步骤可以自动化？

像代码评审这样的事情是不能自动化的，但是运行你的测试套件或者将它部署到你的基础设施上是可以自动化的。

3.有了可以自动化的步骤，你需要编写什么脚本，或者你可以使用什么工具来自动化它们？

例如，你可能有一个命令一览表，其中列出了你需要运行的所有命令，以使你的代码库在你的主机或 IaaS 服务上运行。这将是一条候选的可以脚本化的工作流。

你明白我们要怎么做了吗？完成了上述 3 个步骤之后，你就有了构建持续集成、持续交付和持续部署流水线所需的所有工作的列表。现在你可以开始干起来了，看着你的业务经理像素材图片里的模特一样面露微笑！

那么 CI/CD 服务呢？

“但是科尔，你觉得 Jenkins / CircleCI / TravisCI / SemphoreCI 等等怎么样？”如果我们不邀请他们，他们会知道的……”

确实。事情是这样的，与流行的观点相反，你不需要任何这些来建立 CI/CD。如果你已经完成了上面的列表，它主要包括什么？脚本。所以你真正需要的是运行这些脚本所需的那些东西。

对于大多数人来说，这将是一台远程服务器。它不受任何开发人员本地主机精神负担的束缚。它具有足够的权限和足够的软件来完成你所编写的所有自动化操作。

…如果你以前曾经将任何应用程序部署到远程服务器，那么你就已经完成这件事了。你已经准备好了一台服务器，给它足够的东西来运行你的应用程序代码，然后让互联网/内部用户访问你的服务器和应用程序。搭建一台“CI/CD 服务器”几乎是一样的。主要的区别是:

1.运行脚本所需的依赖项。

2.CI/CD 服务器获取你的代码库所需的的访问/权限。

3.CI/CD 服务器将代码库部署到生产基础设施或托管解决方案所需的访问/权限。

在某种意义上，你拥有一个全新的应用程序要处理、开发、扩展和部署。这正是第三方 CI/CD 服务和解决方案开始发挥作用的地方。他们把这个过程从你的工作中抽象出来，让你只专注于写那些自动化脚本。通常要用他们自己的语言或语法。

然而，它确实可以像搭建另一个服务器来执行上述步骤一样简单。我之所以提出这个问题，是因为在讨论 CI/CD 时，人们往往会直接跳到第三方解决方案。虽然我相信对于 90%的团队来说，使用这些是正确的方向，但是首先讨论它们可能会让人注意不到 CI/CD 是多么简单。人们将首先选择一个工具，然后将他们的方形 CI/CD 需求放入工具的圆形功能中，而不是弄清楚需要做什么。

也就是说，如果你确实知道需要脚本化和自动化哪些内容，那么选择 CI/CD 服务或解决方案就会变得容易得多。你想要自己掌控它吗？你喜欢它们的语言或语法吗？他们的文件是“垃圾箱火灾”吗？【译注：指的是某人、某个机构、或某种情况处于绝望境地，或者处于灾难性的失控状态。】你要了解全局。

知易、行难

那么，如果这一概念如此容易，为什么实施起来会相当困难呢？嗯，在我们当前的 DevOps 生态系统中，这是一个技能反馈周期。不像开发，你改完之后可以立即知道它是否正常运转，而 DevOps 系统(即 CI/CD 流水线)则需要几分钟到一个小时的时间来查看你所做的是否正确。最重要的是，你经常在本地机器之外测试这些基础设施……这意味着学习是要付出代价的。

例如，假设你已经了一批服务器来处理 CI/CD。假设你的自动化工作流应该测试你的代码库并将其部署到一系列准生产、开发或生产服务器上。好，为了确保事情是准确的，你可能会在实际的基础设施中进行测试。此外，如果其中一项服务器配置是坏的怎么办？现在，你必须深入到服务器中，更改它们的配置，可能还要重新启动它们，然后等待，看看新做的修复是否有效。如果你需要 5 到 10 分钟来完成和部署这个变更，而且你在正常运行之前你还得必须进行 50 到 100 次变更的话……

但是，当第一个蜿蜒绵长的自动化系统平稳运行时，你会有什么感觉？无可比拟。看着你的团队对代码进行一些更改，将其向上推送到版本控制、检查、合并并自动部署，这些事多么值得关注呀。尽管构建这些系统的过程很长，但它极大地缩短了开发人员、业务人员和用户之间的反馈周期。

什么是持续集成、持续交付和持续部署(CI/CD)？

“嗯，持续集成、持续交付和持续部署让我们通过持续地集成和部署新功能不断地向我们的关键涉众交付价值。”

“现在回答这个问题时，不要使用持续、集成、交付、部署这些词，以及它们的任何同义词。”

“嗯……它，嗯，帮助我们帮助我们的利益相关者……我的意思是，更多的时候。”

“那么…你能详细说说吗？”

“嗯……pull requests？”

这种做法的定义很难弄得很明确。我认为这主要是许多不同学科参与其中的结果。管理者、营销人员、销售人员、开发人员、运维、产品。很多人在这条流水线中都插了一手，对他们每个人来说，它意味着日常工作中有些事有了不同。

但是在想出需要做什么工作以及这些工作是如何实际结合在一起的时候？同样，它也很简单，CI/CD 有一个半自动到全自动的过程，凭此过程在旧代码中安全地添加新代码并将其发布给用户。

作者介绍：

J Cole Morrison，云架构师，软件工程师，前 Techstars Hackstar, AWS 解决方案架构师，awsdevops.io 创始人。

原文链接：

A Practical Approach to CI/CD for Developers