安全部署實務

有時候版本不會滿足預期。 儘管使用最佳做法並傳遞所有品質網關，但偶爾會有問題導致生產部署造成使用者無法預見的問題。 為了將這些問題的影響降到最低並減輕，鼓勵 DevOps 小組採用 漸進式曝光 策略，以平衡特定版本的曝光率與其經過證實的效能。 隨著版本在生產環境中證明自己，在每個人都使用它之前，它就可供更廣泛的物件層使用。 Teams 可以使用安全的部署做法，以將生產環境中發行的品質和速度最大化。

控制客戶曝光

DevOps 小組可以採用各種做法來控制對客戶的更新曝光。 在過去，A/B 測試一直是小組的熱門選擇，想要瞭解不同版本的服務或使用者介面如何針對目標目標執行。 A/B 測試也相對容易使用，因為變更通常是次要的，而且通常只會比較服務面向客戶邊緣的不同版本。

透過通道 保管庫 部署

隨著平臺的成長，基礎結構規模和物件需求也通常會成長。 這會建立部署模型的需求，以平衡與新部署相關聯的風險，以及其承諾的更新優點。 一般概念是，指定的版本應該先公開給一小群具有最高風險承受能力的使用者。 然後，如果發行如預期般運作，它可以公開給更廣泛的使用者群組。 如果沒有問題，則程式可以繼續透過更廣泛的使用者群組或 通道，直到每個人都使用新版本為止。 使用 GitHub Actions 和 Azure Pipelines 等現代化持續傳遞平臺，使用通道建置部署程式可供任何規模的 DevOps 小組存取。

功能旗幟

某些功能有時需要部署為發行的一部分，但一開始不會公開給使用者。 在這些情況下，功能旗標會提供解決方案，其中可根據環境、通道或任何其他特定部署，透過組態變更來啟用功能。

使用者選擇加入

與功能旗標類似，使用者選擇加入提供限制曝光的方式。 在此模型中，特定功能會在版本中啟用，但除非用戶特別想要此功能，否則不會為使用者啟用此功能。 風險承受能力決策會卸除給使用者，以便他們決定想要採用特定更新的速度。

通常會同時採用多個做法。 例如，小組可能有一個實驗性功能，適用於非常特定的使用案例。 由於風險高，他們會將其部署到第一個通道，供內部使用者試用。不過，即使功能位於程式代碼中，仍需要有人設定通道內特定部署的功能旗標，以便透過使用者介面公開該功能。 即便如此，功能旗標可能只會公開用戶選擇使用新功能的選項。 任何不在通道、該部署或未選擇加入的人員都不會公開至此功能。 雖然這是一個相當陰謀的例子，但它有助於說明漸進式曝光的彈性和實用性。

小組早期面臨的常見問題

當小組走向更敏捷的 DevOps 實務時，他們可能會遇到與已從傳統整合型交付移轉的其他人一致的問題。 用來每隔幾個月部署一次的 Teams 有一種緩衝穩定心態。 他們預期每個部署都會在其服務中帶來大幅轉變，而且會有無法預見的問題。

承載太大

每隔幾個月部署的服務通常會填入許多變更。 這增加了將立即發生問題的可能性，也使得很難針對這些問題進行疑難解答，因為有這麼多的新內容。 藉由移至更頻繁的傳遞，所部署項目的差異會變得更小，這可讓您進行更專注的測試，並更輕鬆地進行偵錯。

無服務隔離

整合型系統傳統上會藉由相應增加部署所在的硬體來調整規模。 不過，當實例發生問題時，這會導致每個人遇到問題。 一個簡單的解決方案是新增多個實例，以便平衡用戶負載。 不過，這可能需要大量的架構考慮，因為許多舊版系統不會建置成多重實例。 此外，可能需要配置大量重複的資源，才能在其他地方更妥善地合併功能。

隨著新功能的新增，探索微服務架構是否可協助您操作和調整，這要歸功於更好的服務隔離。

手動步驟會導致錯誤

當小組每年只部署幾次時，自動化交付似乎並不值得投資。 因此，會手動管理許多部署程式。 這需要大量的時間和精力，而且容易發生人為錯誤。 只要將最常見的建置和部署工作自動化，就能大幅減少遺失的時間和未強制執行的錯誤。

Teams 也可以使用 基礎結構即程序代碼 ，以更妥善地控制部署環境。 這可移除作業小組要求進行手動變更的需求，因為新功能或相依性會引入各種部署環境。

只有 Ops 可以進行部署

某些組織有原則，需要由作業人員起始和管理所有部署。 雖然過去可能有充分的理由，但當開發小組可以起始和控制部署時，敏捷式DevOps程式會有很大的好處。 新式 持續傳遞 平臺可細微控制誰可以起始哪些部署，以及誰可以存取狀態記錄和其他診斷資訊，確保正確的人員儘快擁有正確的資訊。

不正確的部署繼續進行且無法回復

有時候部署發生錯誤，小組需要加以解決。 不過，當程式是手動的，而且資訊存取速度緩慢且有限時，可能會難以回復到先前的工作部署。 幸運的是，有各種工具和 做法 可降低部署失敗的風險。

核心原則

想要採用安全部署做法的小組應設定一些核心原則來支撐工作。

保持一致

用於生產環境部署的相同工具應該用於開發和測試環境中。 如果發生問題，例如通常來自新版本相依性或工具的相依性，在程式代碼即將發行至生產環境之前，應該先攔截它們。

關心質量訊號

太多團隊陷入不真正關心品質信號的共同陷阱。 經過一段時間，他們可能會發現他們撰寫測試或處理品質工作，只是為了將黃色警告變更為綠色核准。 質量訊號非常重要，因為它們代表項目的脈搏。 用來核准部署的品質訊號應該每天持續追蹤。

部署應該需要零停機時間

雖然每個服務都並非重要，但小組應該以他們能夠且應該部署新版本的心態來接近其 DevOps 傳遞和作業階段，而不需要隨時將其關閉。 現代化基礎結構和管線工具現在已足夠進階，幾乎任何小組都可以以 100% 運行時間為目標。

部署應該在工作時間進行

如果小組採用部署需要零停機的心態，則在推送部署時並不重要。 此外，在工作時間推部署會變得有利，尤其是在一天和一周初。 如果發生問題，應該儘早追蹤，以控制爆炸半徑。 此外，每個人都已經工作，並專注於獲得修正的問題。

通道式部署

具有成熟 DevOps 發行作法的 Teams 能夠採用通道式部署。 在此模型中，新功能會先推出給願意接受最大風險的客戶。 隨著部署經過證實，物件會擴充為包含更多使用者，直到每個人都使用它為止。

範例通道模型

一般通道部署模型的設計目的是要透過仔細分割使用者和基礎結構來找出問題。 下列範例示範 Microsoft 主要小組如何使用通道。

通道	目的	使用者	資料中心
0	尋找部署所引進的大部分使用者影響錯誤	僅限內部、高承受風險和 Bug	美國中西部
1	小組不會廣泛測試的區域	使用產品廣度的客戶	小型數據中心
2	調整相關問題	公用帳戶，在理想情況下，使用一組不同的功能免費帳戶	中型或大型數據中心
3	調整內部帳戶和國際相關問題的問題	大型內部帳戶和歐洲客戶	內部數據中心和歐洲數據中心
4	剩餘縮放單位	別人	所有部署目標

允許製作時間

「製作時間」一詞是指在擴充至下一個通道之前，允許部署執行的時間量。 某些問題可能需要數小時或更長的時間才能開始顯示徵兆，因此發行應該在考慮就緒之前使用適當的時間。

一般而言，24 小時的時間應該足以讓大多數案例公開潛在 Bug。 不過，此期間應包含尖峰使用量的期間，需要整整一個工作天，才能在上班時間達到尖峰的服務。

加速 Hotfix

當 Bug 對生產環境造成嚴重影響時，就會發生即時網站事件（LSI）。 LSIS 需要建立 Hotfix，這是專為解決高優先順序問題而設計的頻外更新。

如果 Bug 是 Sev 0，這是最嚴重的 Bug 類型，則 Hotfix 可能會儘快部署至受影響的縮放單位。 雖然修正程式不會讓情況變得更糟，但此嚴重性的 Bug 會被視為干擾性，因此必須立即加以解決。

評為 Sev 1 的 Bug 必須透過通道 0 進行部署，但之後可以在核准後立即部署到受影響的縮放單位。

具有較低嚴重性之 Bug 的 Hotfix 必須如計畫般透過所有通道進行部署。

重要心得

每個小組都希望以最快的品質快速提供更新。 透過正確的做法，傳遞可以是 DevOps 週期的生產力和無痛部分。

• 經常部署。
• 在整個短期衝刺中保持綠色。
• 在開發、測試和生產環境中使用一致的部署工具。
• 使用允許自動化和授權的持續傳遞平臺。
• 遵循安全部署做法。

下一步

瞭解功能旗標如何協助控制對使用者的新功能曝光。