Rush Stack商店博客活动
跳过到主要内容

如何在您的构建流程中使用 Rush 来自动化发布更新的包

Rush 发布流程分为两个阶段。第一个阶段是在开发期间。开发人员被要求提供变更文件来跟踪应在变更日志中占有一席之地的更改。第二个阶段是在发布时。Rush 可用于收集所有变更文件以增加版本、更新变更日志，并将新包发布到 npm 注册表。

1. 跟踪更改​

只需要跟踪对公共包的更改。人员可以通过在 rush.json 中指定 shouldPublish 字段来控制哪些包应该发布，哪些包不应该发布。定义了公共包后，仓库管理员可以强制开发人员在修改任何公共包时提供变更文件。开发人员可以使用工具在回答几个问题后生成变更文件。

如何强制开发人员提供变更文件​

rush change --verify

如果开发人员在未提供相关变更文件的情况下修改了公共包，则此命令将失败。建议将此命令添加为 CI 构建的步骤，以便在缺少变更文件时构建失败。

开发人员如何生成变更文件​

rush change

运行 rush change 将提示开发人员回答几个问题，并在回答完问题后生成相应的变更文件。变更文件包含此更改需要进行哪种类型的版本增加以及对更改的描述。变更文件应与相关更改一起提交到仓库中。

2. 发布包​

rush publish

当需要发布更新的包时，rush publish 是用于增加包版本并发布更新的包的命令。它在内部执行了许多操作来实现这一点：收集所有变更文件以确定需要进行哪种类型的版本增加、哪些包需要增加版本、增加依赖项的版本、清理变更文件等等。

此命令应该有自己的构建定义。因此，人们只需在需要发布包时触发它即可运行。

rush publish 可配置以满足不同的用途。例如，它支持试运行模式，以便在实际发布之前验证和测试更改。这里列出了更多用例

试运行模式​

rush publish 有几种试运行模式，这些模式允许您执行发布过程的中间步骤，而无需实际发布到 npm 注册表。这对于测试以及在没有用于发布的外部包存储库的情况下创建版本号提升和变更日志非常有用。

rush publish

在不使用任何参数的情况下运行时，它将以只读模式执行整个过程，这意味着更改不会保存到磁盘，不会提交到源代码仓库，也不会真正发布包。如果您想检查版本增加和变更日志更新是否符合您的要求，它非常有用。

rush publish --apply

在此模式下，更改将添加到变更日志文件，并且 package.json 文件将使用新的版本号更新并写入磁盘，但不会实际提交到源代码仓库或发布。如果您想在提交到源代码仓库或发布到包存储库之前查看或编辑任何这些文件，这非常有用。

rush publish --apply --target-branch targetBranch

在此模式下，上述更改将实际提交到基于 targetBranch 的新 git 分支（以 publish- 为前缀）。使用 targetBranch 设置为在 repository.defaultBranch 中指定的指定分支运行此命令，实际上将执行“实时”发布将执行的所有操作（包括提交到 git 源代码），只是不会实际发布到 npm 存储库。

发布模式​

有一些额外的参数可用于配置发布过程：要发布到的注册表、要使用的令牌以及是否包含提交详细信息。

rush publish --apply --target-branch targetBranch --publish

此命令增加版本、将更改提交到 targetBranch，并将包发布到基于环境 npm 注册表值的注册表。

rush publish --apply --target-branch targetBranch --publish --registry registryUrl --npm-auth-token npmToken

除了之前的命令可以执行的操作之外，此命令还允许将包发布到使用指定 npm 令牌的指定注册表。

rush publish --apply --target-branch targetBranch --publish --registry registryUrl --npm-auth-token npmToken --add-commit-details

除了之前的命令可以执行的操作之外，此命令还将在变更日志中包含提交详细信息。

打包模式​

您还可以选择将输出在本地打包到 .tgz 文件中，而不是发布。

rush publish --pack --include-all --publish

注意：任何使用 --publish 标志的命令都将禁用试运行模式，这允许将文件内容写入磁盘。

您还可以将此命令与 --release-folder 结合使用，以暗示文件应输出的位置。

3. 版本策略​

版本策略是 Rush 中引入的一个新概念，用于解决在包数量很大时如何通知包进行不同类型的版本增加的问题。例如，@microsoft/rush 和 @microsoft/rush-lib 始终一起发布并使用相同的版本。这两个版本应该始终一起增加。另一个例子是开发人员可以创建不同的分支来服务不同的主要版本。人们不应该能够在该分支中修改主要版本。版本策略通过定义不同的策略来解决此类问题，其中一个策略强制 rush 和 rush-lib 始终具有相同的版本，另一个策略锁定分支中的主要版本。

什么是版本策略？​

版本策略是一组规则，定义了版本应如何增加。它在 common/config/rush/version-policies.json 中定义。可以在 这里找到示例。公共包通过在 rush.json 中提供 versionPolicyName 来指定它与哪个版本策略相关联。可以在 Rush 和 Rush-lib 配置 中找到示例。如果所有包都遵循相同的规则，则多个包可以使用一个版本策略。当包与版本策略相关联时，它将成为公共包，并且可以在运行 rush publish 时发布。

version-policies.json 的模式在 这里定义。

两种类型的版本策略​

目前支持两种类型的版本策略：步调一致版本策略和个体版本策略。使用一个步调一致版本策略的项目都具有相同的版本。使用个体版本策略的项目将根据其变更文件和策略的限制增加版本。例如，如果个体版本策略具有锁定主要版本，则使用此策略的所有包的主要版本都将被锁定。

[
  {
    "policyName": "myPublic",
    "definitionName": "lockStepVersion",
    "version": "1.0.0-dev.6",
    "nextBump": "prerelease"
  },
  {
    "policyName": "myInternal",
    "definitionName": "individualVersion",
    "lockedMajor": 3
  }
]

使用版本策略时的发布过程​

当使用版本策略时，发布包需要两个步骤。第一步是提升包版本。第二步是发布包。将发布过程分成两个步骤的原因是，通常需要在提升版本后、发布包之前测试包。

提升版本命令​

rush version --bump

运行 rush version --bump 会根据每个包关联的版本策略提升其版本。

发布包命令​

rush publish --include-all

运行 rush publish --include-all 会发布所有版本已提升的公共包。

4. 总结​

总之，您可以使用 Rush 自动化仓库的整个发布流程。