了解提取要求驗證
當您使用提取要求時，可以確保另一個人檢閱 Azure 部署的任何更新。 不過，對程式碼變更執行自動化「檢查」，通常也很有幫助。 在此單元中，您將了解如何使用自動化提取要求驗證和檢查來增加小組對程式碼變更的信賴度。
提取要求驗證
檢閱 Bicep 程式碼的提取要求時，您可能必須先完成一些常見步驟才能評估變更。 這些步驟可能包括：
- 檢查 Bicep 檔案是否有任何錯誤或 Linter 警告。
- 確保先前在 Bicep 檔案中定義的任何資源都會繼續運作。
- 測試任何新定義的資源，確保資源成功部署並如預期般運作。
「提取要求驗證」包含將其中部分活動自動化。 當您將提取要求檢查自動化時，檢閱者可以將時間花在其他更重要的檢閱步驟上，例如，確保程式碼符合小組的品質標準並達成業務目標。
在 GitHub Actions 工作流程中，您可以定義觸發程序，以在提取要求流程的特定點叫用工作流程，包括建立、更新、合併或關閉提取要求時。
在提取要求驗證工作流程中測試 Bicep 程式碼
在先前的課程模組中，您已了解如何建置完整的 GitHub Actions 工作流程，以進行 Lint 分析、驗證、部署及測試 Azure 基礎結構變更，包括跨多個環境執行這些作業。 這些工作流程會在您將您的變更合併至主分支之後執行。
您也可以在提取要求驗證工作流程中執行許多相同的活動。 例如：
- 對 Bicep 程式碼執行 Lint 分析，有助於確保程式碼語意正確，並遵循一些 Bicep 做法的基準建議。
- 「預檢驗證」可協助您建置成功部署程式碼的信賴度，而不需要實際部署檔案。 依據資源類型，預檢驗證可能會找出一些問題，例如不正確的資源名稱、特定資源的無效區域，以及您是否指定了無法成功部署的設定。
- 假設狀況，列出 Azure 環境將因部署結果所發生的變更。
- 部署，實際部署資源並確保沒有任何部署錯誤。
- 部署後測試資源，確保資源設定符合您的業務需求。
提取要求驗證工作流程是一般 GitHub Actions 工作流程，因此可以執行上述任何工作。 不過，值得思考的是在提取要求內執行哪些類型的檢查是合理的。 此處列出的許多驗證活動都需要存取 Azure 環境。 例如，「假設狀況」作業會比較 Bicep 檔案定義的資源與 Azure 訂用帳戶中的資源。 針對實際執行環境執行這項比較有其意義，但因為這樣做會產生一些額外的風險，所以您可能不願意從專為尚未完成或合併的程式碼所設計的工作流程，對實際執行環境執行作業。
在本課程模組中，您會將兩種檢查加入提取要求驗證工作流程：
- 對 Bicep 程式碼進行 Lint 分析，以便對程式碼執行一組初始檢查。
- 將程式碼部署至全新的暫存環境。
這兩個活動不需要連線到實際執行 Azure 環境，甚至不需要連線到任何一般非實際執行環境，例如測試、QA 或預備環境。 執行這兩個活動，您仍然可以對程式碼變更建置足夠的信賴度，以將程式碼合併至存放庫的主分支。
對檢閱者而言，檢查很實用，因為可以節省時間，而不用花時間手動執行活動。 對身為提取要求作者的您來說，檢查也很實用，因為可用來初步了解變更稍後在部署程序中如何作用。
在您自己的提取要求驗證工作流程中，您可以選擇使用其他活動來擴充驗證檢查。
提取要求生命週期觸發程序
GitHub 中的提取要求可能會經歷許多不同的「生命週期事件」。 例如，提取要求「已開啟」。 然後，作者可能會將變更推送至來源分支 (「同步處理」)，這會影響提取要求的內容。 接下來，可以「合併」、「關閉」而不合併提取要求，甚至在未來「重新開啟」提取要求。
使用 GitHub Actions，您可以定義回應上述任何事件的「工作流程觸發程序」。 例如，您可以定義一個只要開啟、同步化或重新開啟提取要求就會自動執行的工作流程，方法為指定 pull_request 觸發程序，無需任何其他設定：
on: pull_request
您也可以指定觸發工作流程的提取要求事件。 例如，每當提取要求關閉時，就會自動執行下列工作流程：
on:
pull_request:
types: [closed]
重要
如果在提取要求中發生合併衝突，工作流程將不會執行。 您必須解決衝突並推送解決方式，以便工作流程可以繼續執行。
提取要求狀態檢查
提取要求工作流程的結果，會在提取要求的詳細資料頁面上顯示為「檢查」。 檢查可讓作者和檢閱者快速取得自動化活動成功或失敗的意見反應，如下列範例所示：
根據預設，即使檢查失敗，仍然可以合併提取要求。 您可能不想允許這麼做，因此您可以設定「分支保護規則」，強制執行特定檢查必須成功，才能合併提取要求。
更新檔案
建立提取要求之後，作者通常需要進行更新。 例如：
- 檢閱者可能會要求作者變更程式碼。
- 如果自動化檢查失敗，則作者可以變更程式碼來修正問題，然後認可並推送變更。
藉由使用 pull_request 觸發程序，您可以設定驗證工作流程在每次更新來源分支時執行。 工作流程最新執行結果會顯示在提取要求的詳細資料頁面上。
可重複使用的工作流程
如果您查看提取要求驗證的可能檢查清單，您會發現它們與您在一般部署工作流程中執行的步驟相同。 為了避免重複，最好使用 GitHub「可重複使用的工作流程」。
您可以針對將在各種工作流程定義中使用的每個作業，定義可重複使用的工作流程。 您會在下一個練習中了解如何做到這一點。
提取要求草稿
身為作者，當您準備好要檢閱、核准和合併變更時，通常會開啟提取要求。 不過，即使您尚未準備好要合併變更，仍可在整個程式碼撰寫程序中存取自動化提取要求驗證檢查，這是很實用的做法。
當您在 GitHub 開啟提取要求時，可以將其標示為「草稿」。 GitHub 會執行所有相同的自動化檢查，檢閱者仍然可以提供意見反應。 不過，當您的提取要求處於草稿狀態時，每個人都清楚該工作尚未就緒，無法進行完整檢閱，而且無法合併。
當提取要求驗證工作流程建立暫時環境時，建立草稿提取要求尤其常見，因為您可以在即時的工作環境中預覽變更。 當您繼續推送變更時，暫時環境會更新，以納入最新的變更。