q: 我的產品是電信級的裝置, 幾百人分成幾十個專案組在開發, 各個專案組進度不統一, 如何整合?
a: 你要做的其實跟技術無關, 更多的是管理工作, 就是制定你的產品級別的整合策略.
這涉及到需求分析和發布計畫(依賴管理, 價值和風險識別), 開發方法(自頂向下還是自底向上, 橫向分層還是垂直特性), 整合粒度劃分(完整特性的整合還是api的整合), 整合間隔計畫, 版本控制策略, 還有尤為重要的整合測試/驗證策略, 甚至你的決心.
任何整合策略在執行過程中都會遇到困難, 如遲遲得不到能夠成功整合的版本. 這時你要找出原因, 並有權力或相應措施要求整個幾百人的團隊停下來, 做為第一優先順序的任務去修復. 並讓整個團隊清楚進度停滯造成的損失. 這麼做的意圖是強調整合的重要性, 因此每個專案組在開發時, 都會優先考慮與其它部分的整合, 從而促進更好的溝通和反饋, 減少整合失敗的次數, 縮小整合的間隔.
這在某種程度上會給你的設計帶來正面影響. 比如為了更容易的整合, 模組間使用松耦合的協議/訊息, 或者標準的資料格式來代替緊耦合的api呼叫. 定義可擴充套件的介面來隔離實現修改的影響...
用整合來驅動你的開發程序.
q: 專案組在各自的分支上工作, 每次光合併版本就好幾天, 怎麼做持續整合?
a: 改變分支策略, 使用同一分支, 隨時整合. 參考《配置管理模式》
q: 構建一次, 包括編譯鏈結, 測試, 需要幾十個小時, 怎麼整合?
a: 其實就是一速度的問題, 有很多潛在的優化措施
優化原始檔依賴關係, 該調整設計就調整設計
優化構建指令碼
優化測試用例, 能夠共用一套測試環境的就一起跑
分類測試用例, 優先執行價值大速度快的用例; 價值小又耗時的測試執行間隔可以放大
分布式構建, 使用諸如 cruise 或 incredibuild 之類的軟體.
使用高效能主機
q: 硬體依賴, 尤其是嵌入式, 怎麼整合?
a: 理想的情況是: 產品**執行在真實的嵌入式裝置上, 測試結果可以報告給執行在 pc 上的 ci 工具
我們很多專案早已做到這一點, 方法也不難:
通過裝置支援的方式(如ftp)將編譯後的**上傳到裝置
向裝置發出命令載入新**(tcp或串列埠)
執行測試用例: 可以執行在 pc 上通過網路(tcp或串列埠)與裝置互動以斷言其行為, 或直接執行在裝置裡, 然後將測試執行結果通過網路取回
在硬體不具備的情況下, 使用**模式裝置
q: 構建結束前有新的commit, 是否要等待上次構建結束才進行新的構建?
a: 取決於你用的ci工具, 大部分是這樣的. 但在支援分布式構建的ci工具中, 可以使用另外一台機器來立刻執行新的構建, 這是一種可能的特性, 如果你知道哪個工具實現了它, 請告訴我.
對這種特性的爭論在於一旦構建失敗, 將不容易分清是誰的提交造成的, 但兩個原因這個假設不成立:
大多 ci 工具基於輪詢的機制, 總會發生一次構建包含多次提交的情況
在提交紀律嚴明, 有責任心, 視 ci 為第一要務的敏捷團隊, 提交前都會在本地執行構建, ci server 上構建失敗的機率不高.
q: 我們的產品需要支援多種作業系統, ci 怎麼做?
a: 多數 ci 伺服器都能執行在多種作業系統上, 差別只在於是分別管理(單機構建)還是統一管理(分布式構建).
q: 是否團隊每個人都需要在自己的開發機器上執行 ci 整合環境?
a: 不需要執行 ci 環境, 只需要執行 ci 環境執行的構建指令碼. 本地構建使用與 ci 相同的構建指令碼將減少 ci 失敗的概率, 參見<>.
q: 是否團隊每個人都需要掌握 ci 知識?
a: ci 工具本身其實很簡單, 更加重要的是整個團隊的整合策略.
q: 如果測試先行, 那整合環境中如何處理預先寫的肯定會失敗的測試?
a: 測試先行的另乙個約束是步子盡可能小, 基本上你不應該在讓測試通過前提交它.
q: 可我們的測試人員提前寫的自動化整合測試, 一開始是失敗的, 只是隨著開發的進行, 才逐漸通過的. 這怎麼辦?
a: 這基本上是你的測試管理策略, 一種簡單的方案就是分開存放注定失敗的測試和已經實現對應功能的測試, 隨著特性的不斷完工, 逐漸的移動測試.
自動化測試工具支援使用標記來控制執行時忽略/跳過某些測試.
q: ci的願景是好的, 但我們這裡根本不可能, 我們的產品需要複雜的執行環境, 執行時需要人工干預, 怎麼測?
a: 我不清楚你說的複雜具體是怎麼複雜, 人工干預是怎麼樣的干預, 但這確實是個常見的, 有無數種真實情形的問題. 通常我們會具體問題具體分析, 但有幾個通用的原則:
設計, 分離核心業務邏輯與外部介面, 爭取讓業務邏輯環境無關
自動化, 尋找合適的自動化測試工具, 必要時自己開發
盡可能搭建真實的執行環境
整合在很大程度上依賴你的測試策略和自動化程度.
q: 你說整合依賴於測試策略和自動化程度, 是否不執行測試的整合不能算整合?
a: 任何一點整合方面的努力都是值得肯定的, 哪怕即使只是持續編譯. 事實上在那些不得不常年維護大型遺留系統的公司, 即使只是持續編譯, 保證每天能夠編譯通過, 也已經具有很大的價值了. 當然, 我們需要盡可能的整合更多的自動化檢驗工作.
ci 社群最近出現了乙個出於商業目的攻擊, 1 , 2 , 基調就是對持續編譯這種 ci 的壞味道/反模式的鄙視. 其實沒人認為 持續整合的核心是持續編譯, 我們尊重任何整合方面的努力, 凡事總有第一步.
q: 整合與測試, 是否經過整合的就是可用的?
a: 取決於你如何定義可用. 信心來自於全面的測試.
q: 聽說 ci 環境配置挺麻煩, 有沒有簡單一點的工具?
q: 對 ci 工具本身, 我還是想不清楚, 它怎麼知道去**取**? 怎麼知道有沒有更新? 怎麼取**? 怎麼編譯? 怎麼知道跑什麼測試? 怎麼知道成功失敗?
a: 版本控制系統的客戶端都是可用的工具, 也都提供了公開德協議或互動介面, 這都沒問題. 至於編譯和測試, ci 工具確實不必知道, 儘管很多任務具都能按照某種約定或自動識別你的源**和測試. 事實上, ci 工具只是忠實的執行你配置的行為, 通常是某個你編寫的指令碼, 因此是由你來指定如何編譯和如何測試. 至於成功或失敗, ci 遵循作業系統的慣例, 返回值0成功, 非0失敗.
q: 我們的版本控制系統是 clearcase, 你們的 ci 工具支援嗎?
a: 不支援, 換 subversion 吧
clearcase 慢
clearcase 貴
clearcase 難用
clearcase 太悲觀, 鎖的你沒脾氣
q: 怎樣才能減少 ci 構建失敗的機率?
a: 這其實是個最佳實踐的問題, 比如對於需要在多個作業系統上執行的產品, 專案組內不同的開發者盡可能使用不同的目標平台開發,這樣可以在本地構建時捕捉到平台類的錯誤. 關於ci工具cc的最佳實踐, 可參考
q: 我們在遺留專案上工作, 面臨前面提到的所有問題: 編譯速度/環境依賴/多個專案組進度依賴/分支合併/甚至版本系統用的都是clearcase, 總感覺你說的很虛, 未必就能給我們的現狀帶來多大改善
a: 這是投入產出比的問題(你的專案還要維護多久, 能帶來多大利潤, 花費大力氣去改善值不值得), 也是價值觀的問題(是放任現狀,直到它自然滅亡, 還是逐步改善, 看看最後能改到什麼程度). 我是建議試試, 從最簡單的,對環境要求不高的開始做起, 慢慢擴大範圍. 所有的軟體都會被廢棄, 人也會死亡, 意義只在於不斷的嘗試, 看看會發生什麼. 如果明知不值得, 這樣也就算了, 留點時間去嘗試別的事情.
敏捷質疑 持續整合
敏捷質疑 持續整合 q 我的產品是電信級的裝置,幾百人分成幾十個專案組在開發,各個專案組進度不統一,如何整合?a 你要做的其實跟技術無關,更多的是管理工作,就是制定你的產品級別的整合策略.這涉及到需求分析和發布計畫 依賴管理,價值和風險識別 開發方法 自頂向下還是自底向上,橫向分層還是垂直特性 整合...
保持敏捷 持續整合
敏捷的乙個要點就是 快速反饋。從最早的每日構建，到現在的持續整合，都是開發者為了迅速獲得系統反饋而採取的一系列措施。而且反饋資訊越來越快速，資訊要求越來越高。一次整合的過程步驟大概如下 自動更新 編譯構建 自動測試 報告整合結果。需要使用者寫好各過程命令 比如更新版本 並在整合伺服器的支援下，把各過...
敏捷持續整合工具CruiseControl
持續化整合工具便是服務於敏捷軟體開發的乙個系列。它主要將原本分散，無序的工作流程，通過工具軟體有機的組織起來，並且在組織的過程中，參與開發設計測試的各個部門的人員都能從中獲取到自動化方面的優惠。使得團隊的工作效率大大提公升。cruisecontrol是乙個針對持續構建程式 專案持續整合 的框架,它包...