为什么IT软件项目的代码合并就是一个“噩梦”？

2011年，LinkedIn上市了，估值在100亿美元。它的会员在以每秒2个的速度增长，但它的交付过程存在很大问题，导致公司几乎停滞不前。这是在几乎所有超速发展的公司中都存在的普遍问题，但迄今为止，很少公司有足够的勇气把情况说出来。我们使用了一个火车发布模型。在这个模型中，每两周，一列“火车”就会带着新的代码离开车站，投入生产。为了搭上火车，你需要让代码进入发布分支。那时，团队在独立的功能分支上进行自己的任务，各个团队间在数周或数月的时间里是完全隔离工作的。

接着，在安排的发布日期前三周，所有功能分支的开发都会暂停下来，十几个团队会尝试将修改合并到发布分支中。合并的过程就是一个噩梦，开发人员几个月来编码所依据的假设已经不再有效。你所使用的类已不复存在，数据库架构也发生了变化，在几十个地方使用的API已经被重构了，UI看起来也完全不同，你认为最终已经从代码库中拿掉的JavaScript库现在又被用在十个新的地方。这些冲突要花好多天去解决，而在完成之后，你又意识到合并过程中有这么多的代码已经改变了，自己在功能分支上所做的大部分测试也变得没有价值了。

我们的测试还远远不够。我们进行了测试，但只对一部分代码进行了测试，仍然存在两个问题。第一，这些测试太慢了，真的很慢。构建的过程——编译、运行测试和封装，所花的时间是以10小时来计的。第二，这些测试并不可靠。其中有许多测试很诡异，会间歇出现失败。所以每次合并之后，大致每天都要构建一次，看看是否能正常工作。我们面对的是几十个测试失败，无从了解这些失败是由某个功能分支中的bug、有问题的合并，还是仅仅是测试出现莫名其妙的情况引起的。

假设我们能够使构建过程变得稳定，接下来的挑战就是整理汇集出部署计划。这是一个手工维护的wiki页面，它会列出发布时需要部署的所有服务，以及这些服务要按照什么顺序部署，需要进行什么配置。举例来说，假设你在功能分支上修改了B服务，为它添加了一个新的端点（endpoint），又修改了A服务调用这个新的端点，你就必须记住要把A和B这两个服务都添加到部署计划中，并且要指明B必须先行部署，这样新的端点才可供A使用。

如果你需要修改B服务的配置，比如增加其线程池的大小或者调整垃圾回收设置，也必须记得把这些修改放到部署计划中，因为所有的配置都是手工管理的。