瞭解環境
部署工作流程可讓您將部署程序中的步驟自動化。 通常，您必須在多個不同的環境中執行步驟。 在您的玩具公司中，您想要先檢閱對程式碼的變更，然後將變更部署到實際執行環境。
在本單元中，您將了解 GitHub Actions 中的環境如何協助您支援自己的程序。
為什麼會有多個環境？
部署流程會變更您的 Azure 資源，包括使用中的資源。 變更資源會涉及一些風險，因為您部署的變更可能無法如預期般運作。 您甚至可能發現變更會中斷您目前的設定。
若要將問題的風險降到最低，最好先以安全的方式試用您的變更，然後再將其部署到您的實際執行環境。 您可透過將變更部署到「非實際執行環境」來將風險降至最低。
許多組織都會設定多個非實際執行環境，在其中逐步部署變更，然後再發佈到實際執行環境。 每個非實際執行環境都具有特定用途，而且通常會有特定的品質閘道，必須達到該閘道，才能繼續移至下一個環境。 如果發生錯誤 (例如測試失敗)，部署就會停止。 隨著您的部署經歷每個環境，您對變更的信賴度也會隨之升高。
常見的環境包括：
開發：開發人員通常會使用開發環境來嘗試其變更，並快速逐一查看其工作。
開發環境通常具有最少的控制措施，讓小組成員可以輕鬆地嘗試各種想法。 您可以使用開發環境來測試資源上的特定組態設定，也可以查看如何以安全的方式設定具有後端資料庫的新網站。 在這些變更和試用中，很多可能都不會進入部署流程，因為您正在排除不會成功的構想。
在某些小組中，您甚至可為每個小組成員設定個別的開發環境，如此當他們在處理新功能時便不會互相干擾。
開發環境有時也稱為「沙箱」環境。
測試：測試環境的設計目的是針對您的變更執行手動或自動化測試。
測試環境可用於持續整合流程。 將變更部署到測試環境之後，就可以對其執行自動化測試。 如果通過所有自動化測試，則可將變更安全地合併至專案的主分支。 自動化測試通常會檢查核心系統功能，以及新部署資源中原則違規等事項。
您也可以針對特定類型的測試 (例如，效能和安全性測試) 建立專用測試環境。
整合：整合環境可協助您測試任何與其他系統的整合點。
您可以在整合環境中模擬端對端交易。 這些測試通常會自動執行，但許多組織也會針對此環境執行手動測試。
整合環境有時也稱為「系統整合測試」(SIT) 環境。
使用者接受度測試：使用者接受度測試 (UAT) 環境會用於手動驗證，通常由商務專案關係人而非開發人員使用。 在手動驗證中，人員會使用解決方案，並確認其行為能如預期運作，並達到必要的商務需求。 接著，該人員會核准變更，以便繼續部署。
實際執行前：實際執行前環境通常是實際執行環境的鏡像，且具有相同的資源 SKU 和設定。 其可用來作為最終檢查，以驗證實際執行環境部署在套用變更期間和之後的行為。 其也可用來驗證實際執行環境部署期間是否有任何預期的停機時間。
實際執行前環境有時也稱為「預備」環境。
實際執行：您的實際執行環境是應用程式終端使用者所使用的環境。 這是您想要妥善保護及盡可能維持運作的即時環境。
在某些組織中，可能有多個實際執行環境。 例如，您可能會在不同的地理區域中設有實際執行環境，或用來為不同的客戶群組提供服務。
示範：您的小組可能也會建立示範環境，以向終端使用者展示應用程式、用於定型，或是讓銷售小組向潛在客戶展示特定功能。 您甚至可以有多個提供不同用途的示範環境。 示範環境通常是實際執行環境的精簡複本，其中包括假造的客戶資料。
組織中的環境
您可能會看到這些環境的變化。 有些組織只會使用幾個環境，有些則會使用更多環境。 您使用的環境數目和類型取決於您要部署的解決方案、建置解決方案的小組規模，以及工作負載的重要性。
有時候，單一環境會同時扮演先前所列之數個環境的角色。 有時候，您可能會有部署到多個環境的複雜工作流程，有些會平行執行，有些則會依序執行。 一些組織在不再使用環境時，甚至會自動加以刪除或取消佈建，然後在未來需要時再重新部署該環境。
無論您的組織選擇何者加入環境清單，其目標都是透過部署工作流程來提升對變更的信賴度。 當變更不符合您的品質需求時，您希望能夠停止將該變更部署到鏈結中的任何後續環境。
在您的玩具公司中，您決定從適用於網站的基本環境組合開始。 除了實際執行環境之外，您還會建立一個名為「測試」的非實際執行環境：
您將會更新工作流程，以將 Bicep 程式碼部署至測試環境，並對其執行一些基本測試。 如果該工作成功，您即可部署至實際執行環境。
工作流程環境
GitHub Actions 也具有環境的概念。 您可以建立 GitHub Actions 環境來代表您在 Azure 中擁有的環境。 當您以 YAML 檔案定義工作流程時，您可以將作業連結至特定環境。 透過使用環境，您可以在工作流程中取得一些額外的功能。
保護規則
GitHub Actions 中的環境可以設定保護規則。 每次在工作流程中的作業中使用環境時，GitHub Actions 會在作業開始執行之前確定符合這些規則。
例如，您可以在實際執行環境上設定手動檢閱。 在實際執行部署開始之前，指定的檢閱者會收到電子郵件通知。 該人員可以在部署開始之前，手動驗證是否已符合您的原則和程序。 例如，核准者可能會在核准部署之前，先在實際執行前環境中檢查所有項目都會如預期般運作。
此外，您可以執行自動化檢查，以確認變更的來源分支。 如果變更不在主分支上，您可以設定 GitHub 以防止將其部署至您的實際執行環境。
密碼
GitHub Actions 可讓您儲存只能與特定環境搭配使用的祕密。 您將在此課程模組稍後深入了解祕密管理。
部署歷程記錄
GitHub Actions 會追蹤針對環境之部署的歷程記錄。 此歷程記錄可讓您輕鬆追蹤環境中一段時間內發生的情況。 其甚至可讓您針對部署一路追蹤至存放庫中的某個認可。 如果您有部署問題，而且需要識別導致問題的變更，則此功能很有用。
建立環境
您可以使用 GitHub Web 介面來建立環境。
當您的工作流程參考不存在的環境時，GitHub Actions 會自動為您加以建立。 此功能可能會影響 GitHub 存放庫的安全性，因為新環境不會設定任何保護規則。 最好是透過 GitHub Web 介面自行建立環境，以便您可以完全掌控其安全性。
將部署作業連結至環境
在部署工作流程定義中，您可以使用 environment 屬性來參考某個環境：
jobs:
deploy:
environment: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
在此範例中，名為 deploy 的作業會連結至 Test 環境。
環境和針對 Azure 的連線
當您使用多個環境時，您應該要讓每個環境彼此獨立。 例如，開發環境的網站不應該能夠存取實際執行環境內的資料庫。
相同的原則也適用於部署工作流程。 您應該要針對每個環境建立個別的工作負載身分識別。 遵循此做法能添加另一層保護，以確保您的非實際執行部署不會影響到您的實際執行環境。
應該為工作負載身分識別指派特定的權限，以僅部署至該環境所使用的訂用帳戶和資源群組：
重要
針對您打算部署至的每個目標環境，使用不同的工作負載身分識別。 授與工作負載身分識別部署至其環境所需的最低權限，而不要包括任何其他權限。
在 Azure 中分隔您的環境也是個不錯的想法。 至少，您應該為每個環境建立個別的資源群組。 在許多情況下，最好為每個環境建立個別的 Azure 訂用帳戶。 然後，您就可以在每個環境的訂用帳戶內建立多個資源群組。
套用 Azure 角色指派，讓使用者和工作負載身分識別只能存取其需要存取的環境。 此外，請謹慎地將實際執行環境的存取限制給一小組人員，以及該環境的部署工作負載身分識別。
環境的同盟認證
當您的工作負載身分識別從部署工作流程連線到 Azure 時，其會使用「同盟認證」來安全地自行驗證，而不需要任何祕密或金鑰。 在此學習路徑的上一個課程模組中，當您的部署工作流程從您 Git 存放庫的 main 分支部署時，您的同盟認證已授與對您部署工作流程的存取權。
當您在工作流程內部署至環境時，必須使用將範圍設定為該環境的同盟認證。
在此課程模組中，您的工作流程包括數個作業，其中許多都會連線並部署至 Azure。 有些作業會使用環境，有些則不使用。 因此，您會針對這兩個工作負載身分識別建立兩個同盟認證：一個將範圍設定為環境，另一個將環境設定為 main 分支。