如何有效地进行版本控制和管理.ppt

1 如何有效地进行版本控制和管理 2 议程 配置管理的发展和最佳经验配置管理模式版本构造和发布管理UCM和perforce的版本控制播控组的实践经验 董全武 部门配置管理规程和指南 3 软件开发的混沌 版本较多 不知道如何选择一个合适的版本进行下一步的工作 你的团队经常得不到一个可以工作的版本而苦不堪言 有多个版本而不能很好的整合 用户出现问题 而你却无法获取和重构用户版本 变更无法追踪 无法有效的追溯版本的变化 你经常处在无法说清楚项目的真实状态 4 5 作业 你们项目组版本控制和管理存在什么问题 原因是什么 使用本培训的方法如何改进 要求至少提出2个问题 说明其原因改进方法应该明确并有可操作性周五前提交到li chunhua 6 如何避免 对症下药配置管理变更管理项目管理 对于开发者 最切实可行的就是版本控制和管理 7 第一代配置管理 时间七十年代开始特征基于文件 FileBased 的版本控制支持check out check in模型简单分支解决问题文件丢失和覆盖的问题 8 最佳经验 标识工件 将工件存入安全的版本库控制并记录对工件的变更保持稳定 一致的工作空间 9 第二代配置管理 时间八十年代中后期特征基于项目库将元数据与配置项分开存储管理从而更好地支持并行开发 团队协作以及过程管理解决问题并行开发 10 最佳实践 支持工件的并行开发及早集成 经常集成记录并追踪变更跟请求保证软件build可重现 11 第三代配置管理 时间2000年特征以活动为中心的组织和集成解决问题如何在复杂的软件开发中把握变更 12 最佳实践 将工件组织成版本化的构件 构件的引入 有利于逻辑设计和物理实现相对应 提供一种机制来更智能的创建和使用基线构件是对众多的文件进行合理分类以呈现系统的设计要素可以大大简化项目开发控制 可以通过合理的目录来组织构件以活动为中心的组织和集成建立活动 变更集的映射在项目里程碑处创建基线更好的标识阶段点和提供开发复用的基准 13 定义开发流程 确定代码线策略 集成规约和质量标准获取工作列表选择工作的代码线和获取一个可信版本在工作区完成单个任务 测试符合代码线策略后提交 反复执行集成人员根据集成规约进行集成 根据质量标准打标签 提交测试 符合质量后标识基线 通知相关人员更新代码 14 议程 配置管理的发展和最佳经验配置管理模式版本构造和发布管理UCM和perforce的版本控制播控组的实践经验 董全武 部门配置管理规程和指南 15 什么是模式 描述在我们环境中反复出现的问题 然后给出该问题的核心解决办法 以这样的方式 你可以上百万次地使用这种解决方法 而不会有两次一样 它描述了为了解决问题而定义的存在而不得不做的事情的规则 16 如何理解和使用模式 上下文何时应该考虑使用该模式问题说明该模式要解决的问题解决办法注意 模式如何互相关联与模式所解决的问题和解决问题的方法同样重要 17 模式纵览 与工作区相关的模式存储库私用工作区第三方码线任务级提交私用系统构造集成构造单元测试冒烟测试回归测试与码线相关的模式码线策略主线活动开发线私用版本任务分支版本线版本预备线 存储库模式 上下文为了创建私用工作区或者运行可靠的集成构造 你需要正确的组件 本模式介绍如何用必要的部件轻松的构造工作区 问题如何获得填充新工作区的正确组件的正确版本 解决办法一站式购物从单一访问点获取你的代码和有关人工制品 使创建开发者工作区尽可能的简单与透明 19 私用工作区模式 上下文你要确保正在跟最新的代码打交道 但是因为人们不能妥善的处理不可控制的变更 所以你要能控制何时开始跟其他开发者变更打交道 本模式描述如何调解总是使用当前码基进行开发的理想与当环境不停的变化时人们不能有效的工作的现实之间的紧张状态 问题如何跟上不断变化的码线并取得进展 而不会为你们自己造成的环境变化分心 解决办法以隔离工作的方法控制变更在私用工作区工作 在那里控制你正在做的代码和组件的版本 你可以完全控制你的环境何时以及如何变更 20 第三方代码线模式 上下文你的系统需要和外部组件相联系 本模式介绍如何跟踪自己的代码的方式 来跟踪第三方的组件问题什么是协调供应商代码的版本与产品代码的版本的最有效的战略 解决办法为第三方代码创建码线 用这条码线构造工作区和安装工具 21 任务级的提交模式 上下文如果知道哪些东西或变更参加了集成 集成构造时就比较容易排错 本模式讨论如何平衡对稳定性 速度和原子性的需要 问题在两次向版本控制系统提交之间 你应该做多少工作 检入文件之前 你应该等多长时间 解决办法每一项小粒度任务做一次提交每一项小粒度的 一致的任务做一次提交 22 私用系统构造模式 上下文私用工作区使得变更和其他外部变化隔离起来 但是你的变更又需要和系统其余部分打交道 为了验证这一变更 你需要以一致的方式构造系统 本模式说明如何在提交变更时检验你的变更是否与最新公布的码基一致 问题如何在检入你的变更前检验它们不损坏构造或者系统 解决办法通过本地构造实现全局考虑提交给源码控制之前 用私用系统构造来构造系统 23 集成构造模式 上下文各个开发在单独的私用区间变更 这些变更必须集成在一起 并且整个系统必须可靠的构造 本模式讨论有助于确保系统的代码总能构造的机制问题如何确保码基总能可靠地构造 解决办法进行集中式构造要确保用中央集成构造所有的变更以及其依存关系 这个构造过程应该是可重生的 尽可能接近最终的产品构造 自动化的或只是需要最少的人工干预 有识别错误与不一致的通知或日志机制 在你的版本控制系统中用标号标识这次构造 24 冒烟测试模式 上下文即使代码能够构造 仍需要检验以后可能使你出故障的运行问题 本模式讨论为了确认构造有效性而需要的决策 问题如何知道系统在你变更后仍能工作 解决办法验证基本功能每次构造都必须进行冒烟测试 以显而易见的方式验证应用未被损坏 25 单元测试模式 上下文在你做模块尤其是编写新代码时 冒烟测试对详细的测试变更是不够的 本模式向你介绍如何测试详细的变更 使得你能确保码线的质量 问题如何测试模块经你变更后是否仍能像预期那样工作 解决办法测试合同开发及运行单元测试 26 回归测试模式 上下文冒烟测试不详尽 单元测试局部化 如果要确定准备发布的版本 就需要确保码基是健壮的 本模式说明如何生成不比上次更差的构造 问题如何确保现有的代码没有因你进行其他改进而变得更糟 解决办法对修改进行测试每当要确保码线的稳定性时 就对系统运行回归测试 用过去使得系统出故障的测试用例创建回归测试 回归测试是黑箱测试 包括过去出现过的和预先考虑到的各种失效模式 27 码线策略模式 上下文当有多条码线时 开发者需要知道如何对待它们 本模式描述如何为每条码线制定与其用途相符的规则 问题开发者如何知道他们的代码应检入哪条码线 何时检入以及检入前要运行哪些测试 解决办法制定交通规则为各分支或码线正式规定策略 确定开发者应如何以及何时进行变更 策略应简明并可以审计 28 码线策略的依据 策略的制定是根据码线的用途决定的 一旦决定了码线需要稳定到何种程度以及如何通过过程达到这种稳定性 就需要把这些策略通知开发者 并实施这些策略 29 策略应包括 码线封装的工作类型 如开发 维护或具体的版本 功能 子系统各元素应该如何以及何时检入 检出 分支与合并对各人 各种角色和各组的访问限制导入 导出关系 期望接收变更以及需要传送变更的码线的名字码线工作期限或退休的条件预期的活动负荷以及集成频率 30 策略的例子 开发线可以检入临时的代码变更 受影响的组件必须是可构造的版本线软件必须能构造并通过回归测试才能检入 检入后的软件对排错是有限制的 不能检入新特征和新功能 检入后 分支冻结 直到整个质量保证周期结束 主线所有的组件都必须编译和链接 并通过回归测试 完整的 经过测试的新特征可以检入 31 主线模式 上下文在软件开发中 往往不得不调解并行的开发工作 版本控制工具提供分支与合并的设施 可以使用分支隔离并行工作 但是可能有代价 本模式使得分支与合并所要求的集成工作减少到最少 问题如何使得当前活动码线的数目保持在容易管理的水平 避免项目的版本长得太宽太密 如何使得合并得开销减少到最小 解决办法简化分支模型开发单个产品版本时 在主线上进行开发 主线是主码线 除了特殊情况之外 全部开发工作都在主线上进行 分支时 先考虑总体战略 然后再创建分支 拿不准时 尽量采用简单的模型 32 活动开发线模式 上下文当你在动态的开发环境工作时 许多人都在变更代码 小组成员都在为了使系统更好而工作 但任何变更都可能损坏系统 而且这些变更可能互相冲突 本模式帮助你在活动开发工作中 在稳定性和进展之间取得平衡 问题如何使得快速发展的码线足够稳定 可以使用 解决办法定义你的目标制定有效的码线策略 使得主开发线足够稳定 能够满足工作需要 不要追求完整的活动开发线 而是力争主线足够有用与活动 能满足你的需要 33 私用版本模式 上下文你要在维持 活动开发线 的同时迅速评价可能损坏系统的复杂变更 本模式描述如何在不会无意的影响全局历史的情况下维持本地的跟踪能力 问题如何进行复杂的变更的实验 如何利用版本控制系统使这样的变更不会公开 解决办法私用历史给开发者提供一种机制 让他们能以他们感到舒适的粒度 为变更设置检查点 这可以通过本地版本控制区提供 只是把稳定的代码集合检入项目存储池 重要的是 确保使用私用版本的开发者记者按合理的时间间隔把变更迁移到共享的版本控制系统 34 任务分支模式 上下文有些开发任务需要很长时间才能实现 并且中间步骤对 活动开发线 有潜在的破坏 本模式描述如何调解长期任务和活动开发线问题你们小组如何能对码线进行多项 长期 重叠的变更 而不对它的一致性和完整性提出过高的要求 解决办法用分支进行隔离为每一项对码线有重大变更的活动开辟一条分支 重要的是经常把活动开发线的变更集成到任务分支 让任务分支与活动码线的集成尽可能平滑 35 版本线模式 上下文你正在 活动开发线 上开发 但是需要维护和增强已经发布的版本 并且要保持已发布的码基的稳定 本模式说明如何隔离已经发布的版本和当前的开发 问题如何在不影响当前开发工作的情况下 维护已经发布的版本 解决办法发布前分支在维护版本与活动开发分支在不同的码线上 把每个已经发布的版本保存在一条版本线上 使得版本线能独立发展 以便排除BUG 每条版本线都从主线上分支 36 版本预备线模式 上下文你即将完成一个版本 同时需要开始下一个版本的开发 你要维护 活动开发线 问题如何使码线稳定 以准备将要到来的发布 同时使新工作能继续在活动码线上进行 解决办法分支而不是冻结当代码接近版本质量时 就创建版本工程分支 在这条分支上完成发布 留出主线进行活动开发 这条分支变为版本分支 37 模式的总结和联系 要点何时以何种策略来隔离 分支 私用 汇总 合并 集成 和验证变更 使得码线能够满足开发的目的并且代价最小 38 议程 配置管理的发展和最佳经验配置管理模式版本构造和发布管理UCM和perforce的版本控制播控组的实践经验 董全武 部门配置管理规程和指南 39 版本构造 构建管理的最佳经验代码 工具 产品检入所有的源文件隔离构建时生成的对象使用通用的构建工具经常构建保留构建日志和输出结果 40 版本标识和发布版本的管理 命名规则既能反应版本演化又具有一定的可读性 关于标签的命名可以参考 数字媒体事业部配置管理补充指南 项目立项后就应该规划好各种用途的分支的命名规则 版本标识中包含分支的关键信息来反映版本的演化 这样以后发布的版本就很容易通过这种映射方式在存储库中找到重建的版本 41 版本发布管理的要求 发布过程是可重复的 可控制的 可跟踪的所有的源代码应该进行配置管理和标识必须提供描述发布过程 工件清单和变更情况的文档应该提供回滚的过程和步骤 以便在出现问题时能恢复发布的版本 42 发布流程 开发人员提交了发布清单的工作产品集成人员获取代码线最新的代码构建版本进行单元测试进行冒烟测试提交版本给测试组测试测试组认可后 完整地发布产品备案管理 形成分支或标签与发布产品的映射 43 议程 配置管理的发展和最佳经验配置管理模式版本构造和发布管理UCM和perforce的版本控制播控组的实践经验 董全武 部门配置管理规程和指南 44 UCM 统一变更管理简介 IBMRATIONAL的产品通过RationalClearCase和ClearQuest的实现是第三代配置管理系统以活动为中心提供推荐流程 也可以定制使用主线提升模型 通过基线提升 45 UCM在六个具体领域 开发人员在共享及公共代码工件上的隔离和协作 将一起开发 集成和发布的相关工件组按构件 component 进行组织 在项目里程碑创建构件基线 baseline 并根据所建立的质量标准来提升基线 将变更组织为变更集 changeset 将活动管理和工件管理集成在一起 按项目来组织软件开发并支持多项目之间的代码共享 开发人员的隔离和协作 46 Perforce简介 常用 简单而功能强大对分支和合并有突出支持使用主线模型支持任务级提交提供了基于数据库的查询报告内置的任务管理 提供集成接口 47 议程 配置管理的发展和最佳经验配置管理模式版本构造和发布管理UCM和perforce的版本控制播控组的实践经验 董全武 部门配置管理规程和指南 48 议程 配置管理的发展和最佳经验配置管理模式版本