图三 取基线差程序

        最后，规范维护项目发布过程。在发布时间到达后，项目经理提交发布任务给配置管理员。配置管理员将测试流上多次确认测试通过的活动集交付（deliver）到集成流，并在集成流上打一条产品基线。配置管理员通过取基线差程序获取更新包后，然后更新发布测试环境，由测试人员进行发布确认测试。发布确认测试主要是对系统基本集进行验证。当发布确认测试通过后，配置管理员将更新包发给发布专员，由发布专员更新到生产环境。通过这种方式，可以保证发布程序是由配置管理员从集成流获取，同时确保发布程序是经过测试的。

3.6 规避活动依赖并控制变更处理顺序
        在并行开发章节中我们提到了共享开发流方式很容易引起交付依赖。在EIP项目中，开发人员同时面对变更、缺陷、任务等多个活动，很容易出现活动的依赖。一旦出现活动依赖，配置管理员在提取更新包供测试时，会存在一定的困难。如果取文件的最新版本，有可能因最新的文件包含某些不稳定的新增功能而导致编译失败。

        为了解决这个问题，我们通过使用触发器的方式进行开发流活动依赖的限制。当源码上一版本关联的活动未验证通过并关闭时，则不允许该源码检出。这个方法不仅控制活动的依赖，而且从限制了EIP项目控制变更的处理顺序（第一批变更未处理完，不进行第二批变更的处理）。

四、小结

        采用上述方法，EIP项目杜绝了发布程序版本混乱的问题，而且减少了变更处理周期，保证了发布进度。现在项目组从开始处理变更，测试变更，到该变更发布，一般只需要1周时间，工作效率提高了200%，业务部门对该项目的满意度也增加了。

        这里需要提醒的是，新方法虽好，但是在引入新方法初期，一定需要有专人配合、指导项目组使用，以保证新方法成功实施。在EIP项目在引入该方法初期，项目管理人员不理解，觉得增加了人力成本（需要多个角色人员）、环境投入（需要额外的发布测试环境），影响了开发进度（文件的检出修改限制）；开发人员觉得开发变麻烦了（文件的检出修改限制）。通过管理员的耐心解释和辅导，经过三个星期的磨合与适应后，EIP项目已完全遵循这种方法进行配置管理和发布管理工作。

        通过上述例子说明，采用IBM Rational ClearCase和ClearQuest，实实在在的帮助公司的维护型项目提高了配置管理能力，增强了公司的竞争力。