[整理版]若何有效地前进版本操纵和治理课件.ppt

1、1如何有效地进行版本控制和管理如何有效地进行版本控制和管理2议程议程l配置管理的发展和最佳经验l配置管理模式l版本构造和发布管理lUCM和perforce的版本控制l播控组的实践经验（董全武）l部门配置管理规程和指南3软件开发的混沌软件开发的混沌l版本较多，不知道如何选择一个合适的版本进行下一步的工作？l你的团队经常得不到一个可以工作的版本而苦不堪言？l有多个版本而不能很好的整合？l用户出现问题，而你却无法获取和重构用户版本？l变更无法追踪，无法有效的追溯版本的变化？l你经常处在无法说清楚项目的真实状态l45作业作业l你们项目组版本控制和管理存在什么问题，原因是什么，使用本培训的方法如何改进？

2、l要求 至少提出2个问题，说明其原因 改进方法应该明确并有可操作性 周五前提交到li_6如何避免如何避免l对症下药l配置管理l变更管理l项目管理l对于开发者，最切实可行的就是版本控制和管理7第一代配置管理第一代配置管理l时间 七十年代开始l特征 基于文件（File Based）的版本控制 支持check-out/check-in模型 简单分支l解决问题 文件丢失和覆盖的问题8最佳经验最佳经验l标识工件,将工件存入安全的版本库l控制并记录对工件的变更l保持稳定，一致的工作空间9第二代配置管理第二代配置管理l时间 八十年代中后期l特征 基于项目库将元数据与配置项分开存储管理 从而更好地支持并行开发

3、、团队协作以及过程管理l解决问题 并行开发10最佳实践最佳实践l支持工件的并行开发l及早集成，经常集成l记录并追踪变更跟请求l保证软件build可重现11第三代配置管理第三代配置管理l时间 2000年l特征 以活动为中心的组织和集成l解决问题 如何在复杂的软件开发中把握变更12最佳实践最佳实践l将工件组织成版本化的构件 “构件的引入”有利于逻辑设计和物理实现相对应 提供一种机制来更智能的创建和使用基线构件是对众多的文件进行合理分类以呈现系统的设计要素可以大大简化项目开发控制，可以通过合理的目录来组织构件l以活动为中心的组织和集成 建立活动变更集的映射l在项目里程碑处创建基线 更好的标识阶段点和

4、提供开发复用的基准13定义开发流程定义开发流程l确定代码线策略、集成规约和质量标准l获取工作列表l选择工作的代码线和获取一个可信版本l在工作区完成单个任务，测试符合代码线策略后提交，反复执行l集成人员根据集成规约进行集成，根据质量标准打标签，提交测试，符合质量后标识基线，通知相关人员更新代码14议程议程l配置管理的发展和最佳经验l配置管理模式l版本构造和发布管理lUCM和perforce的版本控制l播控组的实践经验（董全武）l部门配置管理规程和指南15什么是模式？什么是模式？l描述在我们环境中反复出现的问题，然后给出该问题的核心解决办法，以这样的方式，你可以上百万次地使用这种解决方法，而不会有

5、两次一样，它描述了为了解决问题而定义的存在而不得不做的事情的规则。16如何理解和使用模式如何理解和使用模式l上下文 何时应该考虑使用该模式l问题 说明该模式要解决的问题l解决办法注意：模式如何互相关联与模式所解决的问题和解决问题的方法同样重要 17模式纵览模式纵览l与工作区相关的模式 存储库 私用工作区 第三方码线 任务级提交 私用系统构造 集成构造 单元测试 冒烟测试 回归测试l与码线相关的模式 码线策略 主线 活动开发线 私用版本 任务分支 版本线 版本预备线18存储库模式存储库模式l上下文 为了创建私用工作区或者运行可靠的集成构造，你需要正确的组件。本模式介绍如何用必要的部件轻松的构造工

6、作区。l问题 如何获得填充新工作区的正确组件的正确版本？l解决办法 一站式购物 从单一访问点获取你的代码和有关人工制品。使创建开发者工作区尽可能的简单与透明19私用工作区模式私用工作区模式l上下文 你要确保正在跟最新的代码打交道，但是因为人们不能妥善的处理不可控制的变更，所以你要能控制何时开始跟其他开发者变更打交道。本模式描述如何调解总是使用当前码基进行开发的理想与当环境不停的变化时人们不能有效的工作的现实之间的紧张状态。l问题 如何跟上不断变化的码线并取得进展，而不会为你们自己造成的环境变化分心？l解决办法 以隔离工作的方法控制变更 在私用工作区工作，在那里控制你正在做的代码和组件的版本。你

7、可以完全控制你的环境何时以及如何变更20第三方代码线模式第三方代码线模式l上下文 你的系统需要和外部组件相联系。本模式介绍如何跟踪自己的代码的方式，来跟踪第三方的组件l问题 什么是协调供应商代码的版本与产品代码的版本的最有效的战略？l解决办法 为第三方代码创建码线。用这条码线构造工作区和安装工具。21任务级的提交模式任务级的提交模式l上下文 如果知道哪些东西或变更参加了集成，集成构造时就比较容易排错。本模式讨论如何平衡对稳定性、速度和原子性的需要。l问题 在两次向版本控制系统提交之间，你应该做多少工作？检入文件之前，你应该等多长时间？l解决办法 每一项小粒度任务做一次提交 每一项小粒度的、一致

8、的任务做一次提交。22私用系统构造模式私用系统构造模式l上下文 私用工作区使得变更和其他外部变化隔离起来，但是你的变更又需要和系统其余部分打交道，为了验证这一变更，你需要以一致的方式构造系统，本模式说明如何在提交变更时检验你的变更是否与最新公布的码基一致。l问题 如何在检入你的变更前检验它们不损坏构造或者系统？l解决办法 通过本地构造实现全局考虑 提交给源码控制之前，用私用系统构造来构造系统23集成构造模式集成构造模式l上下文 各个开发在单独的私用区间变更，这些变更必须集成在一起，并且整个系统必须可靠的构造。本模式讨论有助于确保系统的代码总能构造的机制l问题 如何确保码基总能可靠地构造？l解决

9、办法 进行集中式构造 要确保用中央集成构造所有的变更以及其依存关系，这个构造过程应该是可重生的，尽可能接近最终的产品构造，自动化的或只是需要最少的人工干预，有识别错误与不一致的通知或日志机制。在你的版本控制系统中用标号标识这次构造。24冒烟测试模式冒烟测试模式l上下文l即使代码能够构造，仍需要检验以后可能使你出故障的运行问题。本模式讨论为了确认构造 有效性而需要的决策。l问题 如何知道系统在你变更后仍能工作？l解决办法 验证基本功能 每次构造都必须进行冒烟测试，以显而易见的方式验证应用未被损坏。25单元测试模式单元测试模式l上下文 在你做模块尤其是编写新代码时，冒烟测试对详细的测试变更是不够的

10、。本模式向你介绍如 何测试详细的变更，使得你能确保码线的质量。l问题 如何测试模块经你变更后是否仍能像预期那样工作。l解决办法 测试合同 开发及运行单元测试。26回归测试模式回归测试模式l上下文 冒烟测试不详尽，单元测试局部化，如果要确定准备发布的版本，就需要确保码基是健壮的。本模式说明如何生成不比上次更差的构造。l问题 如何确保现有的代码没有因你进行其他改进而变得更糟？l解决办法 对修改进行测试 每当要确保码线的稳定性时，就对系统运行回归测试。用过去使得系统出故障的测试用例创建回归测试。回归测试是黑箱测试，包括过去出现过的和预先考虑到的各种失效模式。27码线策略模式码线策略模式l上下文 当有

11、多条码线时，开发者需要知道如何对待它们。本模式描述如何为每条码线制定与其用途相符的规则。l问题 开发者如何知道他们的代码应检入哪条码线，何时检入以及检入前要运行哪些测试？l解决办法 制定交通规则 为各分支或码线正式规定策略，确定开发者应如何以及何时进行变更。策略应简明并可以审计。28码线策略的依据码线策略的依据l策略的制定是根据码线的用途决定的。一旦决定了码线需要稳定到何种程度以及如何通过过程达到这种稳定性，就需要把这些策略通知开发者，并实施这些策略。29策略应包括策略应包括l码线封装的工作类型，如开发，维护或具体的版本、功能、子系统l各元素应该如何以及何时检入、检出、分支与合并l对各人、各种

12、角色和各组的访问限制l导入/导出关系：期望接收变更以及需要传送变更的码线的名字l码线工作期限或退休的条件l预期的活动负荷以及集成频率30策略的例子策略的例子l开发线 可以检入临时的代码变更；受影响的组件必须是可构造的l版本线 软件必须能构造并通过回归测试才能检入。检入后的软件对排错是有限制的；不能检入新特征和新功能；检入后，分支冻结，直到整个质量保证周期结束。l主线 所有的组件都必须编译和链接，并通过回归测试；完整的、经过测试的新特征可以检入。31主线模式主线模式l上下文 在软件开发中，往往不得不调解并行的开发工作。版本控制工具提供分支与合并的设施。可以使用分支隔离并行工作，但是可能有代价。本

13、模式使得分支与合并所要求的集成工作减少到最少。l问题 如何使得当前活动码线的数目保持在容易管理的水平，避免项目的版本长得太宽太密？如何使得合并得开销减少到最小？l解决办法 简化分支模型 开发单个产品版本时，在主线上进行开发。主线是主码线，除了特殊情况之外，全部开发工作都在主线上进行。分支时，先考虑总体战略，然后再创建分支。拿不准时，尽量采用简单的模型。32活动开发线模式活动开发线模式l上下文 当你在动态的开发环境工作时，许多人都在变更代码，小组成员都在为了使系统更好而工作，但任何变更都可能损坏系统，而且这些变更可能互相冲突。本模式帮助你在活动开发工作中，在稳定性和进展之间取得平衡。l问题 如何

14、使得快速发展的码线足够稳定，可以使用？l解决办法 定义你的目标 制定有效的码线策略，使得主开发线足够稳定，能够满足工作需要，不要追求完整的活动开发线，而是力争主线足够有用与活动，能满足你的需要。33私用版本模式私用版本模式l上下文 你要在维持“活动开发线”的同时迅速评价可能损坏系统的复杂变更。本模式描述如何在不会无意的影响全局历史的情况下维持本地的跟踪能力。l问题 如何进行复杂的变更的实验，如何利用版本控制系统使这样的变更不会公开？l解决办法 私用历史 给开发者提供一种机制，让他们能以他们感到舒适的粒度，为变更设置检查点。这可以通过本地版本控制区提供。只是把稳定的代码集合检入项目存储池。重要的

15、是，确保使用私用版本的开发者记者按合理的时间间隔把变更迁移到共享的版本控制系统。34任务分支模式任务分支模式l上下文 有些开发任务需要很长时间才能实现，并且中间步骤对“活动开发线”有潜在的破坏。本模式描述如何调解长期任务和活动开发线l问题 你们小组如何能对码线进行多项、长期、重叠的变更，而不对它的一致性和完整性提出过高的要求。l解决办法 用分支进行隔离 为每一项对码线有重大变更的活动开辟一条分支。重要的是经常把活动开发线的变更集成到任务分支，让任务分支与活动码线的集成尽可能平滑。35版本线模式版本线模式l上下文 你正在“活动开发线”上开发，但是需要维护和增强已经发布的版本，并且要保持已发布的码

16、基的稳定。本模式说明如何隔离已经发布的版本和当前的开发。l问题 如何在不影响当前开发工作的情况下，维护已经发布的版本？l解决办法 发布前分支 在维护版本与活动开发分支在不同的码线上，把每个已经发布的版本保存在一条版本线上。使得版本线能独立发展，以便排除BUG。每条版本线都从主线上分支。36版本预备线模式版本预备线模式l上下文 你即将完成一个版本，同时需要开始下一个版本的开发，你要维护“活动开发线”。l问题 如何使码线稳定，以准备将要到来的发布，同时使新工作能继续在活动码线上进行？l解决办法 分支而不是冻结 当代码接近版本质量时，就创建版本工程分支，在这条分支上完成发布，留出主线进行活动开发，这

17、条分支变为版本分支。37模式的总结和联系模式的总结和联系l要点 何时以何种策略来隔离（分支，私用）、汇总（合并，集成）和验证变更，使得码线能够满足开发的目的并且代价最小。38议程议程l配置管理的发展和最佳经验l配置管理模式l版本构造和发布管理lUCM和perforce的版本控制l播控组的实践经验（董全武）l部门配置管理规程和指南39版本构造版本构造构建管理的最佳经验l 代码工具 产品l 检入所有的源文件l 隔离构建时生成的对象l 使用通用的构建工具l 经常构建l 保留构建日志和输出结果40版本标识和发布版本的管理版本标识和发布版本的管理l命名规则 既能反应版本演化又具有一定的可读性。关于标签的

18、命名可以参考数字媒体事业部配置管理补充指南。项目立项后就应该规划好各种用途的分支的命名规则，版本标识中包含分支的关键信息来反映版本的演化，这样以后发布的版本就很容易通过这种映射方式在存储库中找到重建的版本。41版本发布管理的要求版本发布管理的要求l 发布过程是可重复的，可控制的，可跟踪的l 所有的源代码应该进行配置管理和标识l 必须提供描述发布过程，工件清单和变更情况的文档l应该提供回滚的过程和步骤，以便在出现问题时能恢复发布的版本42发布流程发布流程l开发人员提交了发布清单的工作产品l集成人员获取代码线最新的代码l构建版本l进行单元测试l进行冒烟测试l提交版本给测试组测试l测试组认可后，完整

19、地发布产品l备案管理，形成分支或标签与发布产品的映射43议程议程l配置管理的发展和最佳经验l配置管理模式l版本构造和发布管理lUCM和perforce的版本控制l播控组的实践经验（董全武）l部门配置管理规程和指南44UCM：统一变更管理简介：统一变更管理简介lIBM RATIONAL 的产品 通过Rational ClearCase和ClearQuest的实现l是第三代配置管理系统l以活动为中心l提供推荐流程，也可以定制l使用主线提升模型，通过基线提升45UCM在六个具体领域在六个具体领域l开发人员在共享及公共代码工件上的隔离和协作；l将一起开发、集成和发布的相关工件组按构件（componen

20、t）进行组织；l在项目里程碑创建构件基线（baseline）并根据所建立的质量标准来提升基线；l将变更组织为变更集（change set）；l将活动管理和工件管理集成在一起；l按项目来组织软件开发并支持多项目之间的代码共享；l开发人员的隔离和协作 46Perforce 简介简介l常用，简单而功能强大l对分支和合并有突出支持l使用主线模型l支持任务级提交l提供了基于数据库的查询报告l内置的任务管理，提供集成接口47议程议程l配置管理的发展和最佳经验l配置管理模式l版本构造和发布管理lUCM和perforce的版本控制l播控组的实践经验（董全武）l部门配置管理规程和指南48议程议程l配置管理的发展

21、和最佳经验l配置管理模式l版本构造和发布管理lUCM和perforce的版本控制l播控组的实践经验（董全武）l部门配置管理规程和指南49部门配置管理规程和指南部门配置管理规程和指南l是经开发经理和配置管理员讨论认可l位置http:/sepgsrv/sites/SHM/DocLib1/Forms/AllItems.aspxl提供配置计划模版 各个项目组或者各个具体项目必须认真填写 以后由项目管理组根据计划审计50参考资料参考资料l软件配置管理模式，黄明成，电力出版社l第三代软件配置管理方案，微软2004年会课件l软件外包发布管理，IBM2004开发者大会课间lperforce配置管理最佳经验、软件生命l数字媒体事业部配置管理规程和指南51