Eclipse方式: Processes that Adapt (part I)

类别:Java 点击:0 评论:0 推荐:

John Wiegand 和 Erich Gamma 在EclipseCon 2005作了题为《Eclipse方式: Processes that Adapt》的主题演讲,阐述了为何Eclipse的开发过程如此成功。

里程碑(Milestones first)
每6个星期为一个周期。每个里程碑都市一次小的开发周期(mini dev cycle)。计划/执行/测试/回顾。里程碑式的开发减少了压力。

持续集成(Continuous integration)
完全自动化的系统构造和测试。每日的晚间构造会发现不同组件之间的集成问题。每周的集成构造和所有的自动单元测试必须成功执行(至少在我们自己使用的时候足够好)。里程碑的构造,则提供整个Eclipse社群使用足够好的系统。

总是beta (Always beta)
每一次构造都视为一个候选的release,我们期待它是可以工作的。组件团队每天使用最新的代码,项目组则使用集成后的,而社群则使用里程碑构造的系统。

集体参与 (Community involvement)
以前的开发是不公布源代码的,也很少交流。现在需要透明的开发过程。整个社群需要知道进行的如何,如何参与。需要开发式的参与,提高社群贡献的价值

问题: 没有人知道下一个里程碑中含有什么新功能 解决:发布新的和值得注意的功能(new and noteworthy)

持续的测试 (Continuous testing)
最初没有单元测试,这就好像蒙着眼睛开车。现在,有超过20,000个JUnit测试单元,和整个构建过程紧密的联系在一起。只有所有的测试都是绿色的时候(JUnit中,绿色表示测试通过),继承构造才能通过。我们有3种不同的测试: 正确性,性能,资源

结束游戏 (Endgame)
正式发布之前或有一次汇总过程(convergence process)。包括了一系列的测试-改正的过程。每一次这样的过程都会增加成本。关注于优先级高的问题。这里没有专职的测试员。

问题:很疲劳的过程 解决:分摊到每一次发布,而不是集中在里程碑之前

最终截止(Final Closure)
以The Elcipse Project Team的名义,发布"Eclipse x.x now available"

放松自己(Decompression)
每次release之后的恢复期。可以自由的去探索一些新的东西,回顾上一个周期(达成的任务,失败的地方,过程,小组之间的交流)。开始计划下一个release的过程。

每个周期的时间

Release 周期: 12-16 个月 里程碑: 9个月 结束游戏:1至2个月 放松期:1个月

这里是第一部分。详见eclipsepowered.org

本文地址:http://com.8s8s.com/it/it10980.htm