项目配置管理方案－－确定软件开发过程
今天是个普通的日子，象平时一样忙碌。但对于服务平台项目的服务安全项目小组，今天是个特殊的日子，因为早上我作为配置管理咨询的角色与项目负责人一起确定项目如何执行配置管理。也许大部分人认为这也不是什么大事，但至少我们认为决定项目未来几年的工作方式的事情应该算是大事情，马虎不得。
这个讨论进行了二个小时左右，一切顺利，确定了依据项目特性制定的配置管理方案。
这个项目的主要特点是维护项目，已有成熟的几个版本在VSS库中维护；组件、模块架构清晰、明确；总体规模不大，人员较少；因而，此项目的特殊之处在于将原VSS库中的既有代码历史记录全部导入ClearCase中，而且ClearCare是使用适合组件架构的UCM（统一变更管理）模型。其它工具还确定了使用ClearQuest来管理缺陷，使用Confluence记录项目信息，使用QuickBuild及Ant来执行每日编译。
交流过程中了解到，系统的架构是组件化的，各个部分比较独立，这很适合UCM的组件化管理。其次，在原VSS中各组件已按目录组织好各个主要版本，这样就为组件提供了很好的基线，只是需要一个一个地使用clearfsimport（自动处理增删改的情况）导入。通过这两方面的准备，组件及其基线就能准备好。
接下来是项目和流的设置。在实际项目中，一般是有一个产品，再对其不同的版本组建不同的项目，并有一个项目名，所以对应的，CC的PVOB一般对应为产品名，并为实际项目创建CC project。当然因为创建复合基线和处理发布等原因，可能创建多于实际项目的CC项目。在这个例子中也不例外，我们创建了一个实际项目，因为没有项目别名，就直接命名为Product_V2.4了。至于流是比较灵活的。项目经理知道目前只有一个团队在开发，人员不超过6人，所以我们决定为十人以下的项目制定多流模式，一个集成流，一个共用的开发流。
在考虑视图策略时，我们觉得静态视图对开发的性能相对要高，对调试有好处，于是决定开发人员使用静态视图，全部数据都存放于本地，服务器不保留这个视图的数据，只在CI时同步VOB数据。但为方便所有人访问VOB，会为集成流和开发流各创建一个公共的视图，这样就能供所有人随时访问最新内容。
...
这个讨论进行了二个小时左右，一切顺利，确定了依据项目特性制定的配置管理方案。
这个项目的主要特点是维护项目，已有成熟的几个版本在VSS库中维护；组件、模块架构清晰、明确；总体规模不大，人员较少；因而，此项目的特殊之处在于将原VSS库中的既有代码历史记录全部导入ClearCase中，而且ClearCare是使用适合组件架构的UCM（统一变更管理）模型。其它工具还确定了使用ClearQuest来管理缺陷，使用Confluence记录项目信息，使用QuickBuild及Ant来执行每日编译。
交流过程中了解到，系统的架构是组件化的，各个部分比较独立，这很适合UCM的组件化管理。其次，在原VSS中各组件已按目录组织好各个主要版本，这样就为组件提供了很好的基线，只是需要一个一个地使用clearfsimport（自动处理增删改的情况）导入。通过这两方面的准备，组件及其基线就能准备好。
接下来是项目和流的设置。在实际项目中，一般是有一个产品，再对其不同的版本组建不同的项目，并有一个项目名，所以对应的，CC的PVOB一般对应为产品名，并为实际项目创建CC project。当然因为创建复合基线和处理发布等原因，可能创建多于实际项目的CC项目。在这个例子中也不例外，我们创建了一个实际项目，因为没有项目别名，就直接命名为Product_V2.4了。至于流是比较灵活的。项目经理知道目前只有一个团队在开发，人员不超过6人，所以我们决定为十人以下的项目制定多流模式，一个集成流，一个共用的开发流。
在考虑视图策略时，我们觉得静态视图对开发的性能相对要高，对调试有好处，于是决定开发人员使用静态视图，全部数据都存放于本地，服务器不保留这个视图的数据，只在CI时同步VOB数据。但为方便所有人访问VOB，会为集成流和开发流各创建一个公共的视图，这样就能供所有人随时访问最新内容。
...
