持续集成之“依赖管理”(2)

　　Joe说道：“我们先梳理一下整个平台上的依赖关系吧。通常来说，软件中的依赖关系通常包括编译时依赖、测试时依赖和运行时依赖。而从依赖形式上可以分为库依赖和组件依赖。所谓库依赖，是指依赖于那些不受控的库文件，比如我们使用了一些开源或者付费的的类库文件或工具，这些库文件的特点是更新较慢，甚至基本不需要更新。而组件依赖是指依赖于那些由自己团队或公司内的其它团队开发的组件，这类依赖的特点是更新频率相对高，有些甚至非常频繁。对于库文件依赖，我们可以在代码库中建立一个目录，叫做lib，并在其下建立build、test、run三个子目录，把我们所依赖的库文件放到相应的子目录中。同时，每个库文件的文件名中最好包含它的版本号，如nunit-2.6.0.11089.bin。这样，就很容易看出依赖了哪些库文件。”

　　Bob接道：“可惜我们不是用Java平台，否则我们可以用象Maven或Ivy这样的工具来管理这些外部库依赖了。而且，同时可以在公司内部利用Artifactory或Nexus这样的开源工具建立一个内部统一服务器，专门管理公司内部所用的这些库依赖。”

　　Alice说道：“我们也可以自己做一个简单的依赖管理系统。比如使用Key-value的格式用文本文件来描述所用到的库文件名及版本号及存放位置，然后再写个通用脚本读取信息下载到本地使用。”

　　Bob接着问道：“对于这种库文件的依赖管理相对容易一些。而我们面临的重要问题好象是组件依赖管理。有什么好办法吗?”

　　Joe想了想，说道：“方法倒是有几个，各有优缺点。一种方法是将组件依赖转成库依赖。其适用的场景是该组件经过一段时间的开发的维护后已趋于稳定，变化不太多。此时就可以将这个组件打包后与其它外部依赖库放在一起，并加入正确的描述，以便依赖于它的所有组件都可以正确地拿到正确的版本。还有一种方法是我们目前所用的方法。即每个组件各自进行持续构建，然后再做集成构建。其中存在的问题是我们如何管理各组件不同版本之间的组合关系。我们一直使用的策略是无论哪次提交，都会触发整个构建。目前要做的有两件事：一是将公共库独立出来，进行单独构建，并且一旦构建成功，自动触发那些依赖于它的其它组件构建，最后进行集成构建。只要我们记录每次构建后的版本及源代码的revision就行，以便可以追踪。二是将游戏平台的持续构建触发其它游戏组件的持续集成。所以，触发关系应该是这样的。”Joe拿起笔，在白板上重新画了一下触发关系图(图2)。

　　Bob摇了摇头，说道：“这样还是解决不了我们之前说过的问题，即我们的发布频率不一致，如何来管理这些发布之间的关系。”

　　“噢，这个问题是这样的。”Joe回答道：“我认为，我们之前单独发布一个游戏组件是不对的。我们因市场压力而将该游戏组件直接部署到生产环境中，尽管在发布前的评估认为，该游戏所依赖的平台接口没有发生变化。正确的做法有两种：(方案A)将平台作为一个整体一同发布，因为我们对平台也做了修改，当时，所有的持续集成测试都是基于主干的最新版本所做的。(方案B)让所有游戏组件依赖于游戏平台的最新发布的稳定版本进行开发。由于平台的新功能开发较慢，所以只要平台接口不发生变更，各游戏应用都可以基于平台的稳定发布版本进行快速更新。但只要某个游戏需要修改平台的接口，就必须与平台的最新代码进行持续集成，并一同发布。”

　　Alice皱了皱眉，说道：“这么看来，对于整个软件来说，能够保持主干随时可以发布才更容易管理组件依赖。因为每当需要发布时，直接做主干发布就行了。实在不行的话，只要将所有组件在同一时间点拉出一个发布分支，然后统一上线就行了。”

　　Bob说道：“这样也有问题。我们的部署会很麻烦，时间可能会很长。”

　　Joe笑着说：“部署麻烦，我们可以通过一系统列的自动化操作来解决。部署时间长的话，我们使用的是集群部署，因此可以采用分批替换的方式来部署。但这种发布方式给我们带来的益处是可以很快的响应市场需求。”

　　Joe拿起杯子喝了口咖啡，接着说道：“当然，这对我们的开发工作也提出了挑战。我们必须使用多种手段才能做到主干持续可发布状态。比如(1)将新功能隐蔽起来，直到它完成为止;(2)把所有的变更都变成一次次非常小的增量式修改，每个修改都做到可发布;(3)通过抽象达到分支的目的(Branch by Abstraction)。另外，我们的自动化测试也需要保持在较高的覆盖率，并丰富其它类型的自动化测试，比如性能测试，压力测试等。如果遇到特殊情况，我们再坐下来商量对策。”

　　Bob仍旧有点迟疑，“这样可能会增加我们的开发成本。不过，可以试一下，看看效果如何。”

　　于是，整个团队开始行动起来了。他们在这条道路上还会遇到什么情况呢?让时间来回答这个问题吧。

原文转自：http://kb.cnblogs.com/page/101101/