傳統的一連集成(CI)系統被設計成功課的流水線。你可以有一個同行評審,然后開始構立功課,然后是單位測試功課,然后是集成測試功課,然后是機能測試功課,諸如此類。
每個功課都是由前一個功課的樂成完成事件觸發的,而第一個功課則是由版本節制系統中源代碼文件的改觀事件來觸發的。雖然,假如你的方針是多個二進制平臺,可能假如你正在構建的是一組組件,以此來測試整個的應用措施,那么它還會越發的巨大。
那么假如有任務失敗了會奈何?Jez Humble 和 David Farley 在一連交付中認為,你首先需要遵循這樣的原則:"不要在失敗的 build 上提交接碼"。換句話說,不要由于新的提交導致問題更嚴重。假如你違反了這個原則,你就沒法確認引起錯誤的真正原因。Humble 和 Farley 發起選擇下面兩種計策之一來處理懲罰 build 失敗的環境:
"當 build 失敗是,不要去做此外工作," 意思是團隊中的所有人都要停下往復修復這個問題。
"時刻籌備回滾到上一版本。" 回滾的計策可以制止打斷整個團隊的事情。
雖然,也可以回收殽雜的計策:在可容忍的時間內實驗修復,高出時間則舉辦回滾。
尚有一種方法可以稍微緩解問題,那就是利用集身分支,只有集身分支是綠色的(所有測試通過),才答允舉辦代碼的歸并。這種計策下集身分支照舊有同樣的問題,不外 master 分支可以擔保老是可用的。
雷同的方法合用于小團隊,你可以讓團隊的所有成員都暫停代碼的提交,不外縱然是小團隊,CI 處于赤色狀態也有大概會一連較量長的時間。對付這種方法的 CI 實踐,你需要嚴格遵循完善的劃定。不外你也可以實驗一種新的實施 CI 的方法。
新一代的 CI
今朝的 CI 是以 CI 處事器為中心。CI 處事器認真發明竄改并觸發任務。
新一代的 CI 則是以代碼 review 系統為焦點,這樣可以擔保在竄改歸并到版本打點系統之前完成相應的操縱。
是否插手團隊的代碼 review 的進程,這取決于你。我強烈發起通過代碼 review 來提高代碼的質量,可是這與 CI 系統自己是獨立的。我們需要強調的是,構建和測試這些行為是由代碼 review 系統的新提交來觸發的。當所有測試都通事后,代碼才會被歸并到骨干上。如此一來,骨干的代碼老是可以擔保是測試通過的,開拓人員也可以并行的舉辦代碼提交。新的 CI 體系可以讓你的自動化變得流通,因為不再有問題會阻塞流程。
OpenStack 的事情流程
CI上的新的要領已經在 OpenStack 項目中獲得大局限的實現,一次來打點所有差異的子項目標CI進程。為了使你對它的局限有一個觀念,可以看到天天 OpenStack 都要處理懲罰 1000 個提交的補丁包,7500條提交的有關于Gerrit的評論和投票, 催生出16,000 個測試情況,尚有250次改觀的歸并(源代碼)。
為了實現下一代的CI系統,OpenStack項目利用下面這些組件:
·Gerrit, 代碼審查和git資源庫打點器。
·Zuul, git代碼庫節制系統。
·Jenkins, 一連集成處事器。
· Nodepool, 陳設在OpenStack云上的智能的 Jenkins 衍生東西。
這些東西通過利用隨機揣度的歸并計策來實此刻同一個項目上的并行測試。假如同一時間在同一項目之上產生了多次評審,Zuul就可以或許以隨機揣度的方法將它們放到一起來對它們舉辦測試。譬喻,插手評審被定名為A、B和C,,那么Zuul將會并行的對 A、A+B以及A+B+C舉辦測試。假如他們都樂成了,那么就已經跟A顛末尾測試并舉辦了歸并結果是一樣的了,然后B在分支(A)的基本上顛末尾測試然后舉辦了歸并,C在A+B的基本之上也同此理。 這樣當你同一個項目有多個代碼孝敬者時,集成的進程會加快不少。
Zuul 還能打點跨多個項目標依賴,答允資源庫間評審的歸并。這在git中是個要害的對象,因為在git中你的組件存在于差異的git資源庫中。
試一試
對付大的團隊甚至是小的團隊來說,你都可以通過設置前述的組件來使項目受益于這一事情流程。Puppet 模塊就能用來輕松的設置這些處事。
別的一種要領就是利用我們本身對這些處事的集成,叫做軟件工場。你將會得到下面這些成果特性:
·對這些成果做了一個不錯集成的一個 web 菜單。
·一個在所有這些處事間輕松舉辦單點登錄的方案,尚有在 LDAP、GitHub 可能登錄面飯(cauth)上的外部認證方案。
·一個bug跟蹤系統(Redmine). 協作東西: 用于共享輸出可能代碼提取的 Paste。 用于協作編輯的 Etherpad。
· 以一種簡樸的方法打點從之前版本的進級。
因為軟件工場是自托管的(我們利用軟件工場來開拓軟件工場), 你可以在 softwarefactory-project.io 上對它舉辦相識。
假如你想要測試驅動的軟件工場,只要按 softwarefactory-project.io/docs/deploy.html 上的文檔照做就行了。
你可以就利用這一新的要領舉辦 CI 的收獲同我們保持交換。