應用程序的部署與發佈

《持續交付發佈可靠軟件的系統方法》讀書筆記

創建發佈策略

當在項目一開始創建發佈策略的第一個版本時，應該考慮下列內容：

每個環境的部署和發佈都是由誰負責的。
創建一個資產和配置管理策略。
部署時所用技術的描述，運維團隊和開發團隊應該對其達成共識。
實現部署流水線的計劃。
枚舉所有的環境，包括用於驗收測試、容量測試、集成測試、用戶驗收測試的環境，以及每個構建在這些環境中的移動過程。
描述在測試和生產環境中部署時應該遵循的流程，比如提交一個變更申請，以及申請授權等。
對應用程序的監控需求，包括用於通知運維團隊關於應用程序相關狀態的 API 或服務。
討論部署時和運行時的配置方法如何管理，以及它們與自動化部署流程是如何關聯在一起的。
描述應用程序如何與所有外部系統集成。比如，在哪個階段進行集成？作爲發佈過程裏的一份子，如何對這種外部集成進行測試？一旦出現問題，運維人員如何與供應商進行溝通？
如何記錄日誌詳情，以便運維人員能夠確定應用程序的狀態，識別出錯原因。
制定災難恢復計劃，以便在災難發生之後，可以恢復應用程序的狀態。
對軟件的服務級別達成一致，比如，應用程序是否有像故障轉移以及其他高可用性策略等方面的需求。
生產環境的數量大小及容量計劃：應用程序會創建多少數據？需要多少個日誌文件或數據庫？需要多少帶寬或磁盤空間？客戶對響應延遲的容忍度是什麼？
制訂一個歸檔策略，以便不必爲了審計或技術支持而保留生產數據。
如何對生產環境進行首次部署。
如何修復生產環境中出現的缺陷，併爲其打補丁。
如何升級生產環境中的應用程序以及遷移數據。
如何做應用程序的生產服務和技術支持。
...

創建這個策略只是一個開始而已，隨着項目的進行，它也會改變。發佈策略的一個關鍵部分就是發佈計劃，它用來描述如何執行發佈。

發佈計劃

通常來說，第一次發佈風險最高，需要細緻地做個計劃。而這種計劃活動的結果可能是產出一些文檔、自動化腳本或其他形式的流程步驟（procedure），用來保證應用程序在生產環境上的部署過程具有可靠性和可重複性。除了在發佈策略中的這些材料以外，還要包括以下內容：

第一次部署應用程序時所需的步驟。
作爲部署過程的一部分，如何對應用程序以及它所使用的服務進行冒煙測試。
如果部署出現問題，需要哪些步驟來撤銷部署。
對應用程序的狀態進行備份和恢復的步驟是什麼。
在不破壞應用程序狀態的前提下，升級應用程序所需要的步驟是什麼。
如果發佈失敗，重新啓動或重新部署應用程序的步驟是什麼。
日誌文件放在哪裏，以及它包括什麼樣的信息描述。
如何對應用程序進行監控。
作爲發佈的一部分，對必要的數據進行遷移的步驟有哪些。
前一次部署中存在問題的記錄以及它們的解決方案是什麼。

有時候，還要考慮一些其他方面的事情。例如，如果新系統是某個遺留系統的替代品，應該把向新系統遷移用戶的步驟寫下來，另外還有如何停止舊系統，特別是不要忘記制訂一個回滾流程，以應對突發問題。

發佈產品

對於商業產品軟件來說，還有如下一些事情需要考慮：

收費模式。
使用許可策略。
所用第三方技術的版權問題。
打包。
市場活動所需要的材料（印刷材料、網站、播客、博客、新聞發佈會等）。
產品文檔。
安裝包。
銷售和售後支持團隊的準備。

應用程序的部署和晉級

要讓軟件的部署活動能以一種可靠且一致的方式進行，其關鍵在於每次部署時都使用同樣的實踐方法，即使用相同的流程向每個環境進行部署，包括生產環境在內。在首次向測試環境部署時就應該使用自動化部署。寫個簡單的腳本來做這件事，而不是手工將軟件部署到環境中。

首次部署

項目首個迭代的主要目標之一就是在迭代結束時，讓部署流水線的前幾個階段可以運行，且能夠部署並展示一些成果，即使可展示的東西非常少。儘管我們不建議讓技術價值的優先級高於業務價值的優先級，但此時是個例外。

對發佈過程進行建模並讓構建晉級

隨着應用程序變得越來越複雜，部署流水線的實現也會越來越複雜。

需要考慮的細節：

爲了達到發佈質量，一個構建版本要通過哪些測試階段（例如，集成測試、QA 驗收測試、用戶驗收測試、試運行以及生產環境）；
每個階段需要設置什麼樣的晉級門檻或需要什麼樣的簽字許可；
對於每個晉級門檻來說，誰有權批准讓某個構建通過該階段；

部署回滾和零停機發布

萬一部署失敗，回滾部署是至關重要的。在運行的生產環境中通過調試直接查找問題的這種做法幾乎總會導致晚上加班、具有嚴重後果的錯誤和用戶的不滿。當出現問題時，你應該有某種方法恢復服務，以便自己能在正常的工作時間內調試所發現的錯誤。

聲明兩個重要的約束，首先是數據，如果發佈流程會修改數據，回滾操作就比較困難。另一個是需要與其他系統集成。如果發佈中涉及兩個以上的系統，回滾流程也會變得比較複雜。

當制定發佈回滾計劃時，需要遵循兩個通用原則。首先，在發佈之前，確保生產系統的狀態（包括數據庫和保存在文件系統中的狀態）已備份。其次，在每次發佈之前都練習一下回滾計劃，包括從備份中恢復或把數據庫備份遷移回來，確保這個回滾計劃可以正常工作。

通過重新部署原有的正常版本來進行回滾

如果你有自動化部署應用程序的流程，讓應用程序恢復到良好狀態的最簡單方法就是從頭開始把前一個沒有問題的版本重新部署一遍。這包括重新配置運行環境，讓它能夠完全和從前一樣。

零停機發布

零停機發布（也稱爲熱部署），是一種將用戶從一個版本幾乎瞬間轉移到另一個版本上的方法。更重要的是，如果出了什麼問題，它還要能在瞬間把用戶從這個版本轉回到原先的版本上。

零停機發布的關鍵在於將發佈流程中的不同部分解耦，儘量使它們能獨立發生。尤其是，在升級應用程序之前，就應該能將應用程序所依賴的共享資源（比如數據庫、服務和一些靜態資源）的新版本放在適當的位置。

藍綠部署

有兩個相同的生產環境版本，一個叫做 “藍環境”，一個叫做 “綠環境”。

系統的用戶被引導到當前正在作爲生產環境的綠環境中。現在我們要發佈一個新版本，所以先把這個新版本發佈到藍環境中，然後讓應用程序先熱身一下（你想多長時間都行），這根本不會影響綠環境。我們可以在藍環境上運行冒煙測試，來檢查它是否可以正常工作。當一切準備就緒以後，向新版本遷移就非常簡單了，只要修改一下路由配置，將用戶從綠環境導向藍環境即可。這樣，藍環境就成了生產環境。這種切換通常在一秒鐘之內就能搞定。

在做這種藍綠部署時，要小心管理數據庫。通常來說，直接從綠數據庫切換到藍數據庫是不可能的，因爲如果數據庫結構有變化的話，數據遷移要花一定的時間。解決這個問題的一種方法是在切換之前暫時將應用程序變成只讀狀態一小段時間。然後把綠數據庫複製一份，並恢復到藍數據庫中，執行遷移操作，再把用戶切換到藍系統。如果一切正常，再把應用程序切換到讀寫方式。如果出了什麼問題，只要把它再切回綠數據庫就可以了。

金絲雀發佈

金絲雀發佈就是把應用程序的某個新版本部署到生產環境中的部分服務器中，從而快速得到反饋。這是一個能大大減少新版本發佈風險的方法。

緊急修復

總會遇到這種情況：發現了一個嚴重的缺陷，必須儘快修復。此時，需要牢記在心的最重要的事情是：任何情況下，都不能破壞流程。緊急修復版本也要走同樣的構建、部署、測試和發佈流程，與其他代碼變更沒什麼區別。

爲什麼這麼說呢？因爲我們看到過很多場合，修復版本直接被放到生產環境中，而產生一個未受控版本。這會導致兩個不幸的後果。首先是這種緊急修改沒有做適當的測試，可能引發迴歸問題，或者該補丁不但沒有修復問題，反而引起了更嚴重的問題。

有時候並不真正需要緊急修復一個缺陷。你需要考慮多少人會受到缺陷的影響，這個缺陷是否經常發生，發生後對用戶有多大的影響。如果缺陷隻影響少數人，而且發生頻率不高，影響較低，而部署一個新版本的風險相對較高的話，可能就沒有必要做緊急修復了。當然，通過有效的配置管理和自動部署過程來減少部署風險還有一些爭議。

持續部署

使用部署流水線，並讓最後一步（部署到生產環境）也自動化。這樣，如果某次提交的代碼通過了所有的自動化測試，就直接部署到生產環境中。如果想讓這種做法不引發問題，自動化測試（應該包括自動化的單元測試、組件測試、功能性和非功能性驗收測試）就必須異乎尋常的強大，覆蓋整個應用程序。必須先寫所有的測試（包括驗收測試），然後再寫代碼。這樣你才能做到，只有用戶故事完成的最後那次代碼提交才能使驗收測試通過。

持續部署可以與金絲雀發佈結合使用。首先通過一個自動化過程將一個新版本發佈給一小撮用戶使用。一旦確認（可能是人爲決策）新版本沒有問題，就把它發佈給所有的用戶。由良好的金絲雀發佈系統提供的這層安全網讓持續部署的風險甚至更小。

小貼士和竅門

真正執行部署操作的人應該參與部署過程的創建；
記錄部署活動；
不要刪除舊文件，而是移動到別的位置；
部署是整個團隊的責任；
服務器應用程序不應該有 GUI；
爲新部署留預熱期；
快速失敗；
不要直接對生產環境進行修改；

小結

只要權限正確的話，部署流水線應該能夠通過 “單擊按鈕” 就能將任意一個已通過前面幾個階段的構建版本部署到任意一種環境中。還應該讓團隊中的每個人都明確地看到哪個構建版本被部署到了哪個環境中，該構建版本包含哪些修改。

降低發佈風險的最佳方法是真正地做發佈演練。越頻繁地將應用程序發佈到不同的測試環境中越好。尤其是，你越頻繁地將應用程序發佈到新的測試環境上，這個過程就越可靠，從而在生產環境上發佈時遇到問題的可能性就越小。

發佈計劃最關鍵的部分是將來自組織各部門參與交付的代表組織起來：構建、基礎設施、運維團隊、開發團隊、測試團隊、DBA 和技術支持團隊。在整個項目週期中，這些人應該不斷地交流，持續合作，從而使交付過程更加高效。