失敗的部署和錯誤版本是應用程式中斷的常見原因。 部署和測試的方法在任務關鍵性應用程式的整體可靠性中扮演重要角色。
部署和測試應形成所有應用程式和基礎結構作業的基礎，以確保任務關鍵性工作負載的結果一致。 準備每周、每天或更頻繁地部署。 設計持續整合和持續部署 （CI/CD） 管線以支援這些目標。
策略應實作：
嚴格的發行前測試。 更新不應造成可能危及應用程式健康情況的瑕疵、弱點或其他因素。
透明部署。 應該隨時推出更新，而不會影響使用者。 用戶應該能夠繼續與應用程式互動，而不會中斷。
高可用性作業。 部署和測試程式和工具必須具有高可用性，才能支援整體應用程式可靠性。
一致的部署程式。 應該使用相同的應用程式成品和程式，在不同的環境中部署基礎結構和應用程式程序代碼。 端對端自動化是必要的。 必須避免手動干預，因為它們可能會帶來可靠性風險。
此設計區域提供如何優化部署和測試程序的建議，目標是將停機時間降到最低，並維護應用程式健康情況和可用性。
這很重要
本文是 Azure 架構完善框架中任務關鍵型工作負載 系列的一部分。 如果您不熟悉此系列，我們建議您從什麼是使命關鍵工作負載？開始。
零停機部署
如需零停機部署的概觀，請檢視下列影片。
達成零停機部署是任務關鍵性應用程式的基本目標。 即使您在上班時間推出新版本，您仍必須整天使用您的應用程式。 先投入心力來定義和規劃部署程式，以推動關鍵設計決策，例如是否將資源視為暫時性。
若要達到無停機時間的部署，請在現有架構旁部署新的架構，徹底進行測試，將終端使用者流量轉移到新架構，然後才退役先前的架構。 其他做法，例如 縮放單位架構，也是關鍵。
Mission-Critical Online 和 Azure Mission-Critical Connected 參考實作說明此部署方法，如下圖所示：
應用程式環境
如需應用程式環境的建議概觀，請檢視下列影片。
您需要各種類型的環境來驗證和準備部署作業的階段。 這些類型具有不同的功能和生命週期。 某些環境可能會反映生產環境且壽命很長，而有些環境可能很短，且功能比生產環境少。 在開發週期早期設定這些環境有助於確保靈活度、將生產和生產前資產分離，以及在發行至生產環境之前徹底測試作業。 所有環境都應該盡可能反映生產環境，不過您可以視需要將簡化套用至較低的環境。 下圖顯示工作關鍵架構：
有一些常見的考慮：
元件不應該跨環境共用。 可能的例外狀況是下游安全性設備，例如綜合測試數據的防火牆和來源位置。
所有環境都應該使用基礎結構即代碼（IaC）工件，例如 Terraform 或 Azure Resource Manager（ARM）範本。
開發環境
如需暫時開發環境和自動化功能驗證的相關信息，請檢視下列影片。
設計考量
功能。 開發環境可接受的可靠性、容量和安全性需求較低。
生命週期。 開發環境應視需要建立，並短暫存在。 較短的生命週期有助於防止設定偏離程式代碼基底並降低成本。 此外，開發環境通常會共用功能分支的生命週期。
密度。 團隊需要多個環境以支持平行特色功能的開發。 他們可以共存於單一訂用帳戶內。
設計建議
將環境保留在專用訂用帳戶中，並將上下文設置為開發用途。
使用自動化程式，將程式代碼從功能分支部署至開發環境。
測試或預備環境
這些環境用於測試和驗證。 會執行許多測試週期，以確保無 Bug 部署至生產環境。 持續驗證和測試一節會說明任務關鍵性工作負載的適當測試。
設計考量
功能。 這些環境應反映生產環境的可靠性、容量和安全性。 如果沒有生產負載，請使用綜合用戶負載來提供實際計量和寶貴的健康情況模型化輸入。
生命週期。 這些環境是短暫的。 測試驗證完成之後，應該銷毀它們。
密度。 您可以在一個訂用帳戶中執行許多獨立環境。 您也應該考慮使用多個環境，每個環境都位於專用的訂用帳戶中。
備註
任務關鍵性應用程式應接受嚴格的測試。
您可以在單一環境中執行不同的測試功能，有些情況下需要這樣做。 例如，若要讓混亂測試提供有意義的結果，您必須先將應用程式放在負載下，以便瞭解應用程式如何回應插入的錯誤。 這就是為什麼混亂測試和負載測試通常會以平行方式執行。
設計建議
請確定至少有一個預備環境能完整反映生產環境，以便能進行類似生產環境的測試和驗證。 此環境內的容量可以根據測試活動的執行而彈性。
產生綜合用戶負載，以提供一個環境變更的實際測試案例。
定義開發與發行週期內的預備環境數目及其用途。
實際執行環境
設計考量
功能。 應用程式需要最高層級的可靠性、容量和安全性功能。
生命週期。 雖然工作負載和基礎結構的生命週期保持不變，但所有數據，包括監視和記錄，都需要特殊管理。 例如，備份和復原需要管理。
密度。 對於某些應用程式，您可能想要考慮使用不同的生產環境來迎合不同的用戶端、用戶或商務功能。
設計建議
針對生產環境與較低環境具有明確的治理界限。 將每個環境類型放在專用訂用帳戶中，以達成該目標。 此分割可確保較低環境中的資源使用率不會影響生產配額。 專用訂用帳戶也會設定存取界限。
臨時藍綠部署
藍/綠部署模型至少需要兩個相同的部署實例。 藍色部署是活躍的，負責處理生產環境中的使用者流量。 綠色部署是準備並測試接收流量的新部署。 綠色部署完成並測試之後，流量會逐漸從藍色導向到綠色。 如果負載傳輸成功，綠色部署會變成新的工作部署。 然後，您可以透過分階段的過程退役舊藍色部署。 不過，如果新部署發生問題，可能會中止，而且流量可以保留在舊的藍色部署中，或重新導向至該部署。
Azure Mission-Critical 建議採用藍/綠部署方式，將基礎結構與應用程式整合為一個部署組件來進行部署。 因此，對基礎結構或應用程式的變更一律會導致包含這兩層的綠色部署。 這種方法可讓您在將使用者流量重新導向至基礎結構和應用程式之前，先對基礎結構和應用程式端對端進行變更的完整測試和驗證。 因為可以驗證與 Azure 平臺、資源提供者和 IaC 模組等下游相依性的相容性，因此此方法會增加釋放變更並啟用零停機升級的信心。
設計考量
技術功能。 利用 Azure 服務中的內建部署功能。 例如，Azure App Service 提供可在部署之後交換的次要部署位置。 使用 Azure Kubernetes Service （AKS），您可以在每個節點上使用不同的 Pod 部署，並更新服務定義。
部署持續時間。 部署可能需要較長的時間才能完成，因為戳記包含基礎結構和應用程式，而不只是變更的元件。 不過，這是可以接受的，因為所有元件未如預期般運作的風險超過了對於時間的考慮。
成本影響。 有額外的成本，因為兩個並排的部署必須共存，直到部署完成為止。
流量轉換。 驗證新部署之後，流量必須從藍色環境轉換為綠色環境。 此過渡需要在不同環境間協調管理使用者流量。 轉換應該完全自動化。
生命週期。 任務關鍵性部署戳記應該視為暫時性。 在布建資源之前，使用短暫有效的戳記每次都會創造一個新的開始。
設計建議
採用藍色/綠色部署方法來釋放所有生產變更。 每次針對任何類型的變更部署所有基礎結構和應用程式，以達到一致的狀態和零停機時間。 雖然您可以重複使用環境，但我們不建議用於任務關鍵性工作負載。 將每個區域部署標記視為短暫的，其生命週期會依附於單一版本。
使用全域負載平衡器，例如 Azure Front Door，協調藍綠環境之間的使用者流量自動轉換。
若要轉換流量，請新增綠色後端端點，以使用低流量到磁碟區權數，例如 10%。 在確認綠色部署的低流量運行正常，並提供預期的應用程式健康狀況之後，逐漸增加流量。 這樣做時，請套用較短的逐步提升的時間來捕捉可能不立即明顯的錯誤。
完成所有流量轉換後，從現有連線中移除藍色後端系統。 例如，從全域負載平衡器服務中移除後端、清空佇列，以及解除其他關聯性。 這樣做有助於優化次要生產基礎架構的維護成本，並確保新環境不會出現設定偏差。
此時，終止使用舊的和已停用的藍色環境。 在下一次部署時，將藍色和綠色位置互換來重複此流程。
訂閱範圍部署
視應用程式的規模需求而定，您可能需要多個生產訂用帳戶作為縮放單位。
觀看以下影片以了解如何為任務關鍵應用程式設定訂閱的建議概述。
設計考量
延展性。 針對具有大量流量的高規模應用程式案例，請設計可跨多個 Azure 訂用帳戶進行調整的解決方案，讓單一訂用帳戶的規模限制不會限制延展性。
這很重要
使用多個訂閱會產生額外的 CI/CD 複雜性，必須妥善管理。 因此，我們只在極端規模的情況下建議使用多個訂閱，當此時單一訂閱的限制可能會成為瓶頸。
環境界限。 將生產、開發和測試環境部署到不同的訂用帳戶。 這種做法可確保較低的環境不會對規模限制造成貢獻。 它還通過提供清晰的管理和識別界限，降低低層環境更新污染生產環境的風險。
治理。 當您需要多個生產訂用帳戶時，請考慮使用專用的應用程式管理群組，透過原則匯總界限簡化原則指派。
設計建議
在專用訂用帳戶中部署每個區域部署戳記，以確保訂用帳戶限制僅適用於單一部署戳記的內容，而不是整個應用程式。 在適當情況下，您可能會考慮在單一區域內使用多個部署戳記，但您應該跨獨立訂用帳戶進行部署。
將全域共用資源放在專用訂用帳戶中，以啟用一致的區域訂用帳戶部署。 避免針對主要區域使用特製化部署。
持續驗證和測試
測試是一項重要活動，可讓您完整驗證應用程式程式代碼和基礎結構的健康情況。 更具體來說，測試可讓您符合可靠性、效能、可用性、安全性、品質和規模的標準。 測試必須妥善定義並套用為應用程式設計和 DevOps 策略的一部分。 測試是本機開發人員程式（ 內部迴圈）期間的重要考慮，也是完整 DevOps 生命週期（ 外部迴圈）的一部分，也就是程式代碼從發行管線程序開始到生產環境的路徑時。
檢視下列影片，以取得持續驗證和測試的概觀。
本節著重於外部循環測試。 它描述各種類型的測試。
| 測試 | 說明 |
|---|---|
| 單元測試 | 確認應用程式商業規則如預期般運作。 驗證程式代碼變更的整體效果。 |
| 煙霧測試 | 識別基礎結構和應用程式元件是否可用，並如預期般運作。 一般而言，只會測試單一虛擬用戶會話。 結果應該是系統以預期的值和行為回應。
常見的煙霧測試案例包括連線到 Web 應用程式的 HTTPS 端點、查詢資料庫，以及模擬應用程式中的使用者流程。 |
| UI 測試 | 驗證是否已部署應用程式使用者介面，且使用者介面互動會如預期般運作。
您應該使用UI自動化工具來驅動自動化。 在UI測試期間，腳本應該模擬實際的使用者案例，並完成一系列步驟來執行動作並達成預期的結果。 |
| 負載測試 | 驗證擴展性和應用程式操作的方法是快速或逐步增加負載，直到達到預定的臨界值。 負載測試通常是針對特定使用者流程所設計，以驗證在定義的負載下符合應用程式需求。 |
| 壓力測試 | 套用多載現有資源的活動，以判斷解決方案限制，並確認系統正常復原的能力。 主要目標是找出潛在的效能瓶頸和規模限制。
相反地，相應減少系統的計算資源，並監視它在負載下的行為，並判斷它是否可以復原。 |
| 效能測試 | 結合負載和壓力測試的各個層面，以驗證負載下的效能，並建立應用程式作業的基準檢驗行為。 |
| 混亂測試 | 將人工失敗插入系統，以評估其回應方式，並驗證復原措施、作業程式和風險降低的有效性。
關閉基礎結構元件、故意降低效能，以及引進應用程式錯誤是測試範例，可用來驗證應用程式在實際發生案例時會如預期般回應。 |
| 滲透測試 | 確保應用程式及其環境符合預期的安全性狀態需求。 目標是要識別安全性弱點。
安全性測試可以包含端對端軟體供應鏈和套件相依性，並掃描和監視已知的常見弱點和暴露程度（CVE）。 |
設計考量
自動化。 自動化測試對於以及時且可重複的方式驗證應用程式或基礎結構變更至關重要。
測試順序。 執行測試的順序是一個重要考慮，因為各種相依性，例如需要有執行中的應用程式環境。 測試持續時間也會影響順序。 使用較短運行時間的測試應盡可能早於迴圈中執行，以提高測試效率。
延展性限制。 Azure 服務有不同的軟式和硬性限制。 請考慮使用負載測試來判斷系統在預期生產環境中是否有超過負載限制的風險。 負載測試也可用於設定適當的自動調整閾值。 對於不支援自動調整的服務，負載測試可協助您微調自動化作業程式。
無法適當調整系統元件，例如主動/被動網路元件或資料庫，可能會受到限制。 壓力測試有助於識別限制。
失敗模式分析。 將錯誤引入應用程式和基礎結構，並評估效果對於評估解決方案的備援機制至關重要。 在此分析期間，找出影響的風險、影響和廣度（部分或完整中斷）。 如需針對 任務關鍵在線 參考實作所建立的範例分析，請參閱 個別元件的中斷風險。
監視。 您應該個別擷取和分析測試結果，並匯總它們以評估一段時間的趨勢。 您應該持續評估測試結果的精確度和涵蓋範圍。
設計建議
觀看下列影片，以了解復原測試如何與 Azure DevOps CI/CD 管線整合。
藉由自動化基礎結構和應用程式元件上的所有測試，以確保一致性。 將測試整合到 CI/CD 管線中，以協調並在適當時執行。 如需技術選項的相關信息，請參閱 DevOps工具。
將所有測試成品視為程序代碼。 它們應該與其他應用程式代碼工件一起維護並進行版本控制。
將測試基礎結構的 SLA 與部署和測試週期的 SLA 對齊。
在每個部署中執行煙霧測試。 同時執行廣泛的負載測試以及壓力和混亂測試，以驗證應用程式效能和作性是否已維護。
- 使用反映實際尖峰使用模式的負載配置檔。
- 在進行負載測試的同時執行混沌實驗和失效注入測試。
小提示
Azure Chaos Studio 是混亂實驗工具的原生套件。 這些工具可讓您輕鬆地進行混亂實驗，並在 Azure 服務和應用程式元件中插入錯誤。
Chaos Studio 提供常見錯誤案例的內建混亂實驗，並支援以基礎結構和應用程式元件為目標的自定義實驗。
如果負載或煙霧測試需要資料庫互動，例如建立記錄，請使用具有降低許可權的測試帳戶，並讓測試數據與實際用戶內容分開。
掃描及監視已知 CVE 的端對端軟體供應鏈和套件相依性。
- 使用 Dependabot for GitHub 存放庫，以確保存放庫會隨著其相依的套件和應用程式最新版本自動更新。
基礎結構即程式代碼部署
基礎架構即程式碼 (IaC) 將基礎架構定義當作原始程式碼，與其他應用程式的 artefacts 一起進行版本控制。 使用 IaC 可跨環境提升程式代碼一致性、在自動化部署期間消除人為錯誤的風險，並提供可追蹤性和復原。 對於藍/綠部署，使用 IaC 與完全自動化部署是勢在必行的。
任務關鍵性 IaC 存放庫有兩個不同的定義，這些定義會對應至全域和區域資源。 如需這些類型資源的相關信息，請參閱 核心架構模式。
設計考量
可重複的基礎結構。 以每次產生相同環境的方式部署任務關鍵性工作負載。 IaC 應該是主要模型。
自動化。 所有部署都必須完全自動化。 人為程式容易出錯。
設計建議
套用 IaC，確保宣告式範本中定義所有 Azure 資源，並在原始檔控制存放庫中維護。 範本部署後，資源會透過 CI/CD 管線自動從原始碼控制系統進行配置。 不建議使用命令式腳本。
禁止對所有環境進行手動作業。 唯一的例外狀況是完全獨立的開發人員環境。
DevOps 工具
有效使用部署工具對於整體可靠性至關重要，因為 DevOps 程式會影響整體函式和應用程式設計。 例如，故障轉移和擴展操作可能取決於由 DevOps 工具所提供的自動化。 工程小組必須瞭解部署服務不可用性對整體工作負載的影響。 部署工具必須可靠且高可用性。
Microsoft提供兩個 Azure 原生工具組 GitHub Actions 和 Azure Pipelines，可有效地部署和管理任務關鍵性應用程式。
設計考量
技術功能。 GitHub 和 Azure DevOps 的功能重疊。 您可以一起使用它們來充分利用這兩者。 常見的方法是在使用 Azure Pipelines 進行部署時，將程式代碼存放庫儲存在 GitHub.com 或 GitHub AE 中。
請注意當您使用多個技術時所新增的複雜度。 根據整體可靠性評估豐富的功能集。
區域可用性。 就可靠性上限而言，單一 Azure 區域的相依性代表作業風險。
例如，假設流量分散在兩個區域：區域 1 和區域 2。 區域 2 裝載 Azure DevOps 工具實例。 假設區域 2 發生中斷，導致實例無法使用。 區域 1 會自動處理所有流量，並需要部署額外的擴展單元，以確保良好的故障轉移體驗。 但是因為區域 2 中的 Azure DevOps 相依性，所以無法進行。
數據複寫。 數據，包括元數據、管線和原始程式碼，應該跨區域複寫。
設計建議
這兩種技術都裝載在單一 Azure 區域中，這可能會讓您的災害復原策略受到限制。
GitHub Actions 非常適合建置工作（持續整合），但可能缺少複雜部署工作（持續部署）的功能。 鑑於 Azure DevOps 的豐富功能，我們建議用於重要任務部署。 不過，在評估取捨之後，您應該做出選擇。
定義部署工具的可用性 SLA，並確保與更廣泛的應用程式可靠性需求一致。
針對使用主動/被動或主動/主動部署設定的多區域案例，請確定即使主要區域裝載部署工具組無法使用，故障轉移協調流程和調整作業仍可繼續運作。
分支策略
分支有許多有效的做法。 您應該選擇可確保最大可靠性的策略。 良好的策略可讓平行開發、提供從開發到生產環境的完整路徑，並支援快速發行。
設計考量
將存取降至最低。 開發人員應該在
feature/*和fix/*分支中執行其工作。 這些分支成為變更的入口。 角色型限制應套用至分支，作為分支策略的一部分。 例如，只允許系統管理員建立發行分支或強制執行分支的命名慣例。緊急狀況的加速流程。 分支策略應允許盡快將緊急修復合併至
main。 如此一來，未來的版本就會包含修正，並避免問題再次發生。 請只針對解決緊急問題的次要變更使用此程式，並加以限制使用。
設計建議
優先使用 GitHub 進行原始檔控制。
這很重要
建立分支策略，以至少詳述 功能 工作和 版本，並使用分支政策和權限來確保策略正確執行。
觸發自動化測試程式，在程式碼變更貢獻被接受之前先驗證其貢獻。 小組成員也必須檢閱變更。
將
main分支視為持續向前移動且穩定的分支，主要用於整合測試。- 請確定只透過PR進行
main變更。 使用分支策略來禁止直接提交。 - 每次合併
mainPR時，應該會自動開始針對整合環境進行部署。 - 分支
main應該視為穩定。 從main建立發行在任何時刻應該都是安全的。
- 請確定只透過PR進行
使用從
release/*分支建立的專用main分支，以便發佈到生產環境。release/*分支應該保留在存放庫中，並可用於修補版本發行。記錄 Hotfix 程式，並只在需要時才使用它。 在
fix/*分支中建立修正檔，以便後續合併到發行分支並部署到生產環境。
適用於 DevOps 的 AI
您可以在 CI/CD 管線中套用 AIOps 方法，以補充傳統的測試方法。 這樣做可偵測潛在的回歸或降級，並允許預先停止部署，以防止潛在的負面影響。
設計考量
遙測數據的數量。 CI/CD 管線和 DevOps 程式會針對機器學習模型發出各種不同的遙測。 遙測數據範圍從測試結果和部署結果涵蓋到複合部署階段中測試元件的操作數據。
延展性。 傳統的數據處理方法，例如擷取、轉換、載入（ETL）可能無法調整輸送量，以跟上部署遙測和應用程式可觀察性數據的成長。 您可以使用不需要 ETL 和數據移動的新式分析方法，例如數據虛擬化，來啟用 AIOps 模型的持續分析。
部署變更。 部署中的變更必須儲存，才能自動化分析和與部署結果的相互關聯。
設計建議
定義要收集的 DevOps 程式數據，以及如何分析數據。 遙測，例如測試執行指標以及每次部署內變更的時間序列數據，都很重要。
- 從準備、測試及生產環境揭露應用程序可觀測性數據，以便在 AIOps 模型中進行分析和關聯。
採用 MLOps 工作流程。
開發具備內容感知和相依性感知的分析模型，透過自動化特徵工程來提供預測，以解決架構和行為的變更問題。
在部署管線中將最佳定型模型註冊和部署，使其投入運行。
後續步驟
檢查安全考量。