基于CVS的配管探讨(xiaohp).pptVIP

分支管理－解决多分支共有BUG 多分支共享的主线代码出现Bug时，如何解决？ 分支管理-使用建议 分支尽可能短 分支结构尽可能简单 及早和经常的合并 集中精力于“主线”的演进 代码集成－DailyBuild-1 一个产品可能包含多个子系统和很多模块，如STARVSM2.3。当产品发布时所有的子系统是作为整体进行发布的 几乎每周，所有子系统都因Bug修复和新增功能在产生变化，而某个模块或子系统的变化又会影响其它子系统，如何快速响应变化？ 代码集成－DailyBuild-2 每日构建、持续集成是组间协同开发的最有效方式 DailyBuild的时间区：从集成测试到产品发布 DailyBuild的好处已修正Bug可以得到尽快的验证尽快验证某模块的变更是否影响其它模块尽量减少因代码集成带来的相互影响时刻保持产品整体版本的完整 软件发布－产品库管理 所有已发布的软件都应在产品库中进行备份 产品发布说明中应包含详细的bug 修复、新增功能、遗留问题等描述 如果某产品的发布频率很高（如IPG），产品的发布说明、发布报告等更不能省略 产品发布时，应对所有子系统、组件的代码打复合基线（即使只更新了某个子系统） 控制产品版本间的差异：哪些该做？哪些不该做？该在哪个版本中做？ * 谢谢！ * * * 基于CVS的配管探讨 xiaohp 2008年12月 * 配置管理的定义 配置管理是对产品生命周期内所选定的中间工作产品、产品组件以及产品的一系列管理活动。包括：配置项识别、变更控制、状态报告和配置审计等。 配置管理的目的是建立和维护在项目的整个生命周期中工作产品的完整性与一致性。 * 配置管理活动 * 配置项（Configuration Item, CI） 凡是纳入配置管理范畴的工作成果统称为配置项 配置项主要有两大类： 1)属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例、编译工具/构建工具等； 2)项目管理和支持过程产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。 每个配置项的主要属性有：名称、标识、文件状态、版本、作者、入库日期等。 配置项 vs. 工作产品 * 常用配置管理工具 CVS: Concurrent Versions System 即并发(或协作)版本控制系统，开源工具 SVN: Subversion几乎继承了CVS的所有优点，并在二进制文件管理、分支和基线管理等方面进行了加强 ClearCase:IBM Rational公司产品，在大型项目的配管工具中占统治地位，它有两个版本Base ClearCase和ClearCase UCM。不过这个工具的价格不菲。 CVS的不足 CVS的串行提交问题：批量文件一个一个的提交，当中途出现错误时会造成版本库处于不一致的状态，而且很难回滚 CVS不支持文件的改名，人为的对文件重名后版本历史丢失 CVS 只能对文件进行版本控制，不能对目录进行版本控制，因此CVS 没有任何关于文件移动（move） 操作的概念 二进制文件的修改只能进行冗余存贮，会浪费大量的空间 CVS的不足 CVS无法对分支进行注释，容易出现用户提交到错误分支现象 没有提交记录列表，无法按任务单元进行版本管理 由于CVS的代码结构存在问题，虽然是开源项目，但今后的扩展空间已经很小 代码提交－Task_based 任务单元(Task)就是一个相对独立的功能或工作单元。一个Task通常会影响多个文件，部分文件的提交会影响别人在代码更新后的阅读和编译任务单元列表会清楚的反应版本变更信息 常见错误文件频繁提交，把CVS服务器当作了文件备份服务器!文件无规律提交，不是基于独立的Task,提交粒度过大或过小 代码提交－开发流与集成流 每个开发者都有独立的开发工作区，项目集成前开发者在自己的开发流上进行代码的调试、签出、签入等操作，开发者之间互不影响 项目需要版本发布时，项目经理和SCM把多个开发流中的变更集成到新版本中，并保证代码集成时不存在冲突 开发流与集成流的分离，有效减少了并行开发的冲突，同时使主线代码相对稳定 代码提交－CVS多人协同开发 CVS没有独立的开发工作区，如何解决多人的协同开发？ STAR当前工作模式是多人代码在本地开发，然后集成，再由一人统一进行提交QA：如何及时获得别人的代码？－拷贝QB：如何进行快速的代码集成？QC：如何查找版本变化的中间信息？ IGP项目解决方法：针对分支建立开发工作区是否合理？ 代码提交－如何避免冲突 现象：开发人员提交代码时，经常出现版本冲突的提示，即服务器的代码版本比你当前工作的文件版本号更高（冲突代码只能进行merge） 解决A、开发人员在代码提交前，应把当前所有文件的工作版本更新到与服务器一致B