1. 部署行為是系統生命的重要組成部分

1.1. 只編寫代碼是不夠的，只要沒有在生產環境中運行，一切都不算完成

1.2. 要想取得成功，需要早早地頻繁部署軟體

1.3. 設計易於部署的軟體非常有必要

1.4. 零停機部署就是目標

2. 機器與服務

2.1. 機器是可配置的操作系統實例

2.1.1. 如果系統在真正的機器上運行，那麼這就意味著物理主機

2.1.2. 如果系統在虛擬機、容器或unikernel上運行，那麼這些就是單元

2.2. 服務是供其他系統使用的可調用介面

2.2.1. 由在多台機器上運行的軟體的冗餘副本組成

2.3. 我們的環境擁有比以往更多的機器，而且大部分都是虛擬的

2.4. 有些機器是其他機器創建的，所以運維人員從未接觸

3. 計劃停機時間的謬誤

3.1. 不能計劃一次或幾次就完成部署，而應該每次一點逐步疊加地進行多次部署

3.2. 更新系統的過程需要花費時間

3.3. 要將部署視為軟體的一個特性

3.3.1. 不能只為了最終狀態而編寫代碼，然後將代碼交給運維部門，讓他們搞清如何在生產環境中運行這些程式

4. 自動化部署

4.1. 構建流水線

4.1.1. 將代碼變更提交到版本控制系統後，構建流水線就會啟動

4.1.2. 產品

4.1.2.1. Jenkins可能是如今最常用的工具

4.1.2.2. ThoughtWorks的GoCD

4.1.2.3. Netflix公司的Spinnaker

4.1.2.4. 亞馬遜的AWS Code Pipeline

4.2. 不要試圖去找最好的工具，而應該選擇一個足夠滿足需要的，然後好好加以利用

4.3. 由於服務可以在具有不同IP地址的任意數量的不同機器上運行，因此平臺還必須配置網路，實現負載均衡和流量路由

4.4. 如果使用不可變的基礎設施，那麼一般從基本的操作系統鏡像開始部署

4.4.1. 此時並不是試圖從未知狀態收斂到預期狀態

4.4.2. 始終從已知狀態——主操作系統鏡像——開始

4.5. 不可變的基礎設施與IaaS、PaaS以及自動化映射是高度一致的

4.6. 狀態收斂在物理機器部署、長壽命虛擬機器和手動映射中則更為常見

5. 持續部署

5.1. 未部署的代碼

5.1.1. 未完成的庫存

5.1.2. 有著未知的缺陷

5.1.3. 會令容量擴展失效

5.1.4. 會導致生產環境出問題

5.1.5. 也可能很好地實現一個沒人想要的功能

5.2. 從開發人員向代碼庫提交代碼到代碼最終在生產環境中運行，這段時間的代碼最為棘手

5.2.1. 持續部署就是儘可能地縮短上述時間段，儘可能地減少未部署代碼引發的問題

5.3. 持續不間斷地部署所有代碼

5.3.1. 意味著每次提交代碼，都要運行完整的構建流水線

5.4. 如果放慢軟體發佈進度耗費的成本，超過部署軟體中彌補錯誤需要的成本，那麼通過流水線自動將代碼部署到生產環境更合適

5.5. 由代碼錯誤造成的成本，可能會遠遠大於在競爭中較慢地發佈軟體的成本，此時在部署到生產環境之前進行人工檢查更為合理

5.5.1. 要確保掌管授權按鈕的人能隨時待命

6. 部署中的各個階段

6.1. 部署PHP應用程式，就是簡單地把文件複製到生產主機上，然後下一個訪問該主機的請求就會訪問這些新文件

6.1.1. 當請求訪問尚未完成複製的文件時，該如何處理

6.2. 相比複製軟體包文件並重新啟動應用程式容器，複製沒有運行時進程的單個文件速度更快

6.3. 粒度越大，安裝和激活軟體所需的時間就越長

6.4. 微觀時間尺度適用於單個實例（主機、虛擬機或容器）

6.5. 巨集觀時間尺度適用於這個版本的整體推送

6.6. 對於可變的基礎設施，這意味著將文件複製到位，從而能夠快速更新符號鏈接或目錄引用

6.7. 對於不可變的基礎設施，這就是部署新鏡像所需的時間

6.8. 會話可以保持活動的時間長度可以沒有上限，特別是當你無法區分訪問者是人類還是機器人或網路爬蟲的時候，尤其如此

6.9. 一旦將部署視為一段時間內的工作，就可以讓應用程式協助完成自身的部署

7. 關係資料庫模式

7.1. 完全安全的資料庫模式的變更是

7.1.1. 添加一個表格

7.1.2. 添加視圖

7.1.3. 在表中添加一個可空列

7.1.4. 添加別名或同義詞

7.1.5. 添加新的存儲過程

7.1.6. 添加觸發器

7.1.7. 將現有數據複製到新的表格或列中

7.1.8. 資料庫模式變更的擴充階段

7.1.8.1. 當前應用程式不會使用這些變更中的任何內容

7.2. 墊片

7.2.1. 一些有助於連接應用程式舊版本和新版本的代碼

7.3. 對測試來說，除了支持前滾，最好也要支持回滾

7.4. 不要忘記在真實的數據樣本上測試資料庫的模式變更

7.5. 測試時絕對不要依賴應用程式當前所謂的合法資料庫模式

7.5.1. 會有用戶最近10年從未登錄過，所以現在必填的一些欄位對他們來說就是一堆空值

7.6. 總會存在一些當前的應用程式絕對無法生成的數據，這就是必須要針對真實生產數據的副本進行測試的原因

8. 無模式資料庫

8.1. 對資料庫引擎而言，無模式資料庫僅僅無模式而已，但對應用程式來說，就完全是另一回事了

8.2. 隨著時間的推移，應用程式很有可能也在不斷演化，原來舊版本的數據文檔現在可能都不可讀了

8.2.1. 編寫應用程式，使其能夠讀取任何時間創建的版本

8.2.1.1. 所有版本之間的轉換都必須經過測試，這意味著需要保留舊文檔作為測試的種子數據

8.2.1.2. 隨著流水線越來越深，翻譯時間會線性增加

8.2.2. 編寫部署期間在整個資料庫運行的遷移常式

8.2.2.1. 舊實例讀取舊文檔，沒問題

8.2.2.2. 新實例讀取舊文檔，沒問題

8.2.2.3. 新實例讀取新文檔，沒問題

8.2.2.4. 舊實例讀取新文檔，會出大問題

8.2.3. 先滴流再批量

8.2.3.1. 這個策略不會對所有文檔進行一次大規模的遷移

8.2.3.2. 通過在應用程式新版本中添加一些條件碼，遷移運行過程中涉及的那些文檔

8.2.3.3. 在生產環境實行了一段時間的“先滴流再批量”之後，就會發現最活躍的文檔都已更新

8.2.3.4. 此時就可以對其餘文檔執行批量遷移，這可以與生產環境同時運行，不會產生危險，因為此時沒有舊實例參與

8.2.3.5. 優點

8.2.3.5.1. 能實現快速部署新的應用程式版本，無須停機進行數據遷移

8.2.3.5.2. 能在不中斷服務的情況下部署代碼，因此當不再需要遷移測試時，能夠將其刪除

8.2.3.6. 缺點

8.2.3.6.1. 不能對相同的文檔類型執行不同的重覆滴流遷移操作

8.2.3.6.2. 當面對一些較大的設計變更時，需要將其分散到多個版本中來實現

8.2.3.7. 對於任何大型遷移——通常在部署過程中執行時間很長——都可以採用這種方法

9. 讓人類定義規則，讓機器貫徹規則

9.1. 實現自動化操作和質量檢查

9.2. 運維工作與開發工作已經變得難解難分，這就要求必須按照可部署的原則設計軟體，就像設計用於生產環境的軟體一樣

10. Web資源

10.1. 緩存破壞（cache-busting）

10.1.1. 能夠幫助瀏覽器、所有中間代理和緩存伺服器獲取最新的靜態資源

10.2. 版本控制

10.2.1. Git生成的SHA值作為版本標識符

10.3. 會話黏性

11. 推出新代碼

11.1. “收斂”式基礎設施

11.1.1. 這種基礎設施使用長壽命的機器，並由這些機器接受變更

11.1.2. 決定每次要更新的機器數量

11.1.3. “金絲雀”組

11.1.4. 要阻止流量發往機器，一種簡單的方法就是將其從負載均衡器池中移除

11.1.5. 通過健康狀況檢查，應用程式中一個簡單的狀態變更，就可以通知負載均衡器不再向該機器發送任何新請求，該機器正在處理的請求會繼續完成

11.2. "不可變”的基礎設施

11.2.1. 要針對新版本的代碼啟用新機器

11.2.2. 隨著新機器不斷出現且通過了健康狀況檢查，它們將開始承擔流量負載，這意味著需要實現會話黏性，否則某個調用方後續發來的請求，就可能不得不交給新版本機器（而不是舊版本機器）來處理

11.3. 如果部署非常頻繁，那麼最好是在現有集群中啟用新機器，這樣做可以避免打斷正在處理的連接

11.4. 在所有的模式下，機器上的記憶體會話數據都會發生丟失，必須讓用戶瞭解到這一點

12. 清理

12.1. 如果工具用完後沒有歸位，那麼工作不能算完成

12.2. 去除墊片

12.2.1. 一旦每個實例都部署了新代碼，就不再需要那些觸發器了，那時就可以刪除它們

12.2.2. 對於新的資料庫遷移，務必最後要執行這樣的刪除操作

12.3. 收縮（contraction），或“收緊”資料庫模式

12.3.1. 撤銷舊表

12.3.2. 撤銷舊視圖

12.3.3. 撤銷舊列

12.3.4. 撤銷不再使用的別名和近義詞

12.3.5. 撤銷不再被調用的存儲過程

12.3.6. 在新列上應用非空約束

12.3.7. 應用外鍵約束

12.4. 清理階段也是審查特征切換的好時機

12.4.1. 任何新的特征切換都應預設設置為“關閉”