基于CVS的配管探讨(xiaohp)

1 基于CVS的配管探讨 xiaohp2008年12月 2 配置管理的定义 配置管理是对产品生命周期内所选定的中间工作产品 产品组件以及产品的一系列管理活动 包括 配置项识别 变更控制 状态报告和配置审计等 配置管理的目的是建立和维护在项目的整个生命周期中工作产品的完整性与一致性 3 配置管理活动 4 配置项 ConfigurationItem CI 凡是纳入配置管理范畴的工作成果统称为配置项配置项主要有两大类 1 属于产品组成部分的工作成果 例如需求文档 设计文档 源代码 测试用例 编译工具 构建工具等 2 项目管理和支持过程产生的文档 这些文档虽然不是产品的组成部分 但是值得保存 每个配置项的主要属性有 名称 标识 文件状态 版本 作者 入库日期等 配置项vs 工作产品 5 常用配置管理工具 CVS ConcurrentVersionsSystem即并发 或协作 版本控制系统 开源工具SVN Subversion几乎继承了CVS的所有优点 并在二进制文件管理 分支和基线管理等方面进行了加强ClearCase IBMRational公司产品 在大型项目的配管工具中占统治地位 它有两个版本BaseClearCase和ClearCaseUCM 不过这个工具的价格不菲 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 开发人员在最新代码基础上进行自测 自测合格的代码再进行提交C 最后的代码更新与代码提交的时间差应是越短越好 防止别人在时间差内提交新内容 代码提交 签入代码的质量 现象 显而易见的错误经常被提到主线上 还有一些是提交疏忽造成的错误 不幸的是CVS无法回滚 这些错误将始终保留解决建议A 检查单元测试代码 确保进行了代码自测B 引入同行评审或称codereview机制 代码提交 CodeReview的作用 在项目早期发现BUG 可以及时修正缺陷帮助普通开发人员认识到错误 提高代码质量 提高开发人员的代码能力避免开发人员犯一些很常见 容易疏忽的错误促进开发组内的人员沟通 使全体项目人员了解所有的代码变更保证项目的代码质量可控 使项目中所有代码质量趋于一致 基线 Baseline 基本概念 在项目生命周期的不同阶段 通过对配置项的正式评审和验证 使其进入一种受控状态 基线通常与项目里程碑同步 是一个相对稳定的结果集基线是项目进一步开发 完善的基准点和参考点 代码基线需要充分的 测试和 测试 有重要的里程碑意义 15 基线管理 代码基线作用 重用性 客户化时从基线开始起步 可以有效重用以前的项目成果 提高开发效率基准性 当出现难以追踪定位的BUG时 通过与基线版本的比较 为问题的解决提供很好的基准可重复性 已发布版本的代码通过Tag取得 并可以重新发布 应保证重新发布的软件功能与原功能完全一致 基线管理 常见里程碑基线 基线管理 源代码基线示例 CVS源代码基线通过Tag实现 18 基线管理 基线与Tag的区别 软件的每次版本发布都需要打Tag 没有意义的冗余Tag应及时删除 可以对项目的部分文件打Tag 但基线应包含所有文件只有具有里程碑意义的代码Tag 才能成为基线 基线代码应放到基线库中基线应从主线上生成 Tag可以在任意的分支上生成 19 基线管理 清理无用的Tag 20 基线管理 CVS删除Tag 21 基线管理 Tag的范围 对于一个文件 多个文件 模块或者所有代码都可以分别打标签 Tag 为了识别Tag的作用范围 应可以通过Tag的命名加以区分 否则根据Tag取代码时会出现混乱例 IPG2 0 4 Template 20081014 22 基线管理 Tag用例 当出现客户化分支时 为了保证分支的扩展性 应在分支处打Tag 分支管理 branch 分支是为了实现软件版本控制 构建管理 版本发布管理 软件并行开发等目的的重要手段对于一个文件 多个文件 模块或者所有代码都可以分别建立分支 小心分支的命名 开发人员在代码更新 update 修改 提交等操作时 要清楚自己所处的分支Tag创建 版本发布时应标明代码包含的分支 分支管理 BugFix分支 软件新增功能与bug修复功能应区别处理 新增功能沿主线增长 定期发布 Bug分支应独立增长 并定期回归到主线 25 分支管理 并行开发示例 Rel1 Rel2 Rel1 p1 分支管理 产品分支 可能出现同一产品的多个版本同时处于发布状态 其代码维护应在不同的分支上进行分支增长应围绕主线进行 不能生成的过长 分支管理 代码集成分支 在快速开发模型下 代码可能会需要多次集成 持续发布 为了避免新增功能的开发与集成测试的冲突 应建立集成分支 分支管理 客户化分支 产品发布后 不同的用户可能会有个性化需求 针对不同的用户可以分别建立分支 分支管理 并行开发分支 为同一项目的每个开发人员都分别建立分支 开发人员在自己的分支上进行独立的签入 签出 调试等工作 当需要集成时由SCM进行代码的统一集成ClearCase通常采用这种分支方式进行并行开发 但针对个人的分支在独立的工作区中 不会进入集成流 即不影响别人 分支管理 关闭分支 需搞清楚的问题何时停止生长 停止时有何工作要做 合并打标签改名称 换位置报告 通知 分支管理 解决多分支共有BUG 多分支共享的主线代码出现Bug时 如何解决 分支管理 使用建议 分支尽可能短分支结构尽可能简单及早和经常的合并集中精力于 主线 的演进 代码集成 DailyBuild 1 一个产品可能包含多个子系统和很多模块 如STAR VSM2 3 当产品发布时所有的子系统是作为整体进行发布的几乎每周 所有子系统都因Bug修复和新增功能在产生变化 而某个模块或子系统的变化又会影响其它子系统 如何快速响应变化 代码集成 DailyBuild 2 每日构建 持续集成是组间协同开发的最有效方式DailyBuild的时间区 从集成测试到产品发布DailyBuild的好处已修正Bug可以得到尽快的验证尽快验证某模块的变更是否影响其它模块尽量减少因代码集成带来的相互影响时刻保持产品整体版