第六章 構建與部署的指令碼化

1. 引言

要實現

• 自動構建
• 自動部署

構建和部署系統一直要保持活力，這個系統不僅要從專案開始就開發，而且一直持續到產品到上線維護階段，細心設計和維護它，像對待專案原始碼一樣，並定期使用，確保我們每次想用時，都能正確執行

2. 構建工具概覽

由於我使用Java，用Maven構建，所以其他相關工具略過

2.1. Make

略

2.2. Ant

略

2.3. NAnt與MSBuild

略

2.4. Maven

慣例由於配置

三個問題

• 專案結構死板
• 擴充套件它要寫程式碼（mojo外掛）
• 預設情況下，自動更新，可能會導致某次構建無法重現

依賴和配置慣例參見第十三章

2.5. Rake

略

2.6. Builder

略

2.7. Psake

略

3. 部署構建指令碼化的原則與實踐

3.1.為部署流水線的每個階段建立指令碼

剛開始可能只需要一個指令碼，但是專案大了之後就要拆分，易於管理和維護

記住，部署指令碼一定要放在版本控制庫中

3.2. 使用恰當的技術部署應用程式

部署指令碼應該能完成應用程式的安裝和升級任務，在部署之前，他要能關閉當前執行的版本，而且既支援在當前資料庫上升級，又能從頭建立資料庫

3.3. 使用同樣的指令碼向所有環境部署

將部署指令碼和需要用到的配置資訊分離開來，詳情可參見

3.4. 使用作業系統自帶的包管理工具

讓自己的應用程式包的安裝也想apache的安裝一樣

3.5. 確保部署流程是冪等的

確保每次部署都以已知狀態良好的環境作為起點

很難實現，作為目標前進吧

3.6. 部署系統的增量式演進

逐步完善，每自動化一個過程，就是一個進步

4. 面向JVM的應用程式的專案結構

推薦使用Maven，Maven最大的貢獻就是標準化了專案結構

• 任何生成的配置或元資料都應放在target下
• 單元測試與原始碼對應
• 版本控制庫應該忽略target目錄
• 確保應用程式所有依賴都與應用程式的二進位制包一起打包

5. 部署指令碼化

核心原則：對測試和生產環境的修改只能由自動化過程執行

5.1. 多層的部署和測試

• 第一層（最底層)，硬體
• 第二層，作業系統，作業系統配置
• 第三層，中介軟體，中介軟體配置
• 第四層，應用/服務/元件，應用配置

保證下一層是準確的，可控的，穩定的配置，再開始上一層的部署

5.2. 測試環境配置

簡單的冒煙測試，證明我們的配置可以工作，可以從如下幾方面入手

• 確認能從資料庫拿到一條記錄
• 確認能連上網站
• 斷言訊息代理中的已註冊的訊息集合是正確的
• 透過防火牆傳送幾次“ping”命令，證明線路是通的，且各伺服器之間提供了一個迴圈分配負荷

關於基礎設施管理，第十一章有更詳細的描述

6. 小貼士

6.1. 總是使用相對路徑

如果不可避免要使用絕對路徑，儘可能將這部分內容獨立出來，不要讓它影響構建系統的其他部分

6.2. 消除手工步驟

枯燥，極易出錯，文件容易過時

當做第二次時要警覺，當你需要重複做第三次時，就把它自動化

6.3. 從二進位制包到版本控制庫的內建可追溯性

保證知道哪個二進位制包是哪個版本庫的哪個版本生成的

6.4. 不要把二進位制包作為構建的一部分放到版本控制庫中

6.5. “test”不應該讓構建失敗

不要一碰到錯誤就失敗，最好都執行一遍流程，報告出所有錯誤，再失敗

6.6. 用整合冒煙測試來限制應用程式

部署前簡要測試一下機器是否正確，環境是否正確等

6.7. .NET小貼士

略

7. 小結

以迭代的方式來識別最令你痛苦的步驟，並將其自動化，沿著部署流水線，逐步完善自動化構建和部署能力。請時刻牢記最終目標，即在開發、測試和生產環境中共享同一種部署機制，但不要過早地糾結於工具的建立