搜索
软件配置管理——康子烨软件配置管理基本的版本控制系统集成构建管理分支变体三库管理的概念什么是软件配置管理软件配置管理的一些比喻缺乏管理所造成的问题什么是软件配置管理一套应用技术上和管理上的指导和监督方法，用来：识别和记录配置项的功能特征和物理特征；控制这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其是否特定的需求。——一个权威定义（被CMM、CMMI引用）软件配置管理的一些比喻图书管理（在一借一还的过程中都需要记录）保险柜（软件资产可能丢失、被窃取和泄露，特别是源代码）岩钉（适当保存历史版本，所有的一切软件资产都可以保存）缺乏管理所造成的问题软件开发人员之间缺乏必要的交流产品升级和维护所必需的程序和文档非常混乱开发过程中的人员流动经常发生因管理不善致使未经测试的软件加入到产品中项目开发状态不清楚软件生产达不到规模化软件配置管理基本的版本控制系统集成构建管理分支变体三库管理的概念基本的版本控制基线版本管理，主要是建立一个公共存储区，记录版本，防止版本覆盖，防止版本混乱。版本管理是配置管理里重要的一项环节。在软件开发中会遇到一些非常棘手的问题，比如，需要将整个软件版本恢复到以前的某一时间的状态；控制某个程序在同一时间只能被一个程序员修改等等。这时就需要使用版本控制软件进行管理了。版本控制软件可以将某一程序恢复到以前的某一时间的状态，甚至将整个软件版本恢复到以前的某一时间的状态。也能够实现某一程序在同一时间只能一个开发人员修改，还可以配制成允许多人修改，最后将不同版本合并为新版本。基本的版本控制假设每个程序员负责一个专门模块，不存在两个程序员修改同一处源代码的问题。在修改程序之前，从哪里拿到最新版本？（程序员可能基于过时的程序开始自己的工作）在修改程序之后，把修改结果提交到那？（程序员的工作可能被湮没）解决之道将源代码流转的渠道从网状结构（图1）改成星星结构（图2），也就是设立一个公共储区，作为参照物和枢纽，大家统一从这个公共点取代码，的轩昂程序改完后，都把自己改的那部分全部传到公共存储区，别人再从那里取用。图1图2假设两个程序员同时修改同一源代码，会出现程序覆盖问题。（即后提交的代码B会把先提交的代码A覆盖）监控。阻止同时修改的事情发生。串行方法辅助。使同时修改的内容合并到一起。并行方法串行方法并行方法版本控制软件还可以对程序修改进行有效的管理，将开发环境、测试环境、运行环境进行有效的隔离。我们还可以在版本控制软件中存放软件开发过程中成成的各种文档，以供随时查阅。如何表达版本的质量状态在版本号中，添加状态标记（常用方法）。有两个弱点：1.在版本库中，标签不一定能重新命名。2.改变标签名称，以及改变安装包的名称，可能会引起混乱。版本本身可以自带些属性。当质量状态提升时，不必改版本名称，只需改版本的质量状态属性。用不同的目录，来区分不同质量状态下源代码的整体版本或安装包。基线是有质量状态的。当探测到源代码质量状态到达了更新程度的时候，做一个基线提升。基线被明显的标记和记录下来的源代码整体版本。（即整体复制）在每个文件的特定版本上打标签来完成。基线的权限——只读软件配置管理基本的版本控制系统集成构建管理分支变体三库管理的概念什么是系统集成系统集成的步骤系统集成系统集成，简称集成，是基本的使命就是把产品的各个部分捏在一起，并保证产品作为整体是可以运转的，而不仅是每个模块，每个单元能在特定的开发调试环境、特定的数据和参数下运转。视角1：集成的，不是模块，而是工作。每个任务单元可能在一个模块上修改，也可能涉及多个模块。视角2：不再把产品的各个模块合到一起，而是把产品的改变合到一起，和在已有的版本上，产生新的版本，所集成的是任何单元，是变更。+=新的整体版本源代码整体版本多个任务单元集成的含义多层集成集成的步骤确保开发人员都提交了相关的源代码。冻结或者标识将要集成的源代码。（比如：禁止开发人员向版本库的提交）取出要集成的源代码。（最好放在一个全新的工作空间）编译、链接和打安装包。（通常称为构建）安装并粗略测试。表示和储备集成成果。（集成结果有两个：1.源代码的整体版本2.生成安装包）通知相关人员本次集成完成。（还应告知集成成员的名称和存储内容）如有问题，修改了源代码，就从头再来。软件配置管理基本的版本控制系统集成构建管理分支变体三库管理的概念什么是构建管理构建管理分为两部分保证构建的可重复性如何让构建更快安装包有没有必要保存安装包如何保存构建管理构建：从源代码生产出安装包的过程。一般包括：编译源代码；链接编译结果；产生可以运行的程序；把所有对客户有用的东西都打包。构建的输入，是产品的全部源文件，可能还有文档、数据等。构建的输出，通常是安装包。是从每一个源文件的编译开始，不借助于以往构建中留下的已有的或许可以重复使用的结果。（通常系统集成，集成工程师所做的构建是全量构建)是尽可能的利用上次构建的成果。（这是一个省时间偷懒的方法）构建分为全量构建增量构建正确、准确快速保证构建的可重复性原材料是固定明确的工具是固定明确的参数设置是固定明确的生产过程是固定明确的（或是尽可能的文档化构建过程）如何让构建更快自动化提高硬件性能提高专一性（尽量减少在同一台服务器上同时运行的构建任务单元的数量）把构建任务分解，并行完成（要实现分布式构建，其软件实现难度则大了很多，可能需要一些高端软件的支持）安装包有没有必要保存？通常是必要的，因为这样可以在需要它的时候能够迅速准确的得到这个安装包。如果将它删除，在将来需要它的时候，还要找历史上的源代码，现从源代码开始编译、打包，那么会耗费时间。安装包如何保存？放进版本库不是明智之举。对于安装包，很多历史版本，比如送去测试用的安装包，需要定期清理，否则会占用大量的磁盘空间。安装包可以保存在共享目录下，该目录可以在局域网共享，除此之外，还要考虑适当的备份。软件配置管理基本的版本控制系统集成构建管理分支变体三库管理的概念什么是分支分支与工作空间的对比流集中精力于主线的演进分支管理要注意的事项分支主线又被称为主干，是一种特殊的分支。合并是某种复制行为，不是复制版本本身，而是复制版本之间的差异。合并不会影响原分支的。分支与工作空间的对比分支可同时容纳多个已提交的任务单元，并以此和其他分之区别。分支存储在服务器上比工作空间存储在本地安全。分支是所有人都能看到，若有必要，所有人都能在上边工作；工作空间是单个开发人员自己的地盘，只有自己才能在上面工作。分支不能改变其起始点，工作空间可以改变弱势：优势：兼具分支和工作空间的优势流流的三种含义流是起始点可改变的产品级的“分支”。流的起始点可以设置为产品的某个整体版本。流可以设置为另外的某个流的末端。分支不能长期存在，把分支缩短，在每一次组内集成，就合并到主线，并关闭该分支，重新建立新的分支，来吸收下一次组内集成的内容。主线始终是开发的主流。A主线B长期隔离导致集成困难主线A—3B—3A—1B—1B—2A—2短分支经常集成为特定用户，进行单独立项，进行特定开发的解决方法。改变版本结构，要集中精力在主线演进，集中精力开发一个产品，从主线出发，有每个分支上，主要关注用户的特殊需求。主线鲢鲈鲑魭鲤鳗鲂鲐鲟鲫鳝鲆1.0版3.0版2.0版主线产鱼法鱼的裂变魭鲐鲂鲆鳝鳗鲫鲤鲟鲑鲈鲢分支管理要注意的事项每条分支的目的和用途，必须明确，并且分支要有合适的名字。分支要规划确定相关角色和权限，要注意全盘考虑，看版本树的整体图景。软件配置管理基本的版本控制系统集成构建管理分支变体三库管理的概念什么是变体产生变体的原因用分支支持变体支持分支的多种方法（组件复用）避免变体的方法减少变体的成本变体变体是指一些软件产品，他们彼此有些相同之处，但彼此有有所区别。产生变体的原因：因支持不同操作系统而产生的变体。因客户制定而成的变体。因不同的功能集而产生变体。用分支支持变体假定，基于标准版1.0版，开发1.0—A版。这是为客户A专门制定的一个版本，里边增加了了一个只有客户A才需要的功能：点石成金。假定，在推出标准版2.0版后，客户A请求将1.0—A版升级到2.0—A版。既保留点石成金功能的同时，去掉1.0版里发现的缺陷，添上2.0标准版里新增加的功能。这时候怎么处理？主线1.0—A1.0版1.0—A版变体（简单情况）用分支支持变体把主线上所有的修改都复制到分支上，集成测试，并作适当调整，确保不影响分支上的特殊功能。弱势:可能引入的代码修改太多，很难做到这一点。主线A1.0版2.0版1.0—A版2.0—A版提升变体版本（方法一）用分支支持变体不把主线上的内容合并到分支上，而是创建新的分支，把原有分支上的内容复制过来。（对于分支合并引入的代码修改进行浏览和审查就会容易得多。）弱势：如果需要频繁的拿到标准版最新版本里的内容，那么需要建很多分支。如果变体与标准版的差距较大，对应的源代码修改也很大。主线1.0版2.0版提升变体版本（方法二）1.0—A1.0—A版2.0—A2.0—A版支持分支的多种方法完全独立开发可以有效的保证遍体之间的隔离，但是无法支持变体之间的共享。常用的改进方法：从某一点开始，独立出来，从此分道扬镳。在这一点之前，所积累的软件资产，就变成变体之间共享了。但随后的改动，只能通过手工的方法，在不同的变体或变体与主流间传播。支持分支的多种方法使用分支能有效的实现隔离，也实现共享。弱势：分支是有管理成本的。如果变体所在的分支上，包含了一些应该共享的改动，那么应合并到主干上。这样的话，相应管理成本也会提高。支持分支的多种方法使用文件属性在一定程度上实现了隔离，但并不完全。在降低共享的成本同时，削弱了隔离。共享又不总是能够自动传播。需要手动修改其他变体的相关文件，才能实现这个功能改动。支持分支的多种方法使用不同的Makefile与使用文件属性一样，在一定程度上实现隔离，共享又不总是能够自动传播。比使用文件属性好的地方是，程序员能够同时看到不同变体所需的源文件。（要注意对Makefile本身的维护）支持分支的多种方法使用宏定义宏和Makefile的方法差不多，都是有选择的选择源代码进行编译，不同的是：Makefile只能区分到文件夹；宏可以区分到源文件。弱点：宏是写在源代码里，遍体多的话，结构就会复杂，难以维护。并非所有编程语言都支持宏。支持分支的多种方法组件复用把系统分解为组件，系统由不同的组件构成，每个组件，可能多次参与不同系统的构成。组件有三种：源代码组件、运行组件、库组件。组件复用引用组件复用后，软件配置管理还要额外关注的事情。加强对公共组件的变更管理。为公共组件的开发提供环境支持。共享多个系统中对公共组件的修改。应对多个系统的系统总体集成中的问题。避免变体的方法聪明的拒接个别客户提出的要求。在标准版本里，实现客户的要求。安装软件时，特定用户只安装特定的组件。通过软件运行时的配置、设置，实现不同外观和功能等。减少变体的成本对变体仅提供有限的支持服务，特别是支持服务。减少变体与标准版本之间的差异。软件配置管理基本的版本控制系统集成构建管理分支变体三库管理的概念开发库受控库静态库开发库管理的概念开发库可以大致反映为开发工程师的个人工作空间，在开发工程师本机上，个人目录下。当然，对于稍大的任务，也可以映射为存储库里的一个任务分支。受控库管理的概念受控库则是开发工程师相互协作、交流最新工作成果的地方。大致上，可以映射为版本控制工具的存储库。这里，可能有不同的分支/目录做不同的用途，可能会打标签、基线。静态库管理的概念静态库，有称基线库，是指那些重要的基线，这些基线标志着项目的重要里程碑，或者这些基线被发布给了“外界”。在比较简单的版本控制工具里，一般可以用特定标签命名