Eclipse方式： Processes that Adapt (part I)

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)
以前的开发是不公布源代码的，也很少交流。现在需要透明的开发过程。整个社群需要知道进行的如何，如何参与。需要开发式的参与，提高社群贡献的价值

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

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

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

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

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

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

每个周期的时间

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

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