软件项目管理第六章 软件配置管理.ppt

关注主线的演进 主线 1.0版 1.1版 1.2版 2.x 2.0版 2.1版 2.2版 3.x 3.0版 3.1版 3.2版 4.x 有问题的版本演化策略 关注主线的演进 该策略存在的问题： 分支层数太深，可能会超出版本控制工具的分支层数范围。 文件的版本演化历史信息复杂，分布在不同的分支中。 开发人员需要经常更换分支，容易出错。 关注主线的演进 主线 1.0版 2.0版 3.0版 2.x 2.1版 2.2版 1.x 1.1版 1.2版 3.x 3.1版 3.2版 更好的版本演化策略 7. 分支管理要点 分支不能随意创建，必须有所规划，适当管理。 分支管理要注意以下几点： 分支要有明确的目的。分支应有一个名字，简略说明分支的目的。 分支要规划好何时创建，从何处创建。 分支要规划好是否合并？合并到哪里？分支上所有的工作成果都要合并，还是有选择地合并？ 分支管理要点 分支要规划相关角色和权限：谁有权读取分支上的内容或向分支提交？分支的合并及分支上的集成工作由谁负责？谁负责创建、删除和重新命名分支？ 分支的规划要全盘考虑，看版本树的整体图景，而不要只关注手边的工作。 本章内容提要 软件配置管理的作用 软件配置管理的相关概念 建立软件配置管理环境 版本控制 系统集成 分支管理 变更管理 配置审计和配置状态报告 配置管理过程 软件配置管理工具 第七节 变更管理 对软件原有需求、设计等的改变叫做变更（change）。对变更必须进行有效的管理，避免其产生负面影响。 变更管理（控制）方法主要受以下因素影响：变更的规模、变更的影响面、变更发生的时间、开发过程模型、研发团队的规模。 1.变更规模对变更控制的影响 有些变更可以较快完成，且规模较小，比如缺陷的修复，对功能进行的少量增强。对于这类比较小的，数量又比较多的变更，可采用缺陷跟踪的方式来跟踪和管理。 有些变更需要不少的人力和时间，对项目的进度和预算都有影响，对这样的大型变更，就需要更严格的控制和企业高层的介入。 2.变更影响面对变更控制的影响 有些变更只会影响到产品的局部，而有些变更则可能会产生广泛的影响，例如公用函数库的变化。 对于有广泛影响的变更，必须有更为严格的控制，变更前要广泛征求意见，认真评估，变更后要通知大家，发生了什么改变。 多层集成 使用多层集成的情况： 多个人合作完成一个任务，需要互相高度配合，而该任务作为一个整体，与其它任务关联不大，此时应考虑使用多层集成。 研发团队分成了若干研发小组，每个小组负责完成一组任务，此时可以考虑在每个组内做第一层集成，然后再做组间的总的集成。 6.保证构建的可重复性 构建(Build)就是从源代码生产出安装包的过程。包括： 编译 链接：生成可执行程序 打包：把所有对用户有用的东西打成一个安装包 构建有时可能不包括打包，比如程序员编译和链接程序后用于测试，此时构建过程就只包括编译和链接。 保证构建的可重复性 构建可能会遇到的问题： 产品的某个版本，在源代码没有改变的情况下，这次构建后产品没问题，下次构建出现了Bug。 产品的某个版本，一个人构建后产品没有问题，另一个人构建后却出现了问题。 产品的某个版本，现在构建没有问题，一段时间（也许是几年或者更长）后再构建却出现了问题。 构建结果的不可预测会给软件开发和维护带来困扰！ 保证构建的可重复性 保证构建的可重复性就是指保证每次构建一个具体的产品版本，得到的结果是相同的。 为了达到这一要求，需要保证： 构建的输入（所有源代码、文档、数据等）是固定和明确的。 构建的工具和环境是固定和明确的。包括特定品牌和版本的编译器、打包工具、操作系统，以及硬件配置。 保证构建的可重复性 参数设置是固定和明确的。包括编译、链接和打包的命令参数，工具和环境的配置参数（例如操作系统的环境变量）。 构建过程是固定和明确的。比如Ant文件、相关的脚本；操作的执行顺序等。 保证构建的可重复性 为了做到以上几点，通常有以下策略： 自动化：尽可能将构建过程自动化，减小出差错的可能性。例如使用构建工具来执行脚本。 文档化：详细记录构建过程、构建环境等信息，使任何人都可根据这个记录文档来正确执行构建过程，得到正确结果。 与源代码的版本绑定：将构建工具、配置参数、执行脚本、说明文档等与源代码一起放到配置库中。一旦导出了特定版本的源代码，也就同时导出了对应该版本的所有这些内容。 7.加快构建速度 全量构建：完全重新编译源代码，继而链接、打包，不利用上次构建所生成的中间结果。 增量构建：尽可能地利用上次构建的成果，只重新编译那些发生了改变（和受改变影响）的源代码。特点：速度更快，但不如全量构建可靠。 加快构建速度 原则： 在追求构建速度的时候，倾向于使用增量构建，例如程序员自己构建的时候。 在强调构建的可