/*** 本沒有流程, 公司採用cmmi, 要求有個流程, 就寫了乙個
*/continuous integration process guide
持續整合實施指南
像" 版本控制", "配置管理"一樣, "每日構建", "持續整合(continuous integration, 簡稱ci)"等實踐也成為現代軟體開發的必備配置. 乙個好的ci環境, 能夠讓你實時監控軟體的開發狀態, 隨時獲得可工作的軟體版本, 能夠提供給開發團隊,管理團隊,甚至市場人員快速而有效的反饋. 沒有實施ci的專案, 就像黑夜中失去聯絡的列車, 可能湊巧能夠到達目的地, 但大多數時間不知身在何處, 將駛向何方.
好的ci環境並不是唾手可得的, 但也並非無章可循. 從2023年thoughtworks發布第乙個ci工具cruisecontrol起, 近7年的時間裡, 軟體開發領域湧現出了大量成功的ci實踐, 以及應該避免重蹈的覆轍. 乙個新的專案團隊應該如何從無到有的實施ci, 這個流程已日漸清晰.
一次實施過程按時間的先後順序, 大致可分為團隊組建, 現狀調研, 實施, 驗收, 及後續維護等幾個步驟.
一. ci團隊組建
綜上所述, 持續整合需要不同於開發人員的技能, 可以循序漸進的培養專業人員, 並在每個專案實施ci的過程中, 得到領域專家的配合.
二. 現狀調研
我們反對一成不變的照搬已有的經驗. 任何忽視現狀的ci實施都是不可取的. 在每個團隊中, 總有一些獨特的, 強大的工具讓你眼前一亮. 認真了解專案組目前的工作狀況, 是成功實施ci的必備步驟.
在我們的培訓教材中, 我們提到, ci的實施, 需要人和工具兩個方面的因素. 在調研過程中, 我們也需要考慮這兩方面的因素, 做出全面的評估.
1. 人, 或者說開發文化
評估檢查列表:
是否編寫單元測試, 或其它形式的自動化測試?
是否經常提交**?
是否總是在提交**前先從伺服器上更新**?
是否關心自己提交的**會不會導致其他成員的**構建失敗?
是否所有的團隊成員都在同一間辦公室工作?
其中正面的回答將有利於提高ci環境給出反饋的速度和力度, 有利於減少在ci環境中失敗的構建次數.
2. 工具
2.1 評估檢查列表(自動化程度):
是否有無需人工干預的單元測試工具?
是否有無需人工干預的功能測試工具?
是否有無需人工干預的更多種類的測試工具?
是否有無需人工干預的**質量檢查工具?
是否有無需人工干預的部署工具?
這裡強調"無需人工干預", 而不是簡單的"自動化", 是想強調不僅僅需要能夠自動化的啟動執行, 而且需要保證在整個執行過程中無需人工干預. 比如說:
不能夠在控制台中等待輸入
不能夠彈出對話方塊等待輸入
2.2 評估檢查列表(可整合性):
是否能夠按照慣例在發生錯誤的時候返回非零值?
是否能夠接受一定格式如xml或純文字格式的輸入?
是否能夠產生標準格式如xml或html等易於整合的輸出?
是否接受命令行引數?
是否支援標準協議控制如 http, ftp ?
是否支援程式設計訪問如 rmi, corba, soap, tcp?
在持續整合逐漸發展成熟的理論中, 乙個叫做"pipeline"的概念開始得到認同. 構建過程中的每乙個步驟未必是乙個孤立的步驟, 可能需要接受前乙個階段的輸出作為輸入, 並產生自己的輸出作為下乙個步驟的輸入, 因此基於各種標準的輸入輸出支援是必要的. 專有格式並不適合任何一種整合環境.
2.3 評估檢查列表(透明度):
是否能夠產生自己的執行日誌?
是否能夠指定日誌的磁碟位置和格式?
ci環境需要展示盡可能多, 盡可能有用的報告, 工具的自我報告直接影響最後的效果.
2.4 評估檢查列表(環境依賴性):
是否能夠在硬碟上的任何乙個目錄中執行?
是否不依賴於絕對路徑?
三. 實施
實施過程是ci的重點, 直接關係到成功與否. 卻也正是變化最多的乙個階段, 定製性都在這個階段體現. 每個ci環境都有獨一無二的特點. 沒有什麼好的方法, 依賴於團隊的經驗.
在這個過程中, 在大的方面上, 可以遵循下面的原則或實踐:
使用配置管理來管理配置
使用一切手段, 讓反饋更快
使用一切手段, 讓反饋更有效
學習並積累可復用的ci最佳實踐
培養團隊成員的責任感, 將ci的反饋落到實處.
在這個過程中, 可能會遇到很多問題. 典型的問題如下:
1. 無法把某個步驟自動化: 認真分析一下原因. 通常這不是真的, 除非乙個軟體是完全封閉的, 沒有任何可程式設計的介面供整合. 問題可能出在選擇的工具上. 是否能夠改進現有工具? 是否能夠選擇其它工具?
2. 需要整合多個源**源: 盡量不要讓兩個不同元件的源**直接依賴, 可以使用編譯後的庫作為媒介. 如果必須有源**的依賴, 盡量讓它們使用同乙個源**倉庫. 如果依賴的源**必須在另外乙個倉庫中, 盡量選用支援聚合的源**控制系統, 如subversion, 可以使用 svn:external 來將不同倉庫中的**聚合在一起.
3. 需要雙向合併不同分支中的源**: 確切來說, 這是配置管理的問題. 這只是配置管理帶給持續整合環境的麻煩. 從配置管理的角度, 應該盡量避免建立這種需要雙向合併的分支. 一旦發生這種情況, 最穩妥的辦法還是開發者在本地完成合併, 然後執行私有構建, 構建成功後再提交到ci環境監控的源**庫中.
四. 驗收乙個最佳實踐就是把整個 ci 環境提交到版本控制系統中, check out 到一台新機器就能用
五. 後續維護
專案的開發周期從幾年到幾個月不等, 而通常開始的幾個星期內就會把ci環境搭好. 隨著開發的進展, 必然會對ci環境有新的需求. 如何應對這些新的需求? 可以從組織管理和技術兩個方面來考慮.
組織管理:
1. 即使有專業的整合團隊, 但資源不充足的時候他們需要為更大範圍的組織服務, 因此專案組內部需要有至少一位成員對環境比較了解. 這可以通過在前期和專業人員結對工作來實現.
2. 隨著時間的推移, 熟悉持續整合的人員必然越來越多, 可能在每個專案組內都有人熟悉持續整合. 這也是我們想看到的結果. 這意味著我司已經建立起了一支有形或無形的專業的持續整合隊伍. 這支隊伍中的大部分人都能夠解決自己專案組中簡單的整合問題. 而少數更專業的人士可以進行更大規模, 集中式的ci平台規劃或管理.
技術:1. 所選用的ci工具必須是易於擴充套件的, 支援使用者定製的. 必要時可以通過編寫外掛程式來滿足新的需求.
2. 所選用的工具最好有可靠的支援, 或成熟的社群, 碰到問題可以尋求幫助.
持續整合（一）
一 提出 整合軟體 的過程不是新問題，如果專案開發的規模比較小，比如乙個人的專案，如果它對 外部系統 的依賴很小，那麼軟體整合不是問題，但是隨著軟體專案複雜度的增加 即使增加乙個人 就會對整合和確保 軟體元件 能夠在一起工作提出了更多的要求 要早整合，常整合 早整合，頻繁的整合幫助專案在早期發現專案...
持續整合簡介
想起我剛畢業後，進入一家以軟體外包為主的外企做開發。它使用傳統的瀑布式的軟體開發流程，沒有使用任何的敏捷實踐。我每天上班開啟電腦，拿到自己的任務，然後從版本控制更新 開啟工程按下build，準備進行今天的開發任務。突然發現build失敗 通常是編譯不過 大喊一聲 誰break build啦 也沒有人...
持續整合 CI
引子 記得剛加入趨勢開始開發工作 的時候曾被告知，趨勢有一套auto build的系統，會每天夜裡自動把當天check in的 進行構建，生成qa可測試 的build。每個rd都得小心提交code，因為專案結束的時候會看auto build的失敗率。可是構建失敗總是在所難免，尤其是每次要提交cand...