持续集成 (CI) 和持续部署 (CD) 是至关重要的开发实践，尤其对于团队而言。无论项目大小，每个项目都容易出错。但是，当设置了具有良好测试的 CI/CD 流程时，这些错误就更容易发现和修复。
在本文中，让我们了解如何检查测试覆盖率、设置使用 CircleCI 和 Coveralls 的 CI/CD 流程，并将 Vue 应用程序部署到 Heroku。即使您使用的工具组合并非如此，我们介绍的概念对您的设置中包含的任何内容仍然有用。例如，可以将 Vue 替换为其他 JavaScript 框架，基本原理仍然相关。
在我们开始之前，先了解一些术语
- 持续集成：这是一种实践，开发人员尽早且频繁地提交代码，在合并或部署之前将代码通过各种测试和构建流程。
- 持续部署：这是一种始终保持软件可部署到生产环境的实践。
- 测试覆盖率：这是用于描述软件测试程度的 指标。具有高覆盖率的程序意味着大多数代码都经过测试。
要充分利用本教程，您应该具备以下条件
- CircleCI 帐户：CircleCI 是一个 CI/CD 平台，我们将使用它进行自动部署（包括在部署之前测试和构建我们的应用程序）。
- GitHub 帐户：我们将项目及其测试存储在一个存储库中。
- Heroku 帐户：Heroku 是一个用于部署和扩展应用程序的平台。我们将使用它进行部署和托管。
- Coveralls 帐户：Coveralls 是一个用于记录和显示代码覆盖率的平台。
- NYC：这是一个我们将用来检查代码覆盖率的包。
包含本帖中介绍的示例的存储库 在 GitHub 上可用。
让我们开始设置
首先，让我们在项目文件夹中安装 NYC
npm i nyc接下来，我们需要编辑package.json中的脚本以检查测试覆盖率。如果我们试图在运行单元测试时检查覆盖率，则需要编辑测试脚本
"scripts": {
"test:unit": "nyc vue-cli-service test:unit",
},此命令假设我们使用 Vue 构建应用程序，其中包含对cue-cli-service的引用。该命令需要更改以反映项目中使用的框架。
如果我们要单独检查覆盖率，则需要在脚本中添加另一行
"scripts": {
"test:unit": "nyc vue-cli-service test:unit",
"coverage": "nyc npm run test:unit"
},现在，我们可以通过终端命令检查覆盖率
npm run coverage接下来，我们将安装 Coveralls，它负责报告和显示覆盖率
npm i coveralls现在，我们需要在package.json中添加 Coveralls 作为另一个脚本。此脚本可以帮助我们将测试覆盖率报告保存到 Coveralls。
"scripts": {
"test:unit": "nyc vue-cli-service test:unit",
"coverage": "nyc npm run test:unit",
"coveralls": "nyc report --reporter=text-lcov | coveralls"
},让我们转到 Heroku 仪表板并在那里注册我们的应用程序。Heroku 是我们用来托管它的工具。
我们将使用 CircleCI 来自动化我们的 CI/CD 流程。转到 CircleCI 仪表板以设置我们的项目。
我们可以通过 CircleCI 侧边栏中的项目选项卡导航到我们的项目，在那里我们应该会看到我们 GitHub 组织中的项目列表。单击“设置项目”按钮。这将带我们到一个新页面，在那里我们会询问我们是否要使用现有配置。我们确实有自己的配置，所以让我们选择“使用现有配置”选项。
之后，我们将被带到所选项目的管道。太棒了！我们已经完成了将我们的存储库连接到 CircleCI。现在，让我们将我们的环境变量添加到我们的 CircleCI 项目中。
要添加变量，我们需要导航到项目设置。
项目设置在侧边栏中有一个环境变量选项卡。这是我们要存储变量的地方。
本教程所需的变量是
您可以在 Heroku 仪表板的帐户部分找到 Heroku API 密钥。
Coveralls 存储库令牌位于存储库的 Coveralls 帐户中。首先，我们需要将存储库添加到 Coveralls，方法是从可用存储库列表中选择 GitHub 存储库。
现在我们已将存储库添加到 Coveralls。我们可以通过单击存储库来获取存储库令牌。
集成 CircleCI
我们已经将 Circle CI 连接到我们的 GitHub 存储库。这意味着 CircleCI 将在 GitHub 存储库中发生任何更改或操作时收到通知。我们现在要做的就是执行以下步骤，以告知 CircleCI 在检测到对存储库的更改后要执行的操作。
在本地项目的根文件夹中，让我们创建一个名为.circleci的文件夹，并在其中创建一个名为config.yml的文件。这是所有 CircleCI 操作的所在。
以下是该文件中包含的代码
version: 2.1
orbs:
node: circleci/[email protected] // node orb
heroku: circleci/[email protected] // heroku orb
coveralls: coveralls/[email protected] // coveralls orb
workflows:
heroku_deploy:
jobs:
- build
- heroku/deploy-via-git: # Use the pre-configured job
requires:
- build
filters:
branches:
only: master
jobs:
build:
docker:
- image: circleci/node:10.16.0
steps:
- checkout
- restore_cache:
key: dependency-cache-{{ checksum "package.json" }}
- run:
name: install-npm-dependencies
command: npm install
- save_cache:
key: dependency-cache-{{ checksum "package.json" }}
paths:
- ./node_modules
- run: # run tests
name: test
command: npm run test:unit
- run: # run code coverage report
name: code-coverage
command: npm run coveralls
- run: # run build
name: Build
command: npm run build
# - coveralls/upload这是一大块代码。让我们分解一下，以便我们知道它在做什么。
Orbs
orbs:
node: circleci/[email protected] // node orb
heroku: circleci/[email protected] // heroku orb
coveralls: coveralls/[email protected] // coveralls orbOrbs 是开源包，用于简化软件和包在不同项目中的集成。在我们的代码中，我们指示了我们用于 CI/CD 流程的 orbs。我们引用了node orb，因为我们使用了 JavaScript。我们引用了heroku，因为我们使用 Heroku 工作流程进行自动部署。最后，我们引用了coveralls orb，因为我们计划将覆盖率结果发送到 Coveralls。
Heroku 和 Coverall orbs 是外部 orbs。因此，如果我们现在通过测试运行应用程序，这些操作会触发错误。要消除错误，我们需要导航到 CircleCI 帐户中的“组织设置”页面。
然后，让我们导航到安全选项卡并允许未经认证的 orbs
工作流程
workflows:
heroku_deploy:
jobs:
- build
- heroku/deploy-via-git: # Use the pre-configured job
requires:
- build
filters:
branches:
only: master一个 工作流程 用于定义作业集合并按顺序运行它们。这部分代码负责自动托管。它告诉 CircleCI 构建项目，然后部署。requires 表示heroku/deploy-via-git作业需要构建完成，这意味着它将等待构建完成才能部署。
作业
jobs:
build:
docker:
- image: circleci/node:10.16.0
steps:
- checkout
- restore_cache:
key: dependency-cache-{{ checksum "package.json" }}
- run:
name: install-npm-dependencies
command: npm install
- save_cache:
key: dependency-cache-{{ checksum "package.json" }}
paths:
- ./node_modules作业是步骤的集合。在这部分代码中，我们通过restore_cache作业还原了在之前的构建中安装的依赖项。
之后，我们安装了未缓存的依赖项，然后保存它们，这样它们就不需要在下次构建期间重新安装。
然后，我们告诉 CircleCI 运行我们为项目编写的测试并检查项目的测试覆盖率。请注意，缓存依赖项可以使后续构建更快，因为我们存储了依赖项，因此无需在下次构建期间安装这些依赖项。
将我们的代码覆盖率上传到 Coveralls
- run: # run tests
name: test
command: npm run test:unit
- run: # run code coverage report
name: code-coverage
command: npm run coveralls
# - coveralls/upload这是 Coveralls 魔术发生的地方，因为这是我们实际运行单元测试的地方。还记得我们在package.json文件中将nyc命令添加到test:unit脚本中吗？感谢这一点，单元测试现在提供了代码覆盖率。
单元测试也提供代码覆盖率，因此我们将在覆盖率报告中包含这些测试。这就是我们在此处调用该命令的原因。
最后，代码运行了我们在package.json中添加的 Coveralls 脚本。此脚本将我们的覆盖率报告发送到 Coveralls。
您可能已经注意到coveralls/upload行已注释掉。这本应是该过程的结束字符，但在最后它变成了开发人员术语中的一个阻碍因素或错误。我将其注释掉了，因为它可能是另一个开发人员的王牌。
整合所有内容
Behold 我们的应用程序，它集成了持续集成和部署功能！
持续集成和部署在很多情况下都很有帮助。一个常见的例子是在软件测试阶段。在这个阶段，会进行大量的提交以进行各种修正。作为一名开发者，我最不想做的事情就是在每次微小更改后手动运行测试并手动部署应用程序。Ughhh。我讨厌重复！
我不知道你是什么想法，但 CI 和 CD 是我了解过一段时间的东西，但我总是找到方法将它们搁置一边，因为它们听起来要么太难要么太耗时。但现在你已经看到了它们的设置相对简单，以及随之带来的好处，希望你能受到鼓舞，并准备好在你自己的项目中尝试一下。