前兩天，去做QCon的志願者，會場期間也聽了來自多家公司專家對很多Topic的介紹。但真正和我們QA相關也就兩個名詞：持續交付和敏捷，而對這兩名詞的實踐可以彙集成一點：持續集成。
阿里巴巴持續集成也推廣得有一年了，我也不太清楚別的部門的效果怎麼樣，但我自己在之前的算法測試和現在的搜索平臺測試中的觀察，感覺持續集成其實都實施得不怎麼樣，並沒有達到持續集成的那種“Nightly Build”的目標。
來自百度的喬樑（2011熱門書《持續交付》的翻譯者）介紹了在百度的項目，和我們目前的情況很類似，羅列了很多點，比如10年的C++歷史代碼什麼的，但總結起來主要有以下三個：
- 分支開發模式
- 太多的手工測試
- 手動發佈的風險
1.1 分支開發模式的帶來問題
這是我們部門目前很常見的問題，尤其是ISearch，大量並行開發中的分支造成了大量的merge工作，以及迴歸測試。這點尤其是我目前經手的兩個項目特別明顯：
（1）ISearch 421：這個項目合併之前各個站點修復bug和新增的feature。這些功能之前測試過一遍;現在因爲要合併到主幹上，需要再測試一遍;然後以後各個站點需要上線時又得測一遍;
其實這後兩遍的測試是人爲造成的，如果版本管理完善的話，完成不需要這兩遍測試;而開發同學將各個站點修復的bug合併到主幹上的工作同樣也是人爲造成的冗餘工作，而且所有merge工作都是得人爲來合併的，而不是用SVN的merge功能。
（2）ISearch 4.3：這個項目目前雖然沒有暴露問題，但等到它要發佈時，期間可能已經盡力了4.2.1 4.2.2 ……N多個版本，這時又一次帶來了merge的問題了，恐怖吧。
1.2 太多手工測試
其實我個人覺得，做好單元測試和自動化測試是持續集成的關鍵步驟。如果沒有自動化的驗證手段，無論哪種敏捷模式、無論哪種開發模式都是浮雲。
1.3 手動發佈的風險
發佈如何做到自動化？我們現在的ISearch是可以用LauchPad來自動化發佈的，但其他項目呢？
環境的部署和發佈腳本也應該被納入版本控制中。當然，發佈腳本應該儘可能統一模板，也是需要經過測試的。我之前遇到過這麼一種情況，有一個算法項目，需要每天定時更新一份數據的，但我那天發現這份數據在項目發佈半年多來從來沒有被更新過，並且明明寫了報警處理，但卻從來沒有報警過。最後究其原因，發現是發佈腳本寫錯了：
# 發佈腳本是這樣寫的
returnCode=調用dump程序
if returnCode != 0
報警 && exit
# 而dump程序卻是這樣的：
int main() {
returnCode = dump數據;
if returnCode == false:
return 0;
......
return 0;
}2.1 進行主幹開發
在QCon介紹持續交付的幾個哥們都建議“主幹開發”。那麼我們來看看主幹開發的好處：
- 規避了分支開發時的那種反覆merge代碼的問題
- 在實現功能時，不得不將需要實現的功能拆成很多小功能，然後去逐個實現
- 自動化測試代碼（這裏的測試不區分是開發的單元測試還是QA的自動化測試）緊跟開發代碼
- 凡是check in到SVN版本庫中的每個Revision都可以發佈的版本，以做到可以日日發佈
這裏需要注意的是：每個需要ci到SVN的代碼都是需要經過完整測試的，而不是我們目前的那種ci上去後再由QA同學checkout出來進行測試。
2.2 做好自動化測試
我們目前自動化的覆蓋率還比較低，我這裏的覆蓋率是指TC覆蓋率（自動化測試能覆蓋多少的TC），而不是行覆蓋率。喬樑在介紹他那個項目時，提到了對他們那個系統做6步測試（包括單元測試、單個模塊的接口測試、集成測試、和依賴的環境一塊的集成測試等），只有這6步測試OK了的，才能被ci到SVN中的。
所以嘛，我覺得做好自動化測試才能真正地做好持續集成。
2.3 解決發佈時的風險
雖然這個QCon的主題叫做”持續交付“，但正確如何讓ops和dev更好的交互卻沒有講到。不過在大會中，來自印度的程序員Sai介紹了他們的開發一個開源系統：chef 。它可以管理着我們線上的生產機器;使用項目的發佈模板來進行自動化發佈;項目發佈的模板可以使用chef默認提供的，比如apache這些chef已經提高了，也可以自己定義;管理依賴的模塊等。
其實我感覺我們部門的lanuchpad也是類似這樣的系統。
2.4 其他建議
ThoughtWorks的高級諮詢師熊節（《重構》的譯者）還給出以下幾點建議：
- 重複的事讓機器去做，人應該從事創造性的工作
- 得到好工具的關鍵在於不要再重複發明輪子
- 計算資源和計算資源的使用應該解藕
- 與生產環境相似的驗證環境應該隨時可得
- 每個研發人員的工作狀態應該隨時可見
-
好的研發實踐應該立即被部署到每個人