一本好書使您改變。它將改變您的思想，您看待問題的角度和方式，最終，它將改改您的行為。然而，所有具有重要意義的改變都不會是在一夜之間發生的，如果您相信這種變革必會發生，不妨朝著這個方向去努力，經常改變，每次改變一點點。

                                                                                                                                           ——《持續整合：軟體質量改進和風險降低之道》

CI的價值：

減少風險：缺陷的檢測與修復變得更快；通過持續測試與持續審查，軟體的健康程度可以測量；可以減少不實的假定。

減少重複過程

在任何時間、任何地點生成可部署的軟體

增強專案的可見性

對開發團隊的軟體產品建立起更強大的產品信心

CI的阻礙：

增加了維護開銷

團隊變化太大

失敗的構建太多

額外的軟硬體成本

團隊中7項好的CI實踐：

經常提交程式碼

不要提交無法構建的程式碼

立即修復無法整合的構建

編寫自動化的開發者測試

必須通過所有的測試和審查

執行私有構建

避免簽出無法構建的程式碼

持續構建：

每次程式碼變更均進行自動化構建

將構建過程控制在單行命令下

將構建指令碼從IDE中分離，避免與IDE產生耦合

集中放置軟體資產

建立一致的目錄結構

讓構建快速失敗

針對所有環境構建

使用專門的整合構建計算機

使用CI伺服器

執行快速構建：分離較慢的構建，讓整合構建少於10分鐘

分階段構建

持續資料庫整合：

進行資料庫自動化整合

使用本地資料庫沙盒

將資料庫資產放入版本控制庫

讓開發者能夠修改資料庫

讓開發者成為開發團隊的一員

持續測試：

線性系統的可靠性是每個系統元件的可靠性的乘積，因此特別需要保證底層元件的可靠性

進行自動化單元測試、元件測試、系統測試、功能測試，優先執行測試速度快的測試

為缺陷編寫測試

讓測試元件可以重複

儘量將測試限制為一個斷言

進行程式碼持續審查，對程式碼的複雜度、耦合度、重複度等進行持續審查（sonarQube）

持續部署：

為每一個構建打上標籤

執行測試

建立構建反饋報告

回滾構建的過程能力

持續反饋：

不要讓您的團隊習慣於忽略來自CI構建過程的訊息

需要儘快反饋：持續整合的核心是減少缺陷引入、發現和修復之是的時間間隔

《持續交付：釋出可靠軟體的系統方法》

軟體交付：

每次修改都應該觸發反饋流程

必須儘快接收反饋

互動團隊必須接收反饋並作出反應

無論部署到什麼樣的目標環境，都使用相同的部署方法

軟體交付的原則：

為軟體的釋出建立一個可重複且可靠的過程

將幾乎所有的事情自動化：配置管理自動化、驗收測試自動化、資料庫升降級自動化，對於硬體可採用虛擬化技術和像puppet這樣的工具支撐自動化

將所有的東西都納入版本控制

提前並頻繁地做讓你感到痛苦的事

內建質量：一旦發現缺陷，就要馬上著手修復，交付團隊中的每個人都應該對應用程式的質量負責

Done意味著已釋出

交付過程是每個成員的責任

持續改進：團隊應定期召開會議，反思過去的一段時間哪邊做得好，哪邊需要改進。

配置管理：

對所有內容進行版本控制，包括應用程式的軟體、硬體及基礎設施，與專案相關的所有東西都在版本控制庫中（但是不推薦將原始碼編譯後的二進位制檔案也納入版本控制中）

頻繁提交程式碼到主幹，儘量減少分支

使用意義明顯的提交註釋

以對待程式碼的方式來對待你的系統配置，使其受到正常的管理和測試

將特定於測試環境或生產環境的實際配置存放於與原始碼分離的單獨程式碼庫中

應該嚴格控制生產環境，進行變更過程管理

高效配置管理策略：將二進位制檔案與配置資訊分離；將所有的配置資訊儲存在一處。

基礎設施應該具有自治特性，且非常容易重新搭建

保證配置管理是宣告式且冪等的，即無論基礎設施的初始狀態是什麼樣，執行了配置操作後，基礎設施或系統所處的狀態就一定是你所期望的狀態。

如果版本控制系統允許，儘量選擇樂觀鎖（編輯本地工作副本的一個檔案時不會阻止其它成員對其進行修改）

康威法則：設計系統的組織不可避免地要產生與其組織的溝通結構一樣的設計，即由都坐在一起的小團隊開發出來的產品更趨向於緊耦合、非模組化特點

持續整合：

一、良好的實踐：

構建失敗之後不要提交新程式碼

提交前在本地執行所有的提交測試，或者讓持續整合伺服器完成此事

等提交測試通過後再繼續工作

回家之前，構建必須處於成功狀態

時刻準備著回滾到前一個版本

回滾之前規定一個修復時間

不要將失敗的測試註釋掉

為自己導致的問題負責

測試驅動的開發

二、推薦的實踐：

極限程式設計開發實踐

若違背架構原則，就讓構建失敗

若測試執行變慢，就讓構建失敗

若有編譯警告或程式碼風格問題，就讓測試失敗

測試策略：

一旦同一個測試重複做過多次手工操作，並確信不會花太多時間來維護時，就要把它自動化

單元測試不應該訪問資料庫、使用檔案系統、與外部系統互動

儘可能頻繁地向客戶演示功能

建立一些基本的非功能測試，如容量測試、安全性測試。

提交測試應該避免複雜的資料準備，而是用盡量少的測試資料來斷言被測試的單元正確地完成了所期望的功能

儘可能使用應用程式的公共API為測試建立正確的初始狀態

部署流水線：

只生成一次二進位制包，並將生成的二進位制包存入於製品庫中，之後的測試、部署均基於此二進位制包

對不同環境採用同一種部署方式

對部署進行冒煙測試，這個冒煙測試還應該檢查一下應用程式所依賴的服務是否都已啟動

向生產環境的副本中部署，即先向類生產環境中部署

每次變更都要立即在流水線中傳遞

只要有環節失敗，就停止整個流水線

為儘快加快反饋過程，增加提交階段的測試

通常都應該使用增量的方法來實現部署流水線：構建、部署、單元測試、程式碼審查、驗收測試、釋出等步驟，部署流水線也應該不斷變化，不斷改善與重構

做整體優化，不斷縮短週期時間，即修改一行程式碼到最終部署至線上並生效的時間

確保構建時儘量使用相對路徑

應該儘量將需要管理的構建數量最少化

驗收測試：

寫應用程式驗收條件時必須想著如何使其自動化，並遵循INVEST原則（independentnegotiable valuable estimable small testable）

儘量與GUI解耦

儘量使測試具有原子性，即與測試的執行順序無關

單個測試範圍內，應該避免所有非同步情況，也要避免跨越測試邊界情況

儘早修復失敗的驗收測試

當驗收測試時間需要很長時，考慮使用虛擬化技術進行多環境並行測試

進行容量測試，但需要先進行度量，找到解決方案之前，必須先找出問題的根源，過早的優化是所有罪惡的根源

對於容量測試環境可以採用縮放後的類生產環境，而不是整個叢集

把自動化容量測試作為部署流水線中的一個完成獨立的階段

部署與釋出：

真正執行部署操作的人應該參與部署過程的建立

記錄部署活動

不要刪除舊檔案，而是移動到別的位置

部署是整個團隊的責任

伺服器應用程式不應該有GUI

為新部署留預熱期

快速失敗

不要直接對生產環境進行修改