左叶小说网

手机浏览器扫描二维码访问

第14部分（第3页）

我觉得你们应该改进一下。

阿捷：哦？

敏捷圣贤：你们现在每个人都会接到反馈的电子邮件。

E…mail一多，大家很快就会将持续集成反馈看做垃圾邮件，进而忽视它们。

你们需要指定一个人专门负责检查关于构建的E…mail。

只有构建失败时，才把邮件发给引起失败的人，这样大家才会重视。

阿捷：嗯，有道理，值得改进。

敏捷圣贤：第五个反模式是用于进行构建的机器性能太低，导致构建时间太长，严重影响频繁地执行集成。

阿捷：呵呵，我们有5台超强的HP…UX服务器，可以实现自动负载分担，并行构建！

这样每次构建，不会超过1小时。

一说到这些，阿捷还是很自豪的，Agile公司财大气粗，硬件环境绝对一流。

敏捷圣贤：嗯，真羡慕你们公司！

最后一个反模式是膨胀的构建，导致反馈延迟。

阿捷：膨胀的构建？

敏捷圣贤：譬如，把太多的任务添加到提交构建过程中，比如运行各种代码自动检查、统计工具或运行性能测试，从而导致反馈被延迟。

阿捷：噢，这个我们倒是应该引起足够的警惕。

敏捷圣贤：其实，还有其他一些反模式的，这些持续集成CI　反模式会妨碍团队从持续集成实践中获得最大的收益，所以一定要想办法限制这些反模式发生的频率。

阿捷：是啊！

对我们没有多少持续集成经验的团队来说，持续集成像一块吊得很高的饼，看得见却摸不着。

要做好持续集成并不容易，但我们可以使用持续集成的思路，来接近持续集成的目标。

敏捷圣贤：嗯，加油！

我有点事情，先下去了。

886。

阿捷：886。

第11章　你开车，我导航（1）

Among　any　three　people　walking；　I　will　find　something　to　learn　for　sure。

　Their　good　qualities　are　to　be　followed；　and　their　shortings　are　to　be　*oided

三人行，必有我师也。

择其善者而从之，其不善者而改之。

——孔子

阿朱上次跟阿捷谈过持续集成后，第二天就召集所有的人开了一次会，把自己的想法跟大家讲了一下，大家纷纷说好！

并当即进行了分工，阿朱和阿紫负责产品自动安装和验收测试中的自动化，大民、小宝负责自动编译、自动UT、自动打包部分，最后再由阿朱进行总的集成。

因为TD的OSS　产品很庞大，再加上历史积累下来的回归测试用例很多，大家决定将持续集成、自动测试的频率设为每天进行一次。

大家还为整个过程起了一个很好听的名字　——“AutoVerify”

，意指自动进行产品的验证。

同时大家还讨论了一些实现细节。

大家晚上下班之前，把自己Check　Out出来的代码Check　In到代码库中。

AutoVerify程序会在每晚8：00自动从代码库中提取最新的代码，自动进行编译，编译成功后同时启动两项任务：一个进程进行自动UT，另外一个进程进行打包并自动部署到测试环境中。

这是因为UT的时间非常长，需要两个小时左右才能跑完全部的868个测试用例。

这样二者并行进行，可以节省两个小时的时间，多跑一些回归测试用例。