什么是语义版本控制?
语义版本控制是一种版本控制方案,旨在一目了然地传达版本之间的兼容性级别。它使用三部分编号系统:major
. minor
. patch
(例如 1.2.3)。并且有时带有特殊标识符后缀,例如-alpha
或-rc1
。
每个部分都有不同的含义:
-
Major : 增加这个数字 (1.0.0 -> 2.0.0) 表示用户应该期待重大的重大变化。
-
Minor:次要编号 (1.0.0 -> 1.1.0) 在发布非破坏性功能和更改时递增。次要版本应该是向后兼容的。
-
补丁:补丁级别的更改 (1.0.0. -> 1.0.1) 是一种非破坏性升级,它引入了低风险更改,例如修复错误或修补安全问题。
开发人员可以通过比较版本号来快速评估升级风险。主要版本是有风险的,应该仔细计划。次要和补丁级别的更改引入不兼容性的可能性要低得多,并且安装起来更安全。
使用语义发布自动化版本
我们如何确定语义版本控制方案中的版本号?这是一个棘手的问题,因为一个典型的版本包含几十个提交。有些包含错误修复,而另一些可能会引入重大更改。在这种情况下,确定适当版本的唯一方法是单独审查每个提交并评估影响。如果听起来很多重复且容易出错的工作最好使用一些自动化工具来完成,那么你是对的。
Semantic-release是一个版本控制工具,能够通过读取提交消息来计算语义版本号。它还可以生成发布说明并将包发布到 GitHub 和 NPM。
正如您可能想象的那样,要使其正常工作,提交消息应遵循预定义的模式:
<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
标头是消息的唯一强制性部分,应采用如下格式:
<type>(<scope>): <short summary>
标头中最重要的组成部分是类型,它有助于语义发布评估提交中引入的更改的重要性。默认行为遵循Angular 的消息格式:
标题类型 | 结果 |
---|---|
修复,完善 | 将版本升级到下一个补丁级别 (1.0.0 -> 1.0.1) 并发布 |
壮举 | 将版本提升到下一个次要级别(1.0.0 -> 1.1.0)并发布 |
文档、构建、ci、重构、测试 | 没有版本碰撞。没有释放。 |
无论标头类型如何,如果提交消息的正文包含字符串BREAKING CHANGE
or DEPRECATED
,语义释放执行主要版本增加。
为了澄清,让我们看几个例子及其效果:
提交消息 | 结果 |
---|---|
修复(铅笔):施加太大压力时停止石墨破裂 | 发布补丁。 |
壮举(铅笔):添加“石墨宽度”选项 | 发布次要版本。 |
perf(铅笔):删除graphiteWidth选项重大更改:graphiteWidth选项已被删除。出于性能原因,始终使用默认的 10 毫米石墨宽度。 | 发布主要版本。 |
如何开始使用语义发布
虽然语义发布是基于节点的应用程序,但它支持任何语言,而不仅仅是 JavaScript 或 TypeScript。不过,您需要安装 Node 和 NPM 才能使用它。
要将语义发布添加到您的项目,请执行以下步骤:
-
使用
npx semantic-release-cli setup
. 当询问要使用哪个 CI 平台时,选择Other
并复制显示的环境变量。您将获得一个用于 GitHub 的令牌,也可以选择获得一个用于 NPM 的令牌。export GH_TOKEN=ghp_Lw83uUpu4paBlLKQuRijD3NMTDusAL07J89l export NPM_TOKEN=npm_xWtDqAasy9yBTPPuA6QppCJx7JIu5w1009KY8
-
转到项目的 Git 存储库。如果项目在 Node.js 上运行,请添加
semantic-release
包:npm --save-dev semantic-release
-
按照之前讨论的提交指南进行一些代码更改并创建提交。例如:
feat: initial commit
-
运行
npx semantic-release
。在非 CI 环境中,该工具以试运行模式运行。该日志显示将在下一个版本中分配的版本(在下面的示例中,v1.0.0)。ℹ Running semantic-release version 19.0.5 ⚠ This run was not triggered in a known CI environment, running in dry-run mode. ✔ Allowed to push to the Git repository ✔ Completed step "verifyConditions" of plugin "@semantic-release/npm" ✔ Completed step "verifyConditions" of plugin "@semantic-release/Github" ℹ No git tag version found on branch master ℹ No previous release found, retrieving all commits ℹ There is no previous release, the next release version is 1.0.0 ℹ Start step "generateNotes" of plugin "@semantic-release/release-notes-generator" ✔ Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator" ⚠ Skip v1.0.0 tag creation in dry-run mode ℹ Release note for version 1.0.0: # 1.0.0 (2022-08-23) ### Features * initial commit
-
当您准备好发布时,执行:
npx semantic-release --no-ci
。这将标记发布并发布包。
您可以通过在项目的根目录中创建一个.releaserc
或文件来自定义工具的行为。release.config.js
这将允许您调整提交消息格式,将能够触发发布的分支列入安全列表,并启用可选插件。有关更多详细信息,请查看配置文档。
使用 CI/CD 进行语义版本控制
在本节中,我们将配置一个 CI/CD 管道来执行语义版本控制。我假设您已经安装了语义发布并且已经有一个持续集成管道。
起始 CI 管道构建和测试 JavaScript Node.js 项目。
在我们可以添加持续交付之前,我们需要在 Semaphore 中进行两项更改:
- 禁用标签,因此发布不会触发 CI 构建。
- 添加包含 GitHub 或 NPM 凭据的密钥。
禁用信号量上的标签
默认情况下,信号量会在所有分支和 Git 标签上触发 CI 构建。这种行为的问题是语义发布在每个新版本上创建并推送一个标签。因此,如果我们不禁用 Semaphore 上的(或安全列表)标签,则该工具的发布可能会触发辅助(无用)CI/CD 运行。
通过打开 Semaphore 项目设置并向下滚动到要构建的内容来更改构建设置?. 确保未选中标签选项。
不要在 Git 标签上触发 CI 构建。
添加身份验证秘密
Semaphore 将代表您将版本发布到 GitHub 和 NPM。因此,它需要访问您的授权凭证,我们将使用秘密存储它。
-
转到您的组织菜单,然后单击设置。
-
单击秘密 >新秘密
-
秘密的名称应该是
semantic-release-credentials
。添加您的 GitHub 和/或 NPM 令牌,如下所示:
设置持续交付管道
让我们添加一个持续交付管道来自动发布项目的新版本。
-
在 Semaphore 上打开您的项目并编辑工作流程。
-
单击+添加促销以创建新管道。如果您想自动发布新版本,请启用自动促销。
-
选择新块并添加以下命令。
sem-semantic-release
是处理安装并将发布信息导出到管道的工具的薄包装器。 -
打开秘密部分并启用之前创建的秘密。
-
单击运行工作流程> 开始测试您的管道。