有時，發布並沒有達到預期。 儘管使用了最佳實踐並通過了所有品質門，但偶爾還是會出現問題，導致生產部署對使用者造成不可預見的問題。 為了最大限度地減少和減輕這些問題的影響，鼓勵 DevOps 團隊採用 漸進式暴露 策略，以平衡給定版本的暴露與其經過驗證的效能。 當一個版本在生產中證明自己時，它就會被更廣泛的受眾層使用，直到每個人都使用它。 團隊可以使用安全的部署做法，以最大限度地提高生產環境中發行的品質和速度。
控制對客戶的暴露
DevOps 小組可以採用各種做法來控制更新向客戶的公開。 從歷史上看，A/B 測試一直是希望了解不同版本的服務或使用者介面如何實現目標的團隊的熱門選擇。 A/B 測試也相對容易使用，因為這些變更通常很小，而且通常只會比較服務面向客戶邊緣的不同版本。
透過層級安全部署
隨著平台的發展，基礎設施規模和受眾需求也趨於增長。 這就產生了對部署模型的需求，該模型可以平衡與新部署相關的風險與其承諾的更新的好處。 總體思路是，給定版本應該首先只公開給風險承受能力最高的一小群用戶。 然後，如果版本如預期般運作，則可以公開給更廣泛的使用者群組。 如果沒有問題，則該過程可以通過更廣泛的用戶組或 層繼續進行，直到每個人都使用新版本。 使用 GitHub Actions 和 Azure Pipelines 等新式持續傳遞平臺，任何規模的 DevOps 小組都可以存取具有層級的部署程式。
功能旗幟
某些功能有時需要部署為版本的一部分，但最初不會公開給使用者。 在這些情況下， 功能旗標 會提供解決方案，其中可根據環境、層或任何其他特定部署，透過設定變更來啟用功能。
使用者選擇加入
與功能旗標類似，使用者選擇加入提供限制曝光的方法。 在此模型中，會在版本中啟用給定功能，但除非使用者特別需要，否則不會為使用者啟用。 風險承受能力決策會卸載給使用者，以便他們決定要採用特定更新的速度。
通常同時採用多種做法。 例如，團隊可能有一個實驗性功能，用於非常特定的使用案例。 由於它有風險，他們會將其部署到第一層供內部用戶試用。不過，即使功能位於程式碼中，有人仍需要為層內的特定部署設定功能旗標，以便透過使用者介面公開功能。 即便如此，功能旗標可能只會公開使用者選擇加入使用新功能的選項。 任何不在該層、該部署中或尚未選擇加入的人員都不會公開此功能。 雖然這是一個相當做作的例子，但它有助於說明漸進式曝光的靈活性和實用性。
團隊早期面臨的常見問題
隨著團隊轉向更敏捷的 DevOps 實踐，他們可能會遇到與其他從傳統整合型交付遷移的人一致的問題。 習慣於每隔幾個月部署一次的團隊有一種緩衝穩定的心態。 他們預計每次部署都會對其服務進行重大轉變，並且會出現不可預見的問題。
有效載荷太大
每隔幾個月部署一次的服務通常充滿許多變更。 這增加了出現直接問題的可能性，並且由於有很多新東西而難以解決這些問題。 透過移至更頻繁的傳遞，部署內容的差異會變得更小，從而可以進行更集中的測試和更輕鬆的偵錯。
無服務隔離
傳統上，單體系統是透過升級部署它們的硬體來擴展的。 然而，當實例出現問題時，就會給每個人帶來問題。 一個簡單的解決方案是新增多個執行個體，以便您可以對使用者進行負載平衡。 不過，這可能需要重要的架構考量，因為許多舊版系統並非建置為多執行個體。 此外，可能需要為可以在其他地方更好地整合的功能分配大量重複資源。
隨著新功能的新增，請探索 微服務架構 是否可以幫助您操作和擴展，這要歸功於更好的服務隔離。
手動步驟會導致錯誤
當團隊每年只部署幾次時，自動化交付似乎不值得投資。 因此，許多部署程序都是手動管理的。 這需要大量的時間和精力，並且容易出現人為錯誤。 只需自動化最常見的建置和部署任務，就可以大大減少時間損失和非受迫錯誤。
團隊還可以利用 基礎設施即代碼 來更好地控制部署環境。 這消除了向營運團隊請求手動變更的需要，因為新功能或相依性被引入各種部署環境。
只有 Ops 可以進行部署
某些組織的原則要求所有部署都由營運人員起始和管理。 雖然過去可能有充分的理由，但當開發團隊可以啟動和控制部署時，敏捷 DevOps 流程會大有裨益。 現代 持續交付 平台可精細控制誰可以起始哪些部署，以及誰可以存取狀態記錄和其他診斷資訊，確保正確的人員盡快獲得正確的資訊。
錯誤的部署會繼續進行，且無法復原
有時部署出錯，團隊需要解決它。 不過，當程序是手動的，且資訊存取緩慢且有限時，可能很難復原至先前的工作部署。 幸運的是，有各種工具和 實踐 可以降低部署失敗的風險。
核心原則
希望採用安全部署實踐的團隊應該設定一些核心原則來支持這項工作。
保持一致
用於在生產環境中部署的相同工具應該用於開發和測試環境。 如果存在問題，例如經常由新版本的依賴項或工具引起的問題，則應在程式碼接近發佈到生產環境之前就發現它們。
關心質量信號
太多的團隊陷入了不真正關心質量信號的常見陷阱。 隨著時間的推移，他們可能會發現他們編寫測試或承擔質量任務只是為了將黃色警告更改為綠色批准。 質量信號非常重要，因為它們代表了項目的脈搏。 用於核准部署的品質訊號應每天持續追蹤。
部署應該需要零停機時間
雖然每項服務始終可用並不重要，但團隊應該以這樣一種心態來處理他們的 DevOps 交付和運營階段，即他們可以而且應該部署新版本，而不必隨時將其關閉。 現代基礎設施和管道工具現在已經足夠先進，幾乎任何團隊都可以實現 100% 正常運行時間的目標。
部署應該在工作時間內進行
如果團隊以部署需要零停機時間的心態工作，那麼何時推送部署並不重要。 此外，在工作時間推送部署變得有利，尤其是在一天的早些時候和一周的早些時候。 如果出現問題，應儘早追蹤以控制爆炸半徑。 此外，每個人都已經在工作並專注於解決問題。
層型部署
具有成熟 DevOps 發行做法的小組能夠進行層型部署。 在此模型中，新功能會先推出給願意接受最大風險的客戶。 隨著部署得到驗證，對象會擴大以包含更多使用者，直到每個人都使用它為止。
層級模型範例
典型的層部署模型旨在透過仔細區隔使用者和基礎結構來儘早發現問題。 下列範例顯示 Microsoft 的主要小組如何使用層。
| 層 | 目標 | 使用者 | 資料中心 |
|---|---|---|---|
| 0 | 尋找部署所引進的大部分影響使用者的錯誤 | 僅內部，對風險和錯誤的高容忍度 | 美國中西部 |
| 1 | 小組未廣泛測試的區域 | 使用廣泛產品的客戶 | 小型資料中心 |
| 2 | 規模相關問題 | 公共帳戶，最好是使用多種功能的免費帳戶 | 中型或大型資料中心 |
| 3 | 內部帳目及國際相關議題的規模問題 | 大型內部客戶和歐洲客戶 | 內部資料中心和歐洲資料中心 |
| 4 | 剩餘的縮放單位 | 其他人 | 所有部署目標 |
允許烘烤時間
烘焙時間一詞是指在擴展到下一層之前允許部署運行的時間量。 有些問題可能需要數小時或更長時間才能開始出現症狀，因此該版本應使用適當的時間，然後才被視為準備就緒。
一般來說，一天 24 小時應該足以讓大多數場景暴露潛在錯誤。 不過，此期間應包括高峰使用時段，對於在工作時間內達到尖峰的服務，需要一整天。
加速修補程式
當錯誤對生產環境產生嚴重影響時，就會發生 即時站點事件 （LSI）。 LSI 需要建立 修補程式，這是旨在解決高優先順序問題的頻外更新。
如果 Bug 是 Sev 0 （最嚴重的 Bug 類型），則 Hotfix 可能會以負責任的方式儘快直接部署至受影響的縮放單位。 雖然修復不會使事情變得更糟至關重要，但這種嚴重性的錯誤被認為具有破壞性，因此必須立即解決。
評等為 Sev 1 的 Bug 必須透過第 0 層部署，但只要核准，就可以立即部署至受影響的縮放單位。
嚴重性較低的錯誤的 Hotfix 必須按計劃部署在所有層級中。
重點摘要
每個團隊都希望以盡可能高的品質快速提供更新。 透過正確的做法，交付可以成為 DevOps 週期中富有成效且輕鬆的一部分。
- 經常部署。
- 在整個衝刺過程中保持綠色。
- 在開發、測試和生產中使用一致的部署工具。
- 使用允許自動化和授權的持續交付平台。
- 遵循安全部署做法。
後續步驟
瞭解 功能旗標 如何協助控制新功能向使用者公開。