软件集成策略故事连载----构建错误是怎么来的

3．构建错误是怎么来的

回到工位，晓川跟师父聊起这些。师父说："老刘当然没法命令你了。他只是项目经理，不是你部门经理。他要是敢指责你，你就跟咱们领导说，有人给你撑腰。至于他不告诉你该怎么做，那要么是他也不知道，要么是他不愿意从他嘴里说出来。这人一看就是个老油条，你小心点儿。 "

"谢谢师父提醒。 "

都说公司里面有办公室政治，看来确实是这样啊，晓川心想。师父年长我很多，这方面我要多听听他怎么说。不过，到底为什么构建总是出错呢？老刘说得也对，我得调查分析一下才能知道。

晓川着手调查。就以上个星期刚做完的集成为例吧。每次构建出错，我是定位到出错的源文件，然后通过源代码版本控制工具查一下这个文件昀近是谁动过，然后就找相应的程序员去改正，然后把改正直接检入到集成分支。嗯，那我去看一下在集成期间，是谁把改正检入到集成分支上的，就能知道是谁的提交造成了问题。

晓川去查看源代码版本控制工具的版本库中集成分支上昀近所做的改动。咦，都是晓川改的……哦，是因为程序员都是跑到我的计算机上改的，所以都是以我的名义检入的。唉，这么查，查不出来了。

晓川只好根据每次改动所改的具体文件去查。因为修改这个文件，让编译能通过，那意味着这个文件的前一次改动是有问题的。这样，再去查这个文件当初是谁在哪个任务分支上改的，就能知道是谁在哪儿惹的祸了。

就这样，晓川用了大半天的时间，到快下班的时候，整理出了一张表，表明这次集成遇到的每个构建错误，各是由谁，在哪个提交中带进来的。下班啦！

下了班，晓川在外面随便买了点东西吃。吃着吃着，觉得不对劲儿。倒不是吃的东西不对劲儿，而是想起了自己下班前的工作成果，觉得不对劲儿。

每个构建错误，确实是某个提交带来的，确实是因为某个提交的存在而存在的。如果没有那个提交，就没有相应的构建错误。但是，这并不能说，这个提交本身是有问题的，是有构建错误的。因为程序员在提交前构建的内容，并不是我构建的内容。我构建的内容，是多个提×××并到一起之后的内容。

事实上，这正是老刘质疑我的地方。"如果程序员的提交都没问题，你确定你构建的时候就肯定没问题么？"我那时也觉得有点不对劲儿，自己的思路不严谨。怎么今天下午调查的时候又给忘了！不成，我得继续研究清楚。不然一周后，新的一轮构建又要开始了，就顾不上了。

星期二上班，晓川来到工位，解锁计算机，开始复现程序员在提交前的环境。这个比较简单，因为程序员工作在任务分支上，在提交前把所有要提交的内容都保存在任务分支上，所以，只要把任务分支末端的源代码取出来，放到本地工作区里，就得到程序员在提交前的环境了。

在这样的工作区里，晓川开始编译构建。构建要一个多小时的时间，因为没法做增量构建，只能全量构建。一个多小时后，构建结果出来了，构建是成功的！

晓川又做了几个试验。结果不尽相同。有的是成功的，有的报错。虽然不能完全确定，但是凭记忆，应该就是在集成分支上构建时报的错。这么说，集成分支上构建报错，有两种可能，一种是提交本身的问题，一种是几个提交相互合并带来的问题。在数量上，大概是一半儿一半儿。

得到了分析结果，晓川觉得挺有成就感。高兴的时候想想，嗯，集成这工作呢，其实也挺轻松的，因为大部分时间都在等。等着程序员解决代码合并冲突，等着构建。构建失败了，等着相关的程序员修复。而有时候是大家一起陪着等。等着把提交的代码都合并到集成分支，相关的程序员们才能回家。等出了基线，依赖于基线中内容的新的任务才能开始。等着等着，时间就等过去了。青春就等过去了。

本文节选自《软件集成策略》一书

董越 著.
电子工业出版社出版。