25配置管理.ppt

时间戳VS校验和 时间戳 因为源文件和目标文件的名称联系在一起，而不是一个明确的源文件的签名。由于要生成相同名称的目标文件，通常是无法同时在同一目录下建立源代码组件的不同版本。 校验和 在时间戳的情况下，通常的做法是当你重新编译一个组件，它不会覆盖目标代码，相反，它会生成一个新的目标代码文件和源代码的签名标签。并行编译是可能的，并且不同版本的组件可以在同一时间被编译。 敏捷编译步骤 将主线系统从版本管理系统下载到开发者的私有工作空间。 构建系统并运行自动测试，以确保所构建系统通过了所有的测试。如果没有，构建终止。这时你应该通知最后提交主线系统的开发人员。他们负责修复这个问题。 完成系统组件的变更。 在私有工作空间构建系统并重新运行系统测试。如果测试失败，继续编辑。 敏捷编译 一旦系统已经通过了测试，将其检入到构建系统，但不作为一个新的系统基线提交。 在构建服务器上构建系统并运行测试。这样做是因为在检出系统后其他人有可能修改了组件。如果是这样的话，在您的私有工作空间，检出失败的组件并进行编辑，以便测试在私有工作空间通过。 如果系统在构建系统上通过测试，将做出的变更作为系统主线中的一个新的系统基线。 持续集成 版本管理 系统 私有 工作空间 检出主线 构建和 测试系统 做相应 变更 构建和 测试系统 构建和 测试系统 检入到构 建服务器 提交变更 到VM 构建服务器 版本管理 系统 持续集成 优点是它允许尽快发现并且修复由不同开发人员的交互引起的问题。主线中最近的系统是确定的工作系统。 虽然持续集成是一个好想法，但在系统构建中实现这个方法并不总是可行的。 如果系统很庞大，构建和测试可能要花费大量时间。这样不太可能每天构建系统几次。 如果开发平台和目标平台不相同，就不大可能在开发人员的私有工作空间运行系统测试。由于平台的差异性，也会需要更多的时间测试系统。 每日构建 对于大型系统或者执行平台和开发平台不相同的系统，持续集成可能不太实际，可以使用每日构建系统。其特征为： 开发组织设定系统组件的交货时间（例如下午2点）。如果开发人员有正在编写的组件的新版本，就必须到下午2点前提交。 通过编译和链接这些组件构建系统的新版本，形成一个完整的系统。 将系统交付给测试小组，执行一组预定义的系统测试。 记录系统测试过程中发现的问题，并返回到系统的开发者。他们在后续版本的组件中修复这些错误。 25.4 发布版本管理 系统的发布版本是分发给客户的软件系统。 对于大众市场的软件，通常可以定义两种类型的发布：一种是交付重要的新功能的主要发布；另一种是修复bug和修复客户报告的问题次要发布。 对于自定义的软件或软件产品线，该系统的发布可能要为每个客户和个人客户生产，可能运行几个不同的系统版本。 发布跟踪 存在问题的情况下，有必要准确再现已经被递送到特定客户的软件。 当一个系统发布产生时，它必须被记录，以确保它可以在恰当的未来被重新创建。 这对定制的，长寿命的嵌入式系统，如那些控制复杂机器的尤为重要。 客户可能多年使用这些系统的唯一发行版本，很长时间以后才提出对系统的变更需求。 发布复制 需要为发布版本编制文档，必须记录用来产生可执行代码的源代码组件的特定版本。 必须记录源代码文件、对应的可执行文件和所有的数据和配置文件的副本。 应该记录操作系统、库、编译器和用于构建软件等工具的版本。 发布规划 在准备发布版本的时候，除了必须准备的技术工作之外，还有广告、宣传材料以及营销策略必须到位，以说服客户购买系统的新版本。 发布时间 如果发布过于频繁，或者需要硬件升级，客户可能不会升级到新版本，尤其是当他们要为此付费的时候。 如果发布间隔时间较长，市场份额可能因为客户迁移到替代系统而丢失。 发布组件 系统的发布版本不仅仅是可执行代码，发布版本还可以包括： 配置文件，定义对于特定安装，发布版本应如何配置; 数据文件，如错误消息的文件，是成功进行系统操作所必需的; 安装程序，用于帮助在目标硬件上安装系统; 电子和纸质文档，用于描述系统; 包装和有关宣传。 影响系统发布的因素 Factor Description Technical quality of the system 系统的技术质量 If serious system faults are reported which affect the way in which many customers use the system, it may be necessary to issue a fault repair release. Minor system faults may be repaired by issuing patches (usually distributed over the Intern