透過版本設定的服務更新來消除停機時間

在過去，系統管理員需要讓伺服器離線，才能更新和升級內部部署軟體。 不過，停機時間是全域 24×7 服務的完整非啟動程式。 許多新式雲端服務是使用者執行其業務的重要相依性。 從來沒有好時機讓系統關閉，所以小組如何在安裝重要的安全性和功能更新時提供持續服務？

藉由使用版本設定的更新，這些重要服務可以順暢地從一個版本轉換到另一個 版本，而客戶會主動使用這些服務。 並非所有更新都很難。 更新前端版面配置或樣式很簡單。 對功能的變更可能很棘手，但有已知做法可降低移轉風險。 不過，數據層產生的變更引進了需要特殊考慮的新挑戰類別。

個別更新圖層

在多個數據中心和個別的數據記憶體中使用分散式在線服務，並非所有專案都可以同時變更。 如果一般服務分割成應用程式程式代碼和資料庫，這大概是彼此獨立版本設定，其中一個雙方必須吸收處理版本設定的複雜性。

版本控制通常更容易在應用程式程式代碼中處理。 較大的系統通常會有相當多的舊版程序代碼，例如存在於其資料庫內的SQL。 應用程式程式代碼應該處理複雜度，而不是進一步使這個 SQL 複雜化。 具體而言，您可以建立一組瞭解 SQL 版本設定的 Factory 類別。

在每個短期衝刺期間，使用該版本建立新的介面，因此一律會有符合每個資料庫版本的程序代碼。 您可以在部署期間輕鬆地復原任何二進位檔。 如果在部署新的二進位檔之後發生問題，請還原為先前的程序代碼。 如果二進位部署成功，請啟動資料庫服務。

那麼，這實際上如何運作？ 例如，假設您的小組目前正在部署Sprint 123。 二進位檔瞭解 Sprint 123 資料庫架構，並瞭解 Sprint 122 架構。 一般模式是使用 SQL 架構的版本/短期衝刺 N 和 N-1。 二進位檔會查詢資料庫、判斷要與其交談的架構版本，然後載入適當的系結。 然後，應用程式程式代碼會處理新數據架構尚無法使用的情況。 一旦有新版本可用，應用程式程式代碼就可以開始使用最新資料庫版本所啟用的新功能。

僅使用數據層向前復原

升級資料庫之後，如果發生問題，服務就會處於 向前 復原狀態。 在線資料庫移轉很複雜，而且通常是多步驟，因此向前復原通常是解決問題的最佳方式。 換句話說，如果升級失敗，則復原也可能會失敗。 投資建置和測試小組從未預期使用的復原程式代碼，沒有什麼價值。

部署順序

假設您需要將一組數據行新增至資料庫，並轉換某些數據。 用戶必須看不見此轉換，這表示盡可能避免數據表鎖定，然後盡可能最短地保留鎖定，使其無法察覺。

我們做的第一件事是操作數據，可能是使用 SQL 觸發程式來讓數據保持同步的平行數據表。大型數據遷移和轉換有時必須跨多個短期衝刺跨數個部署進行多重步驟。

一旦平行建立額外的數據或新的架構，小組就會進入 應用程式程式代碼的部署模式 。 在部署模式中，當程式代碼呼叫資料庫時，它會先擷取架構的鎖定，然後在執行預存程式之後釋放它。 資料庫無法在發出資料庫呼叫和預存程式執行時變更。

升級程式代碼可作為架構寫入器，並要求架構上的寫入器鎖定。 應用程式程式代碼優先於取得讀取器鎖定，而升級程式代碼位於嘗試取得寫入器鎖定的背景中。 在寫入器鎖定下，數據表上只允許少量非常快速的作業。 然後會釋放鎖定，應用程式會記錄新版本的資料庫正在使用中，並使用符合新資料庫版本的介面。

資料庫升級全都使用移轉模式執行。 一組程式代碼和文本會查看資料庫版本，然後進行累加變更，以將架構從舊版移轉至新版本。 所有移轉都會自動化，並透過發行管理服務推出。

Web UI 也必須更新，而不會中斷使用者。 升級 JavaScript 檔案、樣式表單或影像時，請避免混合用戶端載入舊版和新版本。 這可能會導致工作失敗的錯誤，例如使用者正在編輯的欄位。 因此，您應該將所有與部署相關聯的檔案放入個別的版本化資料夾，來設定所有 JavaScript、CSS 和映像檔案的版本。 當 Web UI 回呼應用層時，會載入具有指定版本的資產。 只有當使用者動作導致完整頁面重新整理時，新的 Web UI 才會載入瀏覽器。 升級不會中斷用戶體驗。

下一步

Microsoft 幾十年來一直是世界上最大的軟體開發公司之一。 瞭解 Microsoft 如何使用 DevOps 運作可靠的系統。