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

49 如何有效地进行版本控制和管理 议程 配置管理的发展和最佳经验 配置管理模式 版本构造和发布管理 UCM和perforce的版本控制 播控组的实践经验（董全武） 部门配置管理规程和指南 软件开发的混沌 版本较多，不知道如何选择一个合适的版本进行下一步的工作？ 你的团队经常得不到一个可以工作的版本而苦不堪言？ 有多个版本而不能很好的整合？ 用户出现问题，而你却无法获取和重构用户版本？ 变更无法追踪，无法有效的追溯版本的变化？ 你经常处在无法说清楚项目的真实状态 … 作业 你们项目组版本控制和管理存在什么问题，原因是什么，使用本培训的方法如何改进？ 要求 至少提出2个问题，说明其原因 改进方法应该明确并有可操作性 周五前提交到li_chunhua@ 如何避免 对症下药 配置管理 变更管理 项目管理 … 对于开发者，最切实可行的就是版本控制和管理 第一代配置管理 时间 七十年代开始 特征 基于文件（File Based）的版本控制 支持check-out/check-in模型 简单分支 解决问题 文件丢失和覆盖的问题 最佳经验 标识工件,将工件存入安全的版本库 控制并记录对工件的变更 保持稳定，一致的工作空间 第二代配置管理 时间 八十年代中后期 特征 基于项目库将元数据与配置项分开存储管理 从而更好地支持并行开发、团队协作以及过程管理 解决问题 并行开发 最佳实践 支持工件的并行开发 及早集成，经常集成 记录并追踪变更跟请求 保证软件build可重现 第三代配置管理 时间 2000年 特征 以活动为中心的组织和集成 解决问题 如何在复杂的软件开发中把握变更 最佳实践 将工件组织成版本化的构件 “构件的引入”——有利于逻辑设计和物理实现相对应 ——提供一种机制来更智能的创建和使用基线 构件是对众多的文件进行合理分类以呈现系统的设计要素可以大大简化项目开发控制，可以通过合理的目录来组织构件 以活动为中心的组织和集成 建立活动——变更集的映射 在项目里程碑处创建基线 更好的标识阶段点和提供开发复用的基准 定义开发流程 确定代码线策略、集成规约和质量标准 获取工作列表 选择工作的代码线和获取一个可信版本 在工作区完成单个任务，测试符合代码线策略后提交，反复执行 集成人员根据集成规约进行集成，根据质量标准打标签，提交测试，符合质量后标识基线，通知相关人员更新代码 议程 配置管理的发展和最佳经验 配置管理模式 版本构造和发布管理 UCM和perforce的版本控制 播控组的实践经验（董全武） 部门配置管理规程和指南 什么是模式？ 描述在我们环境中反复出现的问题，然后给出该问题的核心解决办法，以这样的方式，你可以上百万次地使用这种解决方法，而不会有两次一样，它描述了为了解决问题而定义的存在而不得不做的事情的规则。 如何理解和使用模式 上下文 何时应该考虑使用该模式 问题 说明该模式要解决的问题 解决办法 注意：模式如何互相关联与模式所解决的问题和解决问题的方法同样重要 模式纵览 与工作区相关的模式 存储库 私用工作区 第三方码线 任务级提交 私用系统构造 集成构造 单元测试 冒烟测试 回归测试 与码线相关的模式 码线策略 主线 活动开发线 私用版本 任务分支 版本线 版本预备线 存储库模式 上下文 为了创建私用工作区或者运行可靠的集成构造，你需要正确的组件。本模式介绍如何用必要的部件轻松的构造工作区。 问题 如何获得填充新工作区的正确组件的正确版本？ 解决办法 一站式购物 从单一访问点获取你的代码和有关人工制品。使创建开发者工作区尽可能的简单与透明 私用工作区模式 上下文 你要确保正在跟最新的代码打交道，但是因为人们不能妥善的处理不可控制的变更，所以你要能控制何时开始跟其他开发者变更打交道。本模式描述如何调解总是使用当前码基进行开发的理想与当环境不停的变化时人们不能有效的工作的现实之间的紧张状态。 问题 如何跟上不断变化的码线并取得进展，而不会为你们自己造成的环境变化分心？ 解决办法 以隔离工作的方法控制变更 在私用工作区工作，在那里控