持續整合: 實踐指南

 

　

第一部分. 實現　0. 持續整合工具的作用

降低風險? No

提高品質? No

快速反饋? Yes !

工具本身並不能降低項目風險, 提高代碼品質. 工具唯一能做的是給你快速反饋. 你收到反饋之後的行為, 才是降低風險, 提高品質的關鍵 (好幾天不check
in, 工具再牛也白搭; 失敗的build不修複, 工具也無能為力)

所以持續整合是一個以人為核心的過程, 工具只是在這個過程中我們要用到的一個產品, 而且絕對不是唯一的一個.

　

快速反饋: 快速反饋實際上是兩個詞, 快速 和 反饋, 而持續整合又牽扯到人和工具兩個方面, 所以一個好的持續整合過程, 至少需要從四個方面來實施和改善:

1. 工具如何做到快速

2. 工具如何進行有效反饋

3. 人如何做才能讓反饋更快速

4. 人如何做才能讓反饋更有效

　

1 工具如何做到快速1.1 監測各種變化 (擁抱變化是敏捷的態度之一, 持續整合工具正是來實證這種態度的產品)

• 基於原始碼的變化: check in, 工具必須支援多種版本控制系統

• 基於依賴項的變化: 項目A的變化將觸發項目B的構建, 工具必須能管理項目之間的依賴

• 基於其它資源的變化: 檔案系統, Http資源(Server startup)... 這不光是持續整合的關注點, 多數EAI系統都基於外部資源的變化來進行整合

• 基於時間的變化: Nightly Build (你早上上班剛進辦公室, 它就給你反饋了, 不佔用你任何工作時間, 夠快的吧)

• 基於心情的變化: 你很著急, 想立馬看看你這次check in的結果, 而不是等過幾分鐘後讓工具來調度, 工具必須支援"強制構建"

　

1.2 盡其所能來加速構建

• 多線程: 在一台強大的server上多線程的來並發構建多重專案

• 分布式: 利用網路中其它機器的資源, 並發的構建多重專案, 或一個項目的不同部分.

• 虛擬機器: 除了可以並發構建外, 主要是能夠實現環境的隔離

• 分階段構建: 可以看做項目間依賴的一個變種, 支援使用者將一個項目分為多個階段, 階段A構建完畢可以觸發階段B的構建,
  但即使階段B還沒有結束而此時有新的check in的話, 階段A會再次得到觸發而無需等待階段B結束. 典型應用情境是單元測試和功能測試分為不同階段.

　

1.3 支援動態更新的配置或自動載入使用者更改的配置

• 支援線上修改配置

• 使用者修改了項目的配置, 應立即生效, 不需要重新啟動CI Server

• 儲存使用者配置的曆史版本, 方便使用者修複自己在配置過程中不小心引入的錯誤

　

2. 人如何做才能讓反饋更快速2.1 頻繁check in

但有個平衡或折衷, 每次check in應該保證完成了一件相對獨立的事, 盡量不要把一件事放在多次check in中, 否則一旦需要revert,
就需要更多的步驟.

2.2 check in token

這可以看作頻繁check in帶來的問題之一. 這與CI工具無關. 這對整個團隊的效率有協助

2.3 最佳化構建指令碼或代碼

避免不必要的 #include

增量構建等. (這兒有個取捨, 通常CI環境中兩次構建應該是互不影響的; 開發人員可在自己機器上進行增量構建)

　

3. 工具如何進行有效反饋3.0 不推薦電子郵件, 不到萬不得已不要使用

• 郵件是非同步, 不及時

• 受SMTP伺服器和郵件用戶端影響, 不穩定

• 通常淹沒在其它郵件中, 不注目

• 太依賴於使用者坐在電腦前, 不靈活

3.1 聲音與顏色, 光線 (速度分別是340m/s和30萬公裡每秒)

• 為失敗的構建播放令人不想再聽到的音樂

• 配合文本朗讀引擎, 念出破壞構建的人的名字

• 熔岩燈

• 大顯示屏, Web 介面

3.2 案頭通知程式

• CCTray

• Yahoo Widget

• Firefox Plugin

• IDE Plugin

• RSS Reader

3.3 反饋不只是構建結果, 還包括構建過程中發生的事情

• 提供構建輸出或log

• 提供觸發構建的原始碼變化資訊, 如版本號碼, 提交者, 提交注釋, 甚至內建diff功能

• 提供構建統計資訊, 如構建期間, 剩餘時間等

　

4. 人如何做才能讓反饋更有效4.1 工作空間

為了更好的利用聲音/光線等反饋手段帶來的好處, 團隊所有人都應該在同一間屋子裡

即使沒有CI, 如果沒有CI, 失去了CI作為紐帶, 團隊反而更應該待在同一間屋子裡, 快速解決任何人遇到的任何問題

4.2 自動化測試

CI工具能給我們什麼反饋, 不是CI工具決定的, 而是我們自己決定的. 你寫的測試越少, CI工具給你的反饋也就越少

4.3 自動化一切能夠自動化的東西

同樣道理, 你讓CI工具做的越多, 它給你的反饋就越多. CI工具的好處就是, 它可以執行指令碼,應用等任何作業系統支援的東西.

4.4 Claim Responsibility

當構建失敗時, 要有人迅速作出反應, 告訴大家說我會修複, 這樣會避免要麼大家都在等別人修複,要麼有多個人都在獨立修複, 浪費時間

　

第二部分, 使用

　

上面是持續整合實施者的角度來看待持續整合. 那麼從使用者的角度, 我們用持續整合來做什麼? 我們有哪些需求需要持續整合來滿足?

　

如果我是專案管理者

• 項目目前狀態, 成功或失敗

• 代碼測試覆蓋率等品質指標

• 構建頻率, 側面反映開發效率

• 在所有我的產品支援的目標平台上進行構建

• 最新版本的產品示範, 意味著需要編寫部署指令碼讓CI工具把產品部署到產品或示範環境中.

　

如果我是開發人員

• 構建結果, 測試回合結果, 失敗原因

• 構建相關的版本控制系統裡的資訊, 能夠快速發現是誰的check in導致的構建失敗

• 能夠按預先定義的規則在版本控制系統中加標籤

• Personal build, 最好是協助我在check in之前運行構建, 成功後自動幫我check in

• 支援盡量多的版本控制系統和構建工具

　

如果我是Tester

• 能夠下載任意版本的產品進行安裝測試

　

如果我是CI環境維護者

• 提供UI, 命令列, 設定檔, 資料庫等多種方式來進行環境配置

• 詳細而精確的調試資訊, 便於快速修複CI環境

• CI Server的容錯, 對曆史資料的智能管理

• 易於擴充

• 許可權管理, 不希望關鍵配置資訊被無意修改破壞, 不希望無限制的強制構建

　

第三部分, 目標

　

所以持續整合是一個專門的領域, 但對於使用者來講, 它只是手段, 不是目標

什麼是目標? 我們的產品. 所以我們會結合實際, 按照開發過程中出現的需求以最小的代價來實施符合我們需求的CI環境.

持續整合本身沒什麼技術含量, 但具體細節太多, 我們不建議項目中的每個人都能夠實施持續整合, 牽扯太多精力, 這與軟體開發幾乎是不同的領域,
術業有專攻, 能夠實施持續整合也不是什麼大不了的事, 門檻很低, 就是體力活.

但是, 也可以說所以, 我們建議建立公司範圍的持續整合團隊, 或者公司比較大的話至少是部門範圍內的CI團隊, 為範圍內的所有項目搭建統一的持續整合平台,
就像公司的IT部門, 測試部, 品質管理部一樣. 這樣能讓項目組的人員集中精力在我們的核心業務, 我們的強項, 也就是產品開發上.