規劃您的環境
您的 Azure 資產包含許多元件，包括基本設定、全組織的資源和設定，以及應用程式工作負載。 您可能也已將資產分散到多個各有不同用途的環境。
在本單元中，您要了解讓所有部署和設定一致使用程式碼的好處。 然後，您會考量要對每個環境套用多大程度的控制和自動化。 您也會考量您的變更在部署程序各個階段的進展，以及為了支援所選部署策略所需要的控制能力和治理類型。
將基礎結構定義為程式碼
Azure 的部署和設定所涵蓋的範圍不僅僅是應用程式、虛擬機器、儲存體服務和網路。 例如，下列每個項目都是一種設定形式，以及所對應的 Azure 資源：
- 建立資源群組、訂用帳戶和管理群組以組織您的資源。
- 定義及套用 Azure 原則定義、計劃和指派，以控制其他資源的設定方式。
- 指派角色以允許使用者、群組和服務主體存取 Azure 資源。
- 設定監控 (包括警示) 以觀察您的 Azure 資源，並確保其行為符合您的預期。
第一次開始將基礎結構定義為程式碼時，您可能不知道這些項目都可以在範本或定義中定義。 但隨著您使用自動化的手段日趨成熟，將環境的一切都定義為程式碼是不錯的做法。 如此一來，您就可以針對「所有」Azure 設定使用一致、經過測試且獲得核准的程序。 此外，由於您可以在 Git 存放庫中產生不同版本的程式碼並進行追蹤，因此可以檢閱 Azure 環境隨著時間所產生的變化。 您可以使用 Git 存放庫來追蹤每項變更的歷程記錄。
例如，假設您需要設定 Azure 監視器警示。 起初，您可能會認為使用自動化功能來部署警示毫無意義。 但警示是 Azure 設定的重要部分。 如果未正確建立警示，就可能會錯過重要生產問題的通知。 在程式碼中定義警示有下列好處：
- 您的小組成員可以檢閱警示及其設定。
- 您可以先將警示部署到非實際執行環境來進行測試。
- 您可以完整追蹤 Azure 設定的變更。
環境
當您打算以自動化方式部署基礎結構時，實用的做法是先列出您打算使用的環境。 許多組織都有各式各樣的環境類型，這些類型各自有不同的特性。 例如：
- 有些環境會執行生產程式碼，有些則會執行相同程式碼的非生產版本，但可能使用不同的設定。
- 有些環境會長期存在，永遠不會刪除。 有些則是「暫時存在」：是自動建立並於不再使用時終結。
- 有些環境是由基礎結構小組或軟體開發小組使用。 有些則是由安全性小組使用，甚至由銷售小組在需要向潛在客戶展示產品時使用。
舉例您的玩具公司可能用於網站的環境：
當您變更應用程式或基礎結構並認可時，管線會透過一系列非生產環境來部署變更：開發、測試和預備。 您在特定位置上可能也有手動核准步驟，在部署繼續之前，可讓規定的小組成員先確認設定或查看管線記錄。 接著，管線最終將變更部署到實際執行環境。
除了這些環境外，您的銷售小組也有自己的「展示」環境以供與客戶商談。 銷售小組採用實際執行環境的複本來建立展示環境。 安全性小組和測試小組偶爾會建立實際執行環境的暫時性複本，以分別用於進行滲透測試和效能測試。
開發小組也有一組自己的環境。 其中有「沙箱」可供開發小組成員在探索新功能或實驗 Azure 服務時使用。 開發小組也為其檢閱及合併的每個 GitHub 提取要求建立提取要求檢閱環境。
受控環境
在上述某些環境中，合理的做法是需要進行正式的程序才能檢閱及套用變更。 此類型的環境稱為受控環境。 實際執行環境一律受控。 對某些非實際執行環境實施控制措施也是不錯的做法。 如此一來，在實際執行部署之前，您可以確保部署人員清楚了解並測試過控制措施所施加的一切限制。
相反地，「非受控環境」沒有許多 (或任何) 正式的控制措施。 非受控環境可能與其他環境一樣有相同的程式碼和類似的設定，但允許進行更多實驗和變更特定設定。 在非受控環境中，可能會允許使用者使用 Azure 入口網站或直接執行 Azure CLI/Azure PowerShell 命令來修改設定。 使用者或許也能在未使用組織的核准程序時就建立資源。 您必須先在程式碼中擷取非受控環境的變更，然後才能開始套用到實際執行環境之類的受控環境。
注意
有時候，「環境」一詞實際上可能代表多個實體環境或部署。 例如，在建立用於檢閱提取要求的暫時性環境時，可能會因為小組開啟多個提取要求，而同時有多個不同的作用中環境。 但為了規劃環境，您可以將這些具有相同特性和控制措施的環境當作相同的環境。
在與小組討論過後，您指定哪些是受控環境和非受控環境。 您也決定每個環境的擁有者。
| 環境名稱 | 描述 | 負責人 | 存留期 | 控制層級 |
|---|---|---|---|---|
| 部署 | 將多個開發人員所做的變更整合到單一環境。 | 作業小組 | 長期存在 | 受控 |
| Test | 用於對變更執行手動和自動化測試的環境。 | 作業小組 | 長期存在 | 受控 |
| 預備 | 最終的非實際執行環境，進入生產之前的變更都部署在此，且使用如同實際執行環境的設定。 | 作業小組 | 長期存在 | 受控 |
| Production | 執行您的生產工作負載。 | 作業小組 | 長期存在 | 受控 |
| 示範 | 供銷售小組用來向新客戶展示產品。 | 銷售小組 | 長期存在 | 不受控 |
| 效能測試 | 動態建立為實際執行環境的複本，以用於執行效能測試和壓力測試，然後在測試完成時刪除。 | 測試小組 | 短期存在 | 不受控 |
| 滲透測試 | 動態建立為實際執行環境的複本，以用於執行滲透測試和安全性測試，然後在測試完成時刪除。 | 安全性小組 | 短期存在 | 不受控 |
| PR 檢閱 | 針對小組成員為了變更應用程式或基礎結構所建立的每個提取要求來動態建立。 關閉提取要求時，即會刪除環境。 | 開發小組 | 短期存在 | 不受控 |
| 開發沙箱 | 由開發小組的成員建立以進行實驗或探索，然後於不再需要時刪除。 | 開發小組 | 短期存在 | 不受控 |
前面的環境清單只是舉例。 在您自己的組織中，您需要決定所要使用的環境、其存留期應該多久，以及每個環境需要的控制程度。
提示
與其晚點再新增，而必須修正許多損毀的程式碼，若能及早在部署中套用這些程序，便能更容易地對基礎結構程式碼進行 Lint 分析、測試和檢閱。
同樣地，如果安全性控制措施一開始就存在，而且也套用到您的一些非實際執行環境時，就能更容易地使用安全性控制措施。 如此一來，您的小組就會習慣在受控環境中工作。
在整個學習路徑中，我們逐漸介紹其中的某些概念。 盡早將這些元素新增到您的部署程序往往是不錯的做法。
隔離每個環境
請務必分隔每個環境，並盡可能地讓其自給自足。 對每個環境使用專用的 Azure 訂用帳戶很有用，但仍需謹慎地讓環境彼此分隔。
請避免將環境彼此相連。 例如，請勿將實際執行環境的虛擬網路對等互連至非實際執行環境的虛擬網路。 否則，其他人很容易就會不小心地從非實際執行環境變更實際執行環境的資料，或將敏感的生產資料外流到非實際執行環境。
檢查和閘道
隨著部署程序的進行，請執行一系列檢查以提高您對部署的信賴度。 您必須針對部署進行期間會經過的每個環境，決定其合理的檢查。
基礎結構的檢查通常包括：
- 程式碼檢閱。
- 將檢閱中的程式碼部署到暫時性環境，並對這些環境執行自動化測試或手動測試。
- Lint 分析。
- 預檢驗證。
- 手動測試。
- 手動核准。
- 自動化功能測試。
- 自動化煙霧測試。
- 等到上一個環境傳來健康訊號後，再移至下一個環境。
您可能會在部署程序中執行其中的某些檢查多次，例如針對每個受控環境。
提示
在設計部署程序時，請列出您需要執行的所有步驟 (無論該步驟有多小或多明顯)。 盡可能詳細。 您可能不會選擇一開始就將一切自動化，但遵循此做法可協助您為日後的自動化部署程序建立藍圖。
「閘道」是必須成功才能讓部署繼續進行的自動化檢查或手動檢查。
手動介入
建議您盡可能地將程式碼檢閱和部署程序進行期間的檢查自動化。 不過，您的組織可能需要以手動方式核准是否能部署到實際執行環境或其他受控環境。
如果您針對部署使用手動核准閘道，請遵循下列建議做法：
- 清楚定義誰可以核准部署。 使用 Microsoft Entra 群組來定義核准者，而非指定個別使用者。 日後您可以輕鬆變更核准者清單。
- 備妥緊急部署程序。 規劃在標準核准者不在時，誰可以代為核准部署。 緊急部署可能需要在半夜或放假時進行。
- 將人為介入的範圍限制在只能核准或拒絕部署。 除非有無法自動化的步驟，否則請避免必須人為執行任何部署作業的情況。
控管
Azure 提供了各項工具和功能來協助您治理環境，包括：
- Azure 原則可以偵測設定方式不符合組織需求的資源。 也可協助防止資源以不符合規範的方式建立或重新設定。
- 鎖定可以防止重要資源遭到變更或刪除。
- 管理群組可以協助您組織 Azure 訂用帳戶，並以一致的方式在您的各個環境中設定角色型存取控制和原則。
- Azure 監視器可以記錄資源的計量和日誌、將其呈現到儀表板中，並在其與預期值有所偏差時自動向您發出警示。
在建立 Azure 資產時，請考慮使用「Azure 登陸區域」。 登陸區域可讓您從一開始就在環境中建立治理功能。 許多登陸區域都包含預建的 Bicep 和 Terraform 檔案，可協助您設定環境。 我們在摘要中連結更多資訊。