如何通过连续部署自动化项目版本并发布

采用语义化版本控制能更轻松地维护和沟通软件变更，但手动操作却很繁琐。即使手动合并PR、标记提交并推送发布，仍然需要编写发布说明。步骤众多，且重复性高，耗时费力。

本文将介绍如何通过将语义化版本控制集成到持续部署流程中，实现更高效的流程并完全自动化发布流程。

语义化版本控制

语义化版本是一个由三个数字组成的版本号，例如 1.4.10。每个数字都有特定的含义：

主要版本变更 (Major)

第一个数字表示主要版本变更，意味着存在破坏性变更。

次要版本变更 (Minor)

第二个数字表示次要版本变更，意味着添加了新功能。

修补版本变更 (Patch)

第三个数字表示修补版本变更，意味着修复了bug。

可以将语义化版本更简洁地理解为：破坏性变更.功能变更.错误修复。这种描述方式更精确，避免歧义。

提交信息格式

为了确保正确递增语义化版本号并发布正确版本，需要标准化提交信息格式。标准化的提交信息格式有助于确定何时递增哪个数字，并轻松生成发布说明。这里将使用 Angular 提交信息约定，当然也可以根据需要更改。

格式如下：

<code></code>

每个提交信息包含标题、正文和脚注。

提交标题

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

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

• feat: 新功能
• fix: bug 修复
• docs: 文档变更
• style: 不影响代码含义的变更（例如：空格、格式、缺少分号等）
• refactor: 代码重构，既不修复bug也不添加功能
• 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 中创建一个发布工作流程。

<code>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</code>

Steffen Brewersdorff 已经出色地介绍了使用 GitHub Actions 进行 CI，但让我们简要回顾一下这里发生的事情。

这将等待对主分支的推送发生，然后才运行管道。可以随意更改此设置以在一个、两个或所有分支上运行。

<code>on:
  push:
    branches:
      - main</code>

然后，它使用 checkout 拉取仓库并安装 Node，以便 npm 可用于安装项目依赖项。如果这是您偏好的内容，则可以添加测试步骤。

<code>- 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</code>

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

<code>- name: Release
run: npm run release</code>

推送更改并查看操作：

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

发布派对！

我们已经成功创建了一个 CI/CD 语义化发布工作流程！是不是没那么痛苦？设置相对简单，拥有语义化发布工作流程没有任何缺点。它只会使跟踪更改变得容易得多。

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

以上是如何通过连续部署自动化项目版本并发布的详细内容。更多信息请关注PHP中文网其他相关文章！