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