[轉] 持續整合與持續傳遞備忘錄

標籤：

URL  :   http://blog.csdn.net/hunterno4/article/details/22525667

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

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

 

CI的價值：

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

減少重複過程

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

增強項目的可見度

對Team Dev的軟體產品建立起更強大的產品信心

 

CI的阻礙：

增加了維護開銷

團隊變化太大

失敗的構建太多

額外的軟硬體成本

 

團隊中7項好的CI實踐：

經常提交代碼

不要提交無法構建的代碼

立即修複無法整合的構建

編寫自動化的開發人員測試

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

執行私人構建

避免簽出無法構建的代碼

 

持續構建：

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

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

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

集中放置軟體資產

建立一致的目錄結構

讓構建快速失敗

針對所有環境構建

使用專門的整合構建電腦

使用CI伺服器

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

分階段構建

 

持續資料庫整合：

 

進行資料庫自動化整合

使用本機資料庫沙箱

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

讓開發人員能夠修改資料庫

讓開發人員成為Team Dev的一員

 

持續測試：

 

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

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

為缺陷編寫測試

讓測試組件可以重複

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

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

 

持續部署：

為每一個構建打上標籤

執行測試

建立構建反饋報告

復原構建的流程能力

 

持續反饋：

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

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

 

《持續傳遞：發布可靠軟體的系統方法》

 

軟體交付：

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

必須儘快接收反饋

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

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

 

軟體交付的原則：

為軟體的發布建立一個可重複且可靠的過程

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

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

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

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

Done意味著發行

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

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

 

組態管理：

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

頻繁提交代碼到主幹，盡量減少分支

使用意義明顯的提交注釋

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

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

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

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

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

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

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

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

 

持續整合：

 

一、良好的實踐：

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

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

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

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

時刻準備著復原到前一個版本

復原之前規定一個修複時間

不要將失敗的測試注釋掉

為自己導致的問題負責

測試驅動的開發

 

二、推薦的實踐：

極限編程開發實踐

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

若測試回合變慢，就讓構建失敗

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

 

測試策略：

 

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

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

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

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

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

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

 

部署流水線：

 

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

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

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

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

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

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

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

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

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

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

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

 

驗收測試：

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

盡量與GUI解耦

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

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

儘早修複失敗的驗收測試

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

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

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

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

 

部署與發布：

 

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

記錄部署活動

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

部署是整個團隊的責任

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

為新部署留預熱期

快速失敗

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

 

頂

1

踩

0

[轉] 持續整合與持續傳遞備忘錄