|
|
盡管Thoughtworks的首席科學(xué)家Martion folwer 為“持續(xù)集成 ”下了定義，但由于自身背景與經(jīng)歷的不同，每個人對其都有不同的理解。從狹義上講，持續(xù)集成可以認(rèn)為是一種基于某種或者某些變化對軟件系統(tǒng)進(jìn)行的經(jīng)常性的構(gòu)建活動（注：這里的構(gòu)建活動不僅指編譯打包工作，還包含各類自動化測試、部署及發(fā)布活動）。然而，它忽視了一點(diǎn)，即：任何實(shí)踐中都應(yīng)該包含“與人的交互”這一因素。因此，從廣意上講，持續(xù)集成應(yīng)該是軟件開發(fā)團(tuán)隊(duì)在上述活動的約束下所采用的整個開發(fā)流程及活動。它強(qiáng)調(diào)開發(fā)團(tuán)隊(duì)與持續(xù)集成系統(tǒng)之間的互動性。我們既見過持續(xù)集成做得非常成功的團(tuán)隊(duì)，也見過效果不佳的持續(xù)集成，甚至失敗的案例。
那么，到底如何從持續(xù)集成中得到最大的收益呢？這要從持續(xù)集成所涉及的諸多方面進(jìn)行分析，并根據(jù)團(tuán)隊(duì)具體情況（比如團(tuán)隊(duì)規(guī)模、人員組成以及是否為分布式團(tuán)隊(duì) 等）及所開發(fā)軟件自身的特點(diǎn)（是企業(yè)應(yīng)用軟件，還是中間件？是嵌入式軟件，還是互聯(lián)網(wǎng)產(chǎn)品等）制定實(shí)踐策略與實(shí)現(xiàn)步驟。本專欄將與大家共同探討與持續(xù)集成、持續(xù)部署及持續(xù)交付相關(guān)的方法、工具與經(jīng)驗(yàn)。作者本人在Thoughtworks公司曾參與的一款持續(xù)集成與發(fā)布管理產(chǎn)品Go的交付和對外咨詢服務(wù)為專欄提供了很有素材，同時感謝肖鵬 、 李彥輝 、胡凱 、李劍等對欄目內(nèi)容的支持和幫助。
在軟件開發(fā)中，持續(xù)集成實(shí)踐能夠解決的問題是盡早的集成和盡早的反饋。因此，盡管目前流行的所有版本控制工具都提供了分支/合并功能，但在少于20人的團(tuán)隊(duì)中實(shí)現(xiàn)持續(xù)集成的話，推薦使用Single Branch開發(fā)策略。這樣會減少多分支在合并時的開銷。另外，由于理想情況下，每個分支都需要有專屬的持續(xù)集成環(huán)境（包括持續(xù)集成服務(wù)器、構(gòu)建環(huán)境和測試環(huán)境等），所以Single Branch也減少了對持續(xù)集成環(huán)境的需求量（當(dāng)編譯時間較長或測試用例較多時，這個因素的影響尤其重要）。
當(dāng)團(tuán)隊(duì)完成最初搭建持續(xù)集成服務(wù)器，編寫好一鍵式編譯和測試腳本工作后，就需要考慮如何利用持續(xù)集成環(huán)境高效地進(jìn)行團(tuán)隊(duì)協(xié)作開發(fā)了。一定有人會問：
“多人同時在一個分支上開發(fā)的話，每個人提交時都要合并代碼，不是更浪費(fèi)時間嗎？”
這個問題也正是持續(xù)集成期望解決的問題。每當(dāng)開發(fā)人員提交代碼時，就是其與其他開發(fā)人員工作成果的一次集成。如果每個人都能夠頻繁提交代碼，那么代碼集成的頻率就會提高，在持續(xù)集成的有力支持下，代碼中潛在的問題就會更早地暴露出來（比如代碼編譯鏈接問題，自動化測試失敗反映出來的代碼功能問題，或需求理解不一致等問題），以便團(tuán)隊(duì)盡早解決之。
當(dāng)然，持續(xù)集成所鼓勵的頻繁提交并不是指那種僅將版本控制庫當(dāng)成備份工具，無約束的“隨意”提交，還需要團(tuán)隊(duì)開發(fā)流程約束的。下面我們來一同探討“持續(xù)集成環(huán)境中的團(tuán)隊(duì)開發(fā)流程是什么樣的”。
讓我們先設(shè)想一個軟件開發(fā)場景。
一、使用版本管理工具做備份
故事的主人公叫Joe，他打算寫一個游戲，所以用Subversion建立了一個版本控制庫用于保存代碼，然后就動手寫代碼了。Joe的開發(fā)流程是這樣的。
- 從代碼庫中簽出一份代碼；
- 為增加某個功能修改一些代碼；
- 在本地運(yùn)行了一下自動化測試；
- 測試通過之后，提交代碼到版本控制庫；
- 重復(fù)前面的步驟。
如圖1所示。
二、搭建持續(xù)集成服務(wù)器做自動構(gòu)建
“每次在本地手工運(yùn)行自動化測試太麻煩了，”Joe想到，“這種重復(fù)的工作為什么不讓機(jī)器來做呢”。
于是，Joe上網(wǎng)查了一下，發(fā)現(xiàn)持續(xù)集成工具是做這個事情的，就找來一臺舊機(jī)器，用CruiseControl搭建了一個持續(xù)集成服務(wù)器。他的開發(fā)流程也變?yōu)椋?/p>
- 從代碼庫中簽出一份代碼；
- 開發(fā)新功能或修改bug；
- 提交到版本控制庫，思考下一個功能的實(shí)現(xiàn)；
- 持續(xù)集成服務(wù)器運(yùn)行自動化構(gòu)建和測試；
- 如果測試通過，轉(zhuǎn)到步驟(1)；
- 如果測試沒有通過，轉(zhuǎn)到步驟(2)。如圖2所示。
三、多人并行開發(fā)
兩周后，游戲初見原型，Joe向他的幾個朋友介紹了他的游戲創(chuàng)建，他們都非常喜歡，因此也加入了游戲開發(fā)。麻煩很快就出現(xiàn)了。持續(xù)集成服務(wù)器中構(gòu)建結(jié)果經(jīng)常失敗，所以每次簽出代碼后都要做問題清理工作。于是，Job與朋友們坐下來討論如何解決這個問題。
Alice說：“我們每個人都拉一個獨(dú)立分支，當(dāng)每個人的功能開發(fā)完成以后，再合并到一起不就行了嗎？”
Joe不同意這樣的做法。“游戲的需求還不明晰，要經(jīng)常合在一起看一下效果。所以還是在同一個分支上開發(fā)吧。下面，我們討論一下如何讓這種失敗少一些吧。”
于是，他們花了點(diǎn)兒時間，發(fā)現(xiàn)有兩個主要原因?qū)е率 ?/p>
- 本地代碼有問題，原本就編譯不了或會導(dǎo)致測試失敗，但還是提交了；
- 開始做新功能時，沒有特別注意分支上的持續(xù)集成狀態(tài)，直接將主分支上的代碼直接就與本地代碼合并了。
Joe提出，開發(fā)流程應(yīng)該變成如圖3所示：
- 每個人在開發(fā)新代碼之前，只能從持續(xù)集成已成功的那個最新版本簽出代碼；
- 開發(fā)新功能或修改bug；
- 提交前將主分支上的代碼再次取到本地合并；
- 運(yùn)行本地測試，確保測試可以通過；
- 提交代碼到主分支，由持續(xù)集成服務(wù)器再次運(yùn)行測試。
- 如果測試通過，轉(zhuǎn)到步驟(1)；
- 如果測試沒有通過，轉(zhuǎn)到步驟(2)，直到修復(fù)持續(xù)集成上的構(gòu)建。
可是，Alice提出反對意見。她認(rèn)為：“既然本地已經(jīng)運(yùn)行了測試，為什么還要在持續(xù)集成服務(wù)器上再次運(yùn)行呢？”
Joe解釋到：“主要是因?yàn)槲覀兠總€人的本地環(huán)境都不完全相同，很可能出現(xiàn)‘它在我的機(jī)器沒有問題呀’的這個現(xiàn)象，所以還是要在獨(dú)立的持續(xù)集成服務(wù)器上再運(yùn)行一次。”
因此，大家就這么決定了。
四、兩次本地構(gòu)建的目的
四周后的一天，Joe花了很長時間完成了某個新功能后，打算提交了。于是他把分支當(dāng)前的代碼與其本地代碼進(jìn)行了一次合并。然后運(yùn)行了本地測試，但測試失敗了。他用了很長時間來定位該問題是在他自己修改的功能里，還是在被合入的代碼中。這讓他對提交流程進(jìn)行了反思。
“要是在合入他人代碼之前，能夠先運(yùn)行一次本地測試，驗(yàn)證一下我的代碼沒問題就好了，反正本地測試所花的時間也不長。”
于是，他把這個想法告訴了其他人，最后大部分人都同意這么做。于是，其提交流程就變成了這樣：?
- 每個人在開發(fā)新代碼之前，只能從持續(xù)集成完全成功的那個最新版本簽出代碼；
- 開發(fā)新功能或修改bug；
- 運(yùn)行本地測試，如果有失敗就立即修復(fù)，直至測試成本；
- 提交前將主分支上的代碼再次取到本地合并；
- 運(yùn)行本地測試，確保測試可以通過；
- 提交代碼到主分支，由持續(xù)集成服務(wù)器再次運(yùn)行測試。
- 如果測試通過，轉(zhuǎn)到步驟(1)；
- 如果測試沒有通過，轉(zhuǎn)到步驟(2)。
這個過程就被稱為“Check-in Dance”。
Alice還說道：“我們在從主分支上簽出代碼時，一定是那個通過持續(xù)集成驗(yàn)證的最新版本。這樣可以避免簽出的代碼就是有問題的，而影響自己本地的代碼。”整個過程如圖4所示。
五、持續(xù)集成令牌
過了幾天，有人把大家叫到了一起，這次是Alice。她說：
“我今天遇到一個問題。我提交代碼之后，正等著持續(xù)集成服務(wù)器返回結(jié)果呢，Bob就提交代碼了。幸好我提交的代碼通過了測試，否則的話，我就要在Bob的代碼之上修復(fù)啦。所以，我建議我們需要設(shè)立一個提交令牌，只有拿到這個提交令牌的人才能提交。也就是說，當(dāng)一個人做完本地測試之后，去拿這個令牌。拿到之后，再進(jìn)行代碼合并、本地測試和提交。提交以后當(dāng)持續(xù)集成服務(wù)器返回成功通過的結(jié)果時，才能交還令牌。這樣就不會出現(xiàn)我和Bob這種情況了。”
可Bob并不同意這樣的做法，“這次沒有出什么問題，為什么還要這么做呢？”
此時，Joe把話接了過來，說道：“Alice的這個建議很好，我已經(jīng)遇上過一次這樣的事情了，那次測試失敗以后，我花了很長時間才發(fā)現(xiàn)問題并不在我的提交中，而是在Mary的提交中。我把它修復(fù)后，又做了一次提交。”由于大多數(shù)人都同意這么做，因此團(tuán)隊(duì)決定試一試。因?yàn)槟壳皽y試運(yùn)行時間很短，所以提交和集成工作沒有遇到什么瓶頸。提交流程如圖5所示。
似乎事情到這里就結(jié)束了。然而，這個游戲被某投資公司看中，決定做更大的投入，招更多的開發(fā)人員，讓它成為一個開放游戲平臺。那么，接下來Joe與他的朋友們還會遇到哪些問題呢？
it知識庫：持續(xù)集成之戲說Check-in Dance，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
