大型网站的功能上线控制流程篇 2 -- 代码控制

    配合上面feature上线的控制流程，我们再从版本配置的角度来看看code上线的控制流程。
    大型网站中features集的多小组并行开发和集体上线是其常态，该特点对于各开发小组间的代码的同步，以及最终的合并上线的影响是至关重要的。

    在clearcase中，我们都会有一条主干，而依据我们上文的“大型网站的功能上线控制流程篇 1”中所提到的开发分类中（详见该文中“我们先将我们日常的开发内容简单地分为以下几类......”）
    对于#1和#2来说（不论新feature的上线还是老feature的更新或是下线）
    从单一个项目开发角度出发，流程很简明：

1. 从主分支上拉出项目分支A，进行开发
2. 期间可以有几轮的rebase，通常配合上线节奏，每个时间槽（两周）之后进行一次，同步主分支上新features的代码
3. 在QA进行功能测试前，进行最后一次rebase（通常也是发生在进入功能测试前），代码随即冻结。
4. QA进行功能测试，期间有bug fixing（通常是两周）
5. 功能测试结束后，合并回主分支（一周）
6. 进行集成测试，并修复由于合并代码后产生的bug（一周）
7. 最后统一上线（一周）

    而对于在同一时间槽集体上线的多个项目来说

• #1，#2大家可以依据各自项目的实际需要自行安排
• #3 各项目组的最后一次rebase的主分支点必须得是相同的，也即本组feature集上线时间槽，往回推4周的代码基线点（#6 + #5 + #4）
• #4 通常是两周，或者更长
• #5 有了#3的保证，各组feature间的代码冲突量会急剧减少（仅会留下只与项目自身相关的，且确需合并更新的代码冲突），进而#6的有效工作量也会减少并顺利许多
• #6 集中精力解决掉由于合并后的代码冲突导致的bug

注：我们同一类型的工作的基本时间单位是一周，目的一是要保证多项目的平稳完成，目的二则是保证切分和安排的合理性