如何使用持续部署自动化项目版本控制和发布

拥有一个 语义化版本 的软件将有助于您轻松维护和沟通软件中的更改。但这并不容易。即使在手动合并 PR、标记提交和推送发布之后，您仍然需要编写发布说明。这里有很多不同的步骤，而且许多步骤是重复且耗时的。

让我们看看如何通过将语义版本控制插件到持续部署流程中，使流程更加高效，并**完全自动化我们的发布流程**。

语义版本控制

语义版本是一个由三个数字组成的数字，数字之间用点号隔开。例如，1.4.10 是一个语义版本。每个数字都有特定的含义。

将语义版本控制视为 破坏性 . 功能 . 修复 更加容易。它是一种更精确的方式来描述版本号，不会留下任何解释的空间。

提交格式

为了确保我们发布了正确的版本（通过正确地递增语义版本号），我们需要标准化我们的提交消息。通过对提交消息使用标准化格式，我们可以知道何时递增哪个数字，并轻松生成发布说明。我们将使用 Angular 提交消息约定，尽管之后如果您喜欢其他约定，我们可以进行更改。

格式如下

<header>
<optional body>
<optional footer>

每个提交消息都包含一个**标题**、一个**正文**和一个**脚注**。

提交标题

标题是必需的。它有一个特殊格式，包括一个**类型**、一个可选的**范围**和一个**主题**。

标题的**类型**是一个必需的字段，用于说明提交内容对下一个版本的影响。它必须是以下类型之一：

• feat: 新功能
• fix: 错误修复
• docs: 文档更改
• style: 不影响代码含义的更改（例如空格、格式、缺少分号等）
• refactor: 不修复错误也不添加功能的更改
• perf: 提高性能的更改
• test: 添加缺失的测试或对现有测试的更正
• chore: 对构建过程或辅助工具和库的更改，例如生成文档

范围是一个分组属性，指定提交所相关的子系统，例如 API、应用程序的仪表板、用户帐户等。如果提交修改了多个子系统，则可以使用星号 (*) 来代替。

标题**主题**应该包含对所做更改的简短描述。编写主题时有几个规则：

• 使用祈使句，现在时态（例如“更改”而不是“已更改”或“更改”）。
• 第一个单词的首字母小写。
• 结尾不要加句号 (.) 。
• 避免编写超过 80 个字符的主题提交正文。

与标题主题一样，正文使用祈使句，现在时态。它应该包括更改的动机，并将其与以前的行为进行对比。

提交脚注

脚注应包含有关**破坏性更改**的任何信息，也是引用此提交关闭的问题的地方。

破坏性更改信息应以 BREAKING CHANGE: 开头，后跟一个空格或两个换行符。提交消息的其余部分在此处。

强制执行提交格式

当您必须标准化团队中的每个人都必须遵守的任何内容时，团队合作始终是一个挑战。为了确保每个人都使用相同的提交标准，我们将使用 Commitizen。

Commitizen 是一个命令行工具，它使使用一致的提交格式变得更容易。使存储库 支持 Commitizen 意味着团队中的任何人都可以运行 git cz，并获得详细的提示以填写提交消息。

生成发布

既然我们知道我们的提交遵循一致的标准，我们就可以开始生成发布和发布说明了。为此，我们将使用一个名为 semantic-release 的软件包。它是一个维护良好的软件包，对多个 持续集成 (CI) 平台提供了很好的支持。

semantic-release 是我们旅程的关键，因为它将执行发布的所有必要步骤，包括：

1. 确定您发布的最后一个版本
2. 根据自上次发布以来添加的提交来确定发布类型
3. 为自上次发布以来添加的提交生成发布说明
4. 更新 package.json 文件，并创建一个与新发布版本相对应的 Git 标签
5. 推送新发布

任何 CI 都可以。在本文中，我们将使用 GitHub Action，因为我喜欢在使用第三方解决方案之前使用平台现有的功能。

有多种 安装 semantic-release 的方法，但我们将使用 semantic-release-cli，因为它提供了逐步操作。在终端中运行 npx semantic-release-cli setup，然后填写交互式向导。

该脚本将执行以下操作：

• 它使用提供的 NPM 信息运行 npm adduser，以生成 .npmrc。
• 它创建一个 GitHub 个人令牌。
• 它更新 package.json。

CLI 完成后，它会将 semantic-release 添加到 package.json，但不会实际安装它。运行 npm install 以安装它以及其他项目依赖项。

剩下的唯一事情就是通过 GitHub Actions 配置 CI。我们需要手动添加一个工作流程，该工作流程将运行 semantic-release。让我们在 .github/workflows/release.yml 中创建一个发布工作流程。

name: Release
on:
  push:
    branches:
      - main
jobs:
  release:
    name: Release
    runs-on: ubuntu-18.04
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Setup Node.js
        uses: actions/setup-node@v1
        with:
          node-version: 12
      - name: Install dependencies
        run: npm ci
      - name: Release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        # If you need an NPM release, you can add the NPM_TOKEN
        #   NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
        run: npm run release

Steffen Brewersdorff 已经很好地介绍了 使用 GitHub Actions 进行 CI，但让我们简单地回顾一下这里发生了什么。

这将等待 main 分支上的推送操作，只有在推送操作发生后才会运行管道。您可以随意将其更改为在一个、两个或所有分支上运行。

on:
  push:
    branches:
      - main

然后，它使用 checkout 拉取存储库，并安装 Node，以便 npm 可用于安装项目依赖项。如果需要，可以进行测试步骤。

- name: Checkout
uses: actions/checkout@v2
- name: Setup Node.js
uses: actions/setup-node@v1
with:
    node-version: 12
- name: Install dependencies
run: npm ci
# You can add a test step here
# - name: Run Tests
# run: npm test

最后，让 semantic-release 完成所有神奇的操作

- name: Release
run: npm run release

推送更改并查看操作

现在，每次对指定分支进行提交（或合并）时，操作将运行并进行发布，并包含发布说明。

发布派对！

我们成功创建了 CI/CD 语义化发布工作流！是不是没那么痛苦？设置相对简单，而且使用语义化发布工作流没有弊端。它只是让跟踪更改更容易。

semantic-release 有很多插件，可以实现更高级的自动化。例如，甚至有一个 Slack 发布机器人，可以在项目成功部署后发布到项目频道。无需再前往 GitHub 寻找更新！