作为 Web 开发人员 (DevOps)，您需要了解的有关 CI/CD 的所有信息

DevOps、CI 和 CD 代表什么？

我在其他文章中写了一些关于这个的内容，但今天我将发布一篇关于这个 DevOps 任务的更详细、更具描述性和更循序渐进的文章。

DevOps、CI 和 CD 代表什么？

DevOps

DevOps 是“开发与运维”（Development Operations）的缩写。
它是一套结合软件开发 (Dev) 和 IT 运维 (Ops) 的实践。它旨在缩短系统开发生命周期，并提供高质量软件的持续交付。

IT 性能可以通过吞吐量和稳定性来衡量。吞吐量可以通过部署频率和变更前置时间来衡量；稳定性可以通过平均恢复时间来衡量。《DevOps 现状报告》发现，投资于能够提高吞吐量和稳定性的实践可以提升 IT 性能。

DevOps 的目标涵盖整个交付流程。其中包括：

• 提高部署频率
• 更快上市
• 新产品的失败率较低
• 缩短修复之间的准备时间
• 更快的平均恢复时间（如果新版本崩溃或以其他方式禁用当前系统）。

使用 DevOps 方法，简单的流程将变得更加可编程且动态化。DevOps 旨在最大限度地提高运营流程的可预测性、效率、安全性和可维护性。自动化通常能够支持这一目标。

DevOps 集成针对产品交付、持续测试、质量测试、功能开发和维护版本，以提高可靠性和安全性并提供更快的开发和部署周期。

与部署频率相关的实践包括：

• 持续交付
• 对所有生产工件使用版本控制

与变更准备时间相关的做法有：

• 对所有生产工件使用版本控制
• 自动化测试

与平均恢复时间相关的做法有：

• 对所有生产工件使用版本控制
• 监控系统和应用程序健康状况

虽然 DevOps 描述的是一种工作方法而不是一个独特的角色（如系统管理员），但招聘广告越来越多地使用“DevOps 工程师”这样的术语。

虽然不存在有关“DevOps 工程”的任何证书或头衔，但事实上任何开发人员都可以并且应该知道如何实施、测试和提供 DevOps 流程的一部分，至少是我们所参与的部分。

如果您对此一无所知，并且您申请了一家在整个开发过程中实施 DevOps 的公司，那么这可能会导致文化冲击，并对事物的工作原理和工作原理产生很大的误解。

我不会在这篇文章中深入探讨诸如 IaC（基础设施即代码）、容器化、业务流程编排或软件度量之类的术语，因为每个概念都需要一篇完整的文章来详细阐述，而本文的目的并非如此。您可以搜索这些概念来了解它们的含义，但目前您不需要了解更多。

持续集成

在软件工程中，持续集成 (CI) 是每天多次将所有开发人员的工作副本合并到共享主线的实践。

*没有必要每天多次，但当合理需要时即可。

着手进行更改时，开发人员会获取当前代码库的副本以供使用。随着其他开发人员将更改的代码提交到源代码存储库，此副本逐渐不再反映存储库代码。不仅现有代码库可能会更改，而且新代码、新库以及其他可能产生依赖关系和潜在冲突的资源也可能被添加。

开发在分支上持续的时间越长而未合并回主线，最终合并回开发者分支时出现多个集成冲突和故障的风险就越大。当开发者向代码库提交代码时，他们必须首先更新代码，以反映自他们复制代码以来代码库中的更改。代码库包含的更改越多，开发者在提交自己的更改之前必须完成的工作就越多。

最终，存储库可能会变得与开发人员的基线有很大不同，以至于他们进入有时被称为“合并地狱”或“集成地狱”的境地，其中集成所需的时间超过了进行原始更改所需的时间。

正如您应该注意到的，它是关于将所有开发人员的工作合并到存储库，并通常将其部署到测试机器（通常称为预生产或测试环境）中，以测试合并在一起的不同更改以寻找可能的错误。

实现这个 CI 天堂有两种方法。在我看来，最好的方法是将 Develop 分支合并到我的功能分支中，这样我就可以在本地测试我的更改。然后，当功能完成后，我可以轻松地将我的功能分支合并到 Develop 分支，并创建从 Develop 分支到 Master 分支的合并请求。

这样做的原因是，我突然需要做一些语义上不属于热修复的小改动。如果我多次将一个未完成的功能推送到开发分支，可能会阻碍我将其部署到生产环境中。这会导致其他团队成员使用热修复来修复那些并非热修复的功能，或者花费大量时间注释我的功能，而这并不理想（我需要稍后修复合并，并在拉取更改时取消注释）。

持续交付

持续交付 (CD) 是一种软件工程方法，团队在短周期内开发软件，确保软件能够随时可靠地发布，并且在发布软件时手动执行。它旨在以更快的速度和更高的频率构建、测试和发布软件。该方法允许对生产环境中的应用程序进行更多增量更新，从而有助于降低交付变更的成本、时间和风险。简单且可重复的部署流程对于持续交付至关重要。

CD 与持续部署形成对比，持续部署是一种类似的方法，其中软件也是在短周期内生产的，但通过自动部署而不是手动部署。

您需要根据项目情况选择其中一种。如果您在部署过程中进行自动化测试，则可能需要使用持续部署；相反，如果您需要手动测试更改，则需要执行持续交付。

采取这种做法的原因很容易理解。如果你一次性部署大量变更，你的应用程序交付给客户的时间跨度会更大，所有变更的测试将会非常困难。

如果您在短周期内交付变更，则需要测试的变更很少，并且客户将很快收到更新。

一步步轻松实现 CI/CD

您应该了解的第一个概念是 CI/CD（或 DevOps）是一种工作方式，而不是您专门通过 APP 执行的操作。

我假设您已经使用了像 Git 这样的 VCS（版本控制系统），并且您已经正确地测试了您的更改（单元测试、端到端，或者如果应用程序由于某种原因不支持自动化测试，则从测试或 QA 部门手动进行）。

DevOps 的第一个变化来自于 git 的使用：你需要正确使用 Git 和 Git Flow。如果你对此一无所知或了解甚少，可以查看本教程。

正确使用 gitflow 将使您将更改正确地集成到存储库中。

此时，您只需要一个 CI/CD 脚本来自动化应用程序上所有可自动化的任务。
假设您正在从头开始构建一个 Web 应用，并希望将以下工作流添加到其中。

它是如何工作的？

持续集成的工作原理是将小代码块推送到 Git 存储库中托管的应用程序代码库，并且每次推送时，都会运行脚本管道来构建、测试和验证代码更改，然后再将它们合并到主分支中。

持续交付和部署包括进一步的 CI，每次推送到存储库的默认分支时都会将应用程序部署到生产环境中。

这些方法允许您在开发周期的早期发现错误和错误，确保部署到生产的所有代码都符合您为应用程序建立的代码标准。

脚本，一步一步

我使用 GitLab 作为主存储库，但此脚本应适用于所有 git 存储库；在 GitLab 上，此脚本必须命名为 .gitlab-ci.yml（您需要根据所选存储库重命名它）。

简单脚本：

阶段：
  - 部署

部署：
  阶段：部署
  图片：debian:stretch-slim
  仅有的：
    - 掌握

  脚本：
    - apt-get update && apt install -y --no-install-recommends lftp
    - lftp -e “设置 ftp：ssl-allow 否；设置 ssl：verify-certificate 否；镜像 -R ./ “$REMOTE_ROUTE -p 21 -u $USER，$PSWD $HOST

*大写字母前面带有美元符号，是您可以在存储库配置/首选项中设置的变量。

这将生成一个包含您的代码的 docker 镜像，在该 docker 镜像内执行一些操作，然后该 docker 镜像将被销毁，所有操作均“即时”完成。

逐行执行：
我们在阶段列表中添加一个名为 deploy 的阶段，然后使用 Docker 镜像 debian:stretch-slim 定义此 deploy 阶段。
该阶段仅在合并/推送到 Master 分支时触发。
然后，我们定义在 deploy 阶段的此时运行的脚本。

在这种情况下，它将简单地执行更新和升级（-y = 假设所有问题的答案都是肯定的），然后我们需要安装 lfpt，最后它将使用 lftp 通过 FTP 将存储库内容（./）移动到服务器所需的目录 ($REMOTE_ROUTE)（此服务器目录将是给定域的根目录）。

这可以是持续部署，因为每次将代码推送到主分支时它都会触发。

如果我们阻止推送到主分支，添加一个阶段，从开发分支（而不是主分支）获取代码，并将代码交付到测试机器，那么也可以实现持续交付。然后，我们需要手动执行合并到主分支的操作​​，才能运行部署到生产环境的流水线。

我们首先要做的就是增加安全性。这是一个普通的 FTP 传输，可以轻松转换为基于 SSL 的 FTP（FTPs）传输。

阶段：
  - 部署

部署：
  阶段：部署
  图片：debian:stretch-slim
  仅有的：
    - 掌握

  脚本：
    - apt-get update && apt install -y --no-install-recommends lftp
    - lftp -e “设置 ftp：ssl-protect-data true；设置 ftp：ssl-force true；设置 ssl：verify-certificate no；设置 ftp：ssl-allow no；mirror -R ./ “$REMOTE_ROUTE -p 21 -u $API_USER,$API_PSWD $HOST

现在我们添加了 ftp：ssl-protect-data true；设置 ftp：ssl-force true；因此它将通过 SSL 运行（必须安装在目标机器上）。

执行此操作的最佳方法是使用 SSH，但我有一个共享主机，用于空闲时间，所以无法通过终端访问它。我目前能做的最好的就是使用基于 SSL 的 FTP，不使用 SFTP，也不使用 SSH（两者都需要使用终端/控制台，无论是本地还是远程，而且在共享主机上你无法访问它）。

好的，现在我们已经使用 SSL 证书保护了此文件交易加密过程，现在...还有什么？

添加作业：

想象一下，我在存储库根目录中有一个名为 app/ 的文件夹，其中我有一个 react/angular/svelte/preact（无论什么）项目，或者只是一堆用于前端的纯 html、css 和 js 文件。

如今，使用打包工具（webpack、rollup、parcel 等等）已经很常见了。—— 这次我使用的是我最喜欢的 parcel ——

您可以将 dist/ 文件夹（捆绑器的输出）添加到您的存储库，以便您可以将 dist/ 文件夹直接从存储库移动到生产文件夹：

阶段：
  - 部署

部署：
  阶段：部署
  图片：debian:stretch-slim
  仅有的：
    - 掌握

  脚本：
    - apt-get update && apt install -y --no-install-recommends lftp
    - lftp -e “设置 ftp：ssl-protect-data true；设置 ftp：ssl-force true；设置 ssl：verify-certificate no；设置 ftp：ssl-allow no；mirror -R ./app/dist/”$REMOTE_ROUTE -p 21 -u $API_USER,$API_PSWD $HOST

这是一个不好的做法。毕竟，这是对原始代码进行转译/编译的结果。

我们可以通过在部署过程中简单地在这台升起的机器内执行构建来解决这个问题，如下所示：

阶段：
  - 部署

部署：
  阶段：部署
  图片：debian:stretch-slim
  仅有的：
    - 掌握

  脚本：
    - apt-get update && apt install -y --no-install-recommends lftp
    -cd./应用程序/
    -apt-get 安装 -y gnupg2
    -apt-get 安装 curl -y
    -apt-get 安装 apt-transport-https ca-证书
    - curl -sL https://deb.nodesource.com/setup_12.x | bash -
    -apt-get 安装 nodejs -y
    - curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key 添加 -
    - 回显“deb https://dl.yarnpkg.com/debian/stable main”| tee /etc/apt/sources.list.d/yarn.list
    - apt 更新 && apt 安装 yarn -y
    -纱线安装
    - 纱线生产
    - lftp -e “设置 ftp：ssl-protect-data true；设置 ftp：ssl-force true；设置 ssl：verify-certificate no；设置 ftp：ssl-allow no；mirror -R ./dist/ “$REMOTE_ROUTE -p 21 -u $USER,$PSWD $HOST

• 我正在使用 yarn，但您可以将其更改为 npm、npx 或您最喜欢的包管理器。

哇，它长得真快，是吧？

首先，我进入 app/ 目录，也就是我的前端应用所在的地方。然后，我安装依赖项以及依赖项的依赖项，以便可以执行yarn install和yarn build-prod命令。

yarn（或 npm 或..）安装将读取应用程序文件夹内的 package.json，下载并安装其上指定的依赖项，然后生成 node_modules

yarn build-prod 是一个自定义脚本，它使用 parcel 来捆绑我的应用程序，细节在这个上下文中并不重要，你需要知道的是，这会在 app/ 中生成一个 dist/ 文件夹，其中包含用于生产的前端​​代码（ofuscated、minified 等）。

最后（记住我们在 ./app/ 目录中）我将 dist/ 文件夹的内容推送到 $REMOTE_ROUTE，即生产根目录。

• 避免将 dist/ 文件夹推送到存储库
• 避免将 node_modules 推送到存储库（永远不要将 node_modules 文件夹推送到存储库！没有借口，不要这样做，永远不要。）
• 每次将一些代码推送或合并到 Git Master 分支时，自动执行部署过程
• 如果某个进程失败（例如，因为我们添加了新的依赖项，但没有在 package.json 中说明），它将抛出错误并取消该进程，因此我们增加了可靠性

如您所见，您可以在流程中添加 Linux 命令。

您需要记住，所有命令都将以 root 身份执行，因此请避免在命令中使用 sudo。您还需要跳过进程内的用户交互（例如，在 apt-get install 命令中添加 -y 修饰符将自动假定所有问题的答案均​​为“是”），否则进程将失败（您无法与进程交互，因为它是自动化的）。

管道上的自动化测试：

然后，您可以在此过程中为测试添加触发器，它可能会因您用于测试的工具（Cypress，Selenium，Protractor......）而有很大差异，每个工具都会有一些关于将测试添加到 CI 管道的文档，例如Cypress CI 文档。

我无法添加所有示例，因为基本上我没有使用过所有示例，而且对于大家来说，这些示例对于通用目的来说用处不大。如果您目前已经有了一个可以运行的流水线，请阅读您的测试工具文档中关于 CI 流水线的内容，因为有很多针对不同技术、语言和方法的工具，我无法在这里一一介绍。

将测试添加到您的管道中并添加另一个阶段以将开发部署到预生产/测试环境中将完成您的脚本。

如果出现故障，您将在部署之前获得带有可见日志的自动化测试，并且您的 CI CD 管道将正确完成。

监控

此时唯一能持续的就是监控。

当您在各种环境中部署新版本的代码时，监控功能可以实时监控应用的运行情况。在流程早期发现问题，使团队能够快速解决问题，并继续测试和监控后续更改。

有很多工具可用于此目的，其中一些是 Datadog、Nagios、Zabbix、Sensu、Prometheus、SysDig……

每个人都有不同的工作方法并提供不同的工具（不仅用于监控您的应用程序，还用于监控服务器状态，数据图等），因此您需要深入挖掘才能知道哪一个最适合您。

出于我在测试中提到的同样原因，我无法在此详细介绍监控。此外，监控工具并非集成在此流水线流程中，而是在您的服务器上安装、配置和维护的。除了您的应用程序和数据监控需求外，您所使用的工具也会因您的平台（云服务器、专用服务器、VPS（虚拟专用服务器）、共享主机……）而异。

用法

如果您在任何现代公司（或拥有现代软件的老公司）申请工作，他们通常会使用这样的流程（根据他们使用的技术，它可能有很大差异，但基础和流程基本相同：计划、代码、构建、测试、发布、部署、操作、监控并一遍又一遍地重复）。

您可以在部署阶段找到后端命令，例如，如果您将 Laravel 与 PHP 结合使用，则可以找到一些 artisan 命令。您还可以找到一些不同的前端命令，这些命令使用另一个带有不同捆绑器或自定义脚本的包管理器。
您还可以找到与我没有解释的概念的集成，例如业务流程或测量。
您还可以在无服务器环境中找到带有一些 lambda 函数的 CI CD 管道，或者将 Kubernetes 与 jenkins 或 azure 结合使用。由于存在大量可能性，我尝试涵盖一个几乎可以用于所有项目的用例，并且可以在家中以很少的成本重现（我使用的共享主机每月约为 4.95 美元，按年计费有折扣等（转到 Web 托管查看共享主机计划）。我可以推荐它，因为它易于操作，并且包含一个 CPanel，可以使很多事情变得更容易，因此您可以玩耍和学习。

但是所有这些可能的集成都是脚本内部的步骤，在推动部署之前，或者是为了特定目的在管道流程的特定行上抛出的 SSH 命令。您可能无法在您的系统上运行适当的监控工具，并且您可能不需要编排工具，因为这些概念适用于大型应用程序，或者至少适用于云或专用服务器（您也可以在 VPS 上配置它们）所以如果您正在学习，您可能不想每年花费大约 300 美元来购买低性能的 VPS。如果您即将创建一家初创公司，那么您将需要关注这一点并获得一台带有监控功能的适当服务器，此外，编排工具仅在您的架构需要它时才适合，并非总是如此。

希望它能帮助您理解整个过程，如果您有任何疑问，请不要害羞在评论部分问我:)

此致，

乔尔

你喜欢我的内容吗？☕请我喝杯咖啡