設計工作流程和版本設定策略
當您開始發佈可重複使用的 Bicep 程式碼時，您可能會使用手動方法。 您可以輕鬆決定需要發佈的 Bicep 檔案，而且可能有用於遞增版本號碼的手動程序。
當您將發佈程式自動化時，您必須考慮如何自動化這些步驟。 在本單元中，您將了解如何採用版本設定系統，以傳達您對程式碼所做的變更。 您也將了解如何設定工作流程的範圍，只發佈您預期的程式碼。
版本號碼
在先前的 Microsoft Learn 訓練課程模組中，您已了解範本規格和 Bicep 模組版本設定的重要性。 您可以選擇許多不同的版本設定方法。 在許多情況下，最好使用多部分版本設定系統。 多部分版本設定系統是由主要版本、次要版本和修訂編號所組成，類似下列範例：
在上述範例中，主要版本為 1、次要版本為 4，而修訂編號為 106。
版本號碼不同部分的變更會傳達有關程式碼中變更類型的重要資訊：
每當進行中斷性變更時，您應該遞增主要版本號碼。 例如，假設您新增強制參數，或是從 Bicep 檔案中移除參數。 這些是中斷性變更的範例，因為 Bicep 需要在部署時間指定強制參數，且不允許設定不存在參數的值。 因此，您會更新主要版本號碼。
每當您要新增程式碼內容，但不是中斷性變更時，您應該遞增次要版本號碼。 例如，假設您新增具有預設值的選用參數。 選用參數不是中斷性變更，因此您應該更新次要版本號碼。
每當進行回溯相容的錯誤修正或其他不會影響程式碼運作方式的變更時，您應該遞增修訂編號。 例如，假設您為了更妥善地使用變數和運算式而重構 Bicep 程式碼。 如果重構完全不會變更 Bicep 程式碼的行為，您就會更新修訂編號。
您的工作流程也可以自動設定修訂編號。 工作流程的執行數目可用來做為修訂編號。 此慣例有助於確保版本號碼一律是唯一的，即使您未更新版本號碼的其他元件也一樣。
例如，假設您使用的是其他人已發佈的 Bicep 模組。 模組的版本號碼為 2.0.496。 您會看到新版本的模組可供使用，版本號碼為 2.1.502。 唯一的重大變更是次要版本號碼，這表示當您使用新版本時不應預期發生中斷性變更。
注意
語意版本設定是一種正式化版本設定結構，與多部分版本設定類似。 語意版本設定包含版本號碼中的其他元件，以及有關您應該設定或重設每個元件的嚴格規則。 我們在摘要中提供有關語意版本設定的詳細資訊連結。
您的小組必須決定如何針對版本設定目的來定義中斷性變更。 例如，假設您已建置部署儲存體帳戶的 Bicep 模組。 您現在正在更新 Bicep 檔案，以在您的儲存體帳戶上啟用私人端點。 您同時將私人 DNS 區域新增至 Bicep 檔案。
在該範例中，您可以進行變更，而不會影響 Bicep 檔案的參數或輸出。 如此一來，任何部署檔案的人可能都不會注意到任何不同。 但這項變更會使資源的行為產生顯著差異，因此您可能會決定將其視為主要版本更新。
您也可以選擇使用更簡單的版本設定策略，例如只使用工作流程的執行數目做為版本號碼。 雖然這種方法更容易實作，但表示您無法有效地將版本之間的差異傳達給使用程式碼的人。
版本和工作流程
當您以互動方式發佈程式碼時 (例如使用 Azure CLI)，您可能會在發佈時考慮指派給範本規格或模組的版本號碼。 但在自動化部署工作流程中，您必須變更版本號碼指派方法。 您的工作流程無法自動偵測中斷性變更，或建議您何時應該遞增主要或次要版本號碼。 在發佈範本規格或模組之前，請仔細考慮版本設定。
其中一種方法是使用 Bicep 程式碼來儲存中繼資料檔案，如下圖所示：
每當更新 Bicep 程式碼時，您會更新對應中繼資料檔中的版本資訊。 請確定您已正確識別中斷性和非中斷性變更，以便正確遞增版本號碼。
提示
如果您的小組使用提取要求來檢閱 Bicep 程式碼，請要求檢閱者驗證程式碼的任何變更是否需要變更您的主要或次要版本號碼。
您將在下一個練習中看到如何使用中繼資料檔案。
有多少工作流程？
建置範本規格和模組的集合很常見。 通常，在同一個 Git 存放庫中保留這些項目很合理。
藉由在 GitHub Actions 中使用路徑篩選，您可以在存放庫內為每個模組或範本規格建立個別的工作流程。 此方法可協助您避免每次變更一個檔案時，就在存放庫內發佈每個 Bicep 檔案的新版本。 您可以使用可重複使用的工作流程，在集中式檔案中定義工作流程的步驟，讓每個模組和範本規格的工作流程保持輕量型。
例如，假設您有類似稍早說明的檔案結構。 您可以設定三個不同的工作流程，分屬每個 Bicep 檔案。 選取每個索引標籤以查看對應的工作流程定義及其路徑篩選：
name: 'publish-module-1'
on:
push:
branches:
- main
paths:
- 'module-1/**'
jobs:
publish:
uses: ./.github/workflows/publish-module.yml
with:
path: 'module-1/main.bicep'
假設您只變更 module-2/main.bicep 檔案。 只有模組 2 的工作流程會執行。 但是，如果您在相同的認可中變更多個檔案，則會觸發每個相關的工作流程。
注意
為每個可重複使用的 Bicep 檔案建立工作流程的方法很簡單且有彈性。 但是，當您有大量的 Bicep 檔案時，或不想為每個模組和範本規格維護個別的工作流程時，可能會變得麻煩。
您也可以在工作流程中撰寫指令碼，以尋找已變更的程式碼，並且只發佈這些檔案。 這是更複雜的方法，而且超出此 Microsoft Learn 課程訓練模組的範圍。
可重複使用的 Bicep 程式碼的環境
當您使用 Bicep 部署至 Azure 時，在將程式碼發佈至實際執行環境之前，通常會使用多個環境來協助您驗證及測試程式碼。 在先前的 Microsoft Learn 訓練課程模組中，您已了解如何從部署工作流程使用多個環境。
有些組織會將相同的原則套用至 Bicep 模組和範本規格。 例如，您可能先將新版本的模組發佈至非生產登錄，讓每個模組的使用者都可以試用新版本。 然後，在使用者登出之後，您可以將模組發佈至組織的生產登錄。
如同一般部署，您可以使用作業和可重複使用的工作流程來定義整個環境的部署序列。 在此 Microsoft Learn 課程模組中，我們會發佈至單一環境，讓工作流程保持簡單。
當您從登錄取用模組或使用範本規格做為 Bicep 模組時，您可以使用別名。 您不需要在每次定義模組時指定登錄名稱或範本規格的位置，而是使用其別名。
藉由使用別名，您可以讓部署程序跨多個環境運作。 例如，當您定義模組時，可能會使用別名，而不是登錄名稱。 然後，您可以設計部署工作流程，以設定別名的對應登錄：
- 開發模組登錄 (當您部署至沙箱環境時)。
- 生產登錄 (當您部署至其他環境時)。
注意
當您發佈時，不會套用別名。 只有當您在 Bicep 檔案中使用範本規格或模組時，別名才有效。