Rush Stack商店部落格活動
跳至主要內容

如何在建置流程中使用 Rush 來自動發佈更新的套件

Rush 發佈流程分為兩個階段。第一個階段是在開發期間。系統會要求開發人員提供變更檔案，以追蹤變更日誌中應佔有一席之地的變更。第二個階段是在發佈時。Rush 可用來收集所有變更檔案，以增加版本、更新變更日誌，並將新套件發佈至 npm 登錄。

1. 追蹤變更​

只需追蹤公開套件的變更。人們可以透過指定 shouldPublish 欄位，在 rush.json 中控制應發佈哪個套件以及不應發佈哪個套件。一旦定義了公開套件，儲存庫管理員可以強制開發人員在修改任何公開套件時提供變更檔案。開發人員可以使用工具，在回答幾個問題後產生變更檔案。

如何強制開發人員提供變更檔案​

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- 為前綴)。使用設定為 repository.defaultBranch 中指定的分支的 targetBranch 執行此指令，將有效地執行「即時」發佈的所有操作 (包括提交至 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 自動化您的儲存庫的整個發佈流程。