建议用 Firefox 85+、Safari 14+、Edge 87+ 浏览
我的文章 我的评论 我的书评 我的知乎*
书单 书讯 书评
需求知识体系 特性 用例 统一用例方法 用户故事 需求工具
业务建模 UML OOD
敏捷知识体系 敏捷方法 敏捷问答 敏捷工具 敏捷评论 敏捷资源
业务模式 需求模式 架构模式 设计模式 大道至简:实话设计模式 Web 应用架构模式
.NET Java JS 笔记
Amazon* ITPub* Martin Fowler* 教程
需求分析需求模型非功能需求业务需求分析
SpringJSF
> >
在线/181 登录/0

案例分析:跌跌撞撞的持续集成之路

阅读数:10.5K
基本


问题描述


仝键在 InfoQ China 上发表了一篇文章《跌跌撞撞的持续集成之路》,介绍了他们团队尝试持续集成(CI)的情况。

这是一个典型的“欲速则不达”的例子。

“跌跌撞撞”反映了作者所遇到的困境。

他们遇到的问题是 build 时间太长,他们想了很多办法,做了几次改进。可是,最终的结果是:“build 一次已经占到了 100 分钟。第一期的产品 Backlog 还没有完成 1/3。”

很多人的建议都没有跳出 CI 的圈圈。

作者遇到的问题其实并不是孤立的。敏捷专家 Amr Elssamadisy 在 InfoQ 的另一篇文章 Is Pipelined Continous Integration a Good Idea? 中描述道:

One of the well-known practices of Agile development is Continuous Integration, which entails team members integrating their code regularly into the baseline and running all unit and system tests. In most teams a CI server is used to do this quickly and automatically when code is checked into the baseline. This usually works well in the beginning of a project, but sometimes, when the team and/or code-base get large, the CI server starts to slow down. The cycle between builds grows and the feedback degrades – a build may take an hour or more to respond with a pass/fail, and by that time several people may have checked in their code into an already broken build.


Elssamadisy 描述的情况和本案非常相似。

问题分析


首先,我们要问:我们究竟为什么要持续集成?CI 能给我们带来哪些好处?

其次,我们要问:如果 CI 带给我们的好处不抵我们的付出,或者得不偿失,那么我们是否还应该坚持 CI?

本案其实涉及到开发效率和开发质量的权衡。

解决方案


本案的解决方案,笼统地说,无非就两种:坚持 CI 的道路 和 放弃 CI 选用其他替代方案的道路。

1)坚持 CI 的道路

* 优化、缩短 build/test 的时间

软、硬件优化多管齐下,想尽一切办法让 build/test 更快,以获得更完整、可靠和迅速的反馈。

* Pipelined CI

这种方式存在较大的风险。Amr Elssamadisy 描述了他所遇到的现象:

Here's what I've seen when this happens:

1) Functional tests aren't run and build passes.
2) Someone checks in code, passes build, but breaks functional tests (and doesn't know it).
3) 5 others check in code in an (unknown to them) broken build.
4) The next stage finally catches up and breaks - but 6 people have checked in. They are *all* sure it wasn't their code that broke the build. So they expect the others to fix it.


2)放弃 CI 的道路

张恂建议:用 Daily Integration 取代 Continuous Integration


Martin Fowler 在他的经典文章 Continuous Integration 中谈到了 CI 实践的几个要点。

1) Maintain a Single Source Repository.
2) Automate the Build
3) Make Your Build Self-Testing
4) Everyone Commits Every Day
5) Every Commit Should Build the Mainline on an Integration Machine
6) Keep the Build Fast
7) Test in a Clone of the Production Environment
8) Make it Easy for Anyone to Get the Latest Executable
9) Everyone can see what's happening
10) Automate Deployment

在“每人每天提交”中,他写道:

My general rule of thumb is that every developer should commit to the repository every day. In practice it's often useful if developers commit more frequently than that. The more frequently you commit, the less places you have to look for conflict errors, and the more rapidly you fix conflicts.


他说的“commit to the repository”应该指提交(check in)到基线/主干(base line)上。

他还谈到了 CI 与 Nightly Build 的区别。

Many organizations do regular builds on a timed schedule, such as every night. This is not the same thing as a continuous build and isn't enough for continuous integration. The whole point of continuous integration is to find problems as soon as you can. Nightly builds mean that bugs lie undetected for a whole day before anyone discovers them. Once they are in the system that long, it takes a long time to find and remove them.


在“Keep the Build Fast”中,他介绍了 staged build(build pipeline)的概念,对于 build 时间很长的情况(比方超过 1 小时),可以采用 a two-staged build(commit build、secondary build)方式。

来源:微软中国研发集团服务器与开发工具事业部SQL中国研发中心博客

SQL Server Build 系统(刘春雨 SQL Server 中国 build 团队,2008-7-28)

先提两个问题:

1)如此成功的超大规模 build,微软是如何做到的?有什么杀手锏吗?

2)微软这么做,是不是敏捷?是敏捷,还是卓越?敏捷好,还是卓越好?

仝键:

另外,糖醋鼻子还提到了分支式开发,大家围绕这个还展开了激烈的讨论,不过我考虑到分支式开发对我们的利可能要远小于弊,最终还是放弃了这个方案。


为什么 Branch-Merge 对你们会弊大于利,你没有说明。问题可能恰恰出在这里。

刘春雨介绍了微软是如何解决这个问题的:

我们每天做这么多的 build 正体现了我们如何支持整个 SQL Server 工程体系和构架:

在 SQL Server 2008 的工程体系和构架中,我们将每个需要增加或增强的功能特性做成一个单独的分支,在这个功能特性开发和测试完成后,其代码才会合并到 SQL Server 的主线代码中 ... 每个分支都需要 build 来进行及时的测试,因此有了这个我们当前每周需要的 build 个数 —— 130。当 build 结束后,Test Execution team 和其分支团队会执行自动测试来确保其代码的质量符合严格的要求和标准。最后当这个功能特性开发和测试完成后,其代码将会融入到 SQL Server 的主线代码中,然后其它各个分支团队将重新获取主线代码并融合其分支的当前代码,来保证和主线代码的同步。

相关数据:

- 每个 build 的大小在 300GB 左右。
- 每个完整的 build 需要几十台高端的服务器运行 2.5 天。
- 每个完整的 build 由几千个 job、10000 多个参数组成。
- 我们每天同时做 20 个左右的 build,每周 130 个。
- 位于美国微软总部雷蒙德和北京的 build 团队能够保证 build 全天 24 小时不间断的顺利进行。
- 从去年至今,我们 build team 已经成功而准时地完成了数以千计的 build。


很高兴看到刘春雨的这段介绍,它们和十年前张恂从《微软的秘密》中所学到的方法是一致的。这说明过去十多年来微软一直在沿用这套成熟的方法,它们当然是软件工程中的 Best Practice。正是受到微软经验的启发,张恂带领的研发团队早在 2000 年和 CMM 热之前就做到了软件配置管理和 Branching-Merging,领先于当时国内软件同行业的水平。

你们的系统规模不可能比 SQL Server 更大吧?对于如此庞大系统的功能开发和质量保证,微软运用 Branching-Merging 显然是非常成功的。我觉得你们应该跳出“极限敏捷”和 CI 的圈子,试一试其他成熟的“敏捷”方法。

相关资源


InfoQ 上几篇相关文章:

Book Excerpt: Continuous Integration means Continuous Testing(中文:图书摘录:持续集成意味着持续测试

Is Pipelined Continous Integration a Good Idea?

其他相关资源:

Plastic SCM Blog: Integration strategies

Martin Fowler: Continuous Integration

学习持续集成必读的文章。

让开发自动化: 选择持续集成服务器(developerWorks)

比较了几种 CI 服务器。

Continuous Integration: Improving Software Quality and Reducing Risk (Meera Subbarao, JavaLobby Book Review)

Continuous Integration Using Team Foundation Build (Visual Studio 2005 Technical Article)

Steve McConnell: Daily Build and Smoke Test, IEEE Software, Vol. 13, No. 4, July 1996

McConnell 当年发表在 IEEE Software 上的有关每日建立与冒烟测试的经典之作,每个人都应该读一读。

Daily Builds Are Your Friend, By Joel Spolsky, 2001-Jan-27中文

曾经在微软工作过的 Joel 介绍了 Daily Build 的一些好处和细节。

<帮助> <全部评论> 共 0 个主题 0 条评论 (InfoQCIRoad)
首页 | 使用指南 | 站点地图 | 版权声明 | 联系方法 | © 2005-2022 张恂 版权所有. 沪ICP备15017521号-2