一般而言，構(gòu)建的順序是本地構(gòu)建確保所有的功能運(yùn)行正常，然后提交等待持續(xù)集成工作正常。本地構(gòu)建超過 5 分鐘就變得難以忍受，大多數(shù)情況下我們希望這個反饋時間越短越好。項目的初期我們往往會運(yùn)行所有的步驟：編譯所有代碼，運(yùn)行所有大連軟件修復(fù)二次開發(fā)測試。隨著項目周期的變長，代碼的增多，時間會越來越長。在嘗試若干次重構(gòu)構(gòu)建腳本再也沒辦法優(yōu)化之后，“分階段構(gòu)建”成為絕大多數(shù)的選擇。通過合理地拆分、分層，每次運(yùn)行特定的步驟，例如只運(yùn)行特定的測試、只構(gòu)建必要的部分，然后提交，讓持續(xù)集成服務(wù)器運(yùn)行所有的步驟。這樣開發(fā)者能夠繼續(xù)進(jìn)行后續(xù)的工作。
即便本地快了起來，采用分階段構(gòu)建的大連微信公眾號停車場計費(fèi)系統(tǒng)開發(fā)團(tuán)隊很快也會發(fā)現(xiàn)，CI服務(wù)器的構(gòu)建時間也越來越讓人不滿意，每次提交半小時之后才能得到構(gòu)建結(jié)果太不可接受了。各種各樣的分布式技術(shù)被創(chuàng)建出來。除了常見的CI服務(wù)器本身提供的能力，許多團(tuán)隊也發(fā)明了自己的分布式技術(shù)，他們往往將代碼分布到多臺機(jī)器進(jìn)行編譯和運(yùn)行測試。這種解決方案能夠在比較長的一段時間內(nèi)生效——當(dāng)構(gòu)建變慢的時候，只需要調(diào)整分布策略，讓構(gòu)建過程運(yùn)行在更多的集群機(jī)器上，就可以顯著地減少構(gòu)建時間。
致遠(yuǎn)服軟認(rèn)為：http://www.soft8.com.cn/一些新的工具能夠顯著地提速開發(fā)人員的工作。JRebel能夠?qū)⑿枰幾g的Java語言變成修改、保存立即生效，減少了大量的修改、保存、重新編譯、部署的時間；Spork能夠啟動一個Server，將RSpec測試相關(guān)的代碼緩存于其中，這樣再運(yùn)行RSpec測試的時候就不用重新進(jìn)行加載，極大地提升了效率。
上述的大連軟件修復(fù)二次開發(fā)測試解決方案在特定的時間域內(nèi)很好地解決了一部分問題。然而，在項目運(yùn)轉(zhuǎn)一年、兩年或者更久之后，它們最終依然無法避免構(gòu)建時間變長、開發(fā)變慢、代碼變得混亂、架構(gòu)晦澀難懂、新人難以上手等問題。到底問題的癥結(jié)是什么？
人們喜歡簡潔，但這更多地看起來是一個謊言——沒有多少團(tuán)隊能夠自始至終保持簡潔。人們喜歡簡潔只是因為這個難以做到，并不是說人們不愿意如此。很多人都知道大連軟件修復(fù)二次開發(fā)測試不比其他的勞動力密集型的行業(yè)——人越多，產(chǎn)量越大。《人月神話》中已經(jīng)提到，項目增加更多的人，在提升工作產(chǎn)出的同時，也產(chǎn)生了混亂。短期內(nèi)，這些混亂能夠被團(tuán)隊通過各種形式消化；但從長期看來，隨著團(tuán)隊人員的變動（新人加入，老人離開）以及人正常的遺忘，代碼庫會逐漸失控，混亂無法被消化，而項目并不會停止，新功能不斷地加入，架構(gòu)就在一天天的過程中被腐蝕。
