軟件集成策略故事連載----構建錯誤是怎么來的

3．構建錯誤是怎么來的

回到工位，曉川跟師父聊起這些。師父說：“老劉當然沒法命令你了。他只是項目經(jīng)理，不是你部門經(jīng)理。他要是敢指責你，你就跟咱們領導說，有人給你撐腰。至于他不告訴你該怎么做，那要么是他也不知道，要么是他不愿意從他嘴里說出來。這人一看就是個老油條，你小心點兒。 ”

“謝謝師父提醒。 ”

都說公司里面有辦公室政治，看來確實是這樣啊，曉川心想。師父年長我很多，這方面我要多聽聽他怎么說。不過，到底為什么構建總是出錯呢？老劉說得也對，我得調查分析一下才能知道。

曉川著手調查。就以上個星期剛做完的集成為例吧。每次構建出錯，我是定位到出錯的源文件，然后通過源代碼版本控制工具查一下這個文件昀近是誰動過，然后就找相應的程序員去改正，然后把改正直接檢入到集成分支。嗯，那我去看一下在集成期間，是誰把改正檢入到集成分支上的，就能知道是誰的提交造成了問題。

曉川去查看源代碼版本控制工具的版本庫中集成分支上昀近所做的改動。咦，都是曉川改的……哦，是因為程序員都是跑到我的計算機上改的，所以都是以我的名義檢入的。唉，這么查，查不出來了。

曉川只好根據(jù)每次改動所改的具體文件去查。因為修改這個文件，讓編譯能通過，那意味著這個文件的前一次改動是有問題的。這樣，再去查這個文件當初是誰在哪個任務分支上改的，就能知道是誰在哪兒惹的禍了。

就這樣，曉川用了大半天的時間，到快下班的時候，整理出了一張表，表明這次集成遇到的每個構建錯誤，各是由誰，在哪個提交中帶進來的。下班啦！

下了班，曉川在外面隨便買了點東西吃。吃著吃著，覺得不對勁兒。倒不是吃的東西不對勁兒，而是想起了自己下班前的工作成果，覺得不對勁兒。

每個構建錯誤，確實是某個提交帶來的，確實是因為某個提交的存在而存在的。如果沒有那個提交，就沒有相應的構建錯誤。但是，這并不能說，這個提交本身是有問題的，是有構建錯誤的。因為程序員在提交前構建的內(nèi)容，并不是我構建的內(nèi)容。我構建的內(nèi)容，是多個提×××并到一起之后的內(nèi)容。

事實上，這正是老劉質疑我的地方。“如果程序員的提交都沒問題，你確定你構建的時候就肯定沒問題么？”我那時也覺得有點不對勁兒，自己的思路不嚴謹。怎么今天下午調查的時候又給忘了！不成，我得繼續(xù)研究清楚。不然一周后，新的一輪構建又要開始了，就顧不上了。

星期二上班，曉川來到工位，解鎖計算機，開始復現(xiàn)程序員在提交前的環(huán)境。這個比較簡單，因為程序員工作在任務分支上，在提交前把所有要提交的內(nèi)容都保存在任務分支上，所以，只要把任務分支末端的源代碼取出來，放到本地工作區(qū)里，就得到程序員在提交前的環(huán)境了。

在這樣的工作區(qū)里，曉川開始編譯構建。構建要一個多小時的時間，因為沒法做增量構建，只能全量構建。一個多小時后，構建結果出來了，構建是成功的！

曉川又做了幾個試驗。結果不盡相同。有的是成功的，有的報錯。雖然不能完全確定，但是憑記憶，應該就是在集成分支上構建時報的錯。這么說，集成分支上構建報錯，有兩種可能，一種是提交本身的問題，一種是幾個提交相互合并帶來的問題。在數(shù)量上，大概是一半兒一半兒。

得到了分析結果，曉川覺得挺有成就感。高興的時候想想，嗯，集成這工作呢，其實也挺輕松的，因為大部分時間都在等。等著程序員解決代碼合并沖突，等著構建。構建失敗了，等著相關的程序員修復。而有時候是大家一起陪著等。等著把提交的代碼都合并到集成分支，相關的程序員們才能回家。等出了基線，依賴于基線中內(nèi)容的新的任務才能開始。等著等著，時間就等過去了。青春就等過去了。

本文節(jié)選自《軟件集成策略》一書

董越 著.
電子工業(yè)出版社出版。