投产服务与软件产品的部署有关,是对项目服务特性的要求。运营企业中可能同时有多个应用系统,相互之间往往具有很高的耦合度,一项新业务的推出,往往需要多个软件产品配合修改和同步投产。因此,从业务角度来说,一个新的业务产品的实现,需要多个软件模块(产品)的支持,不同投产单位中这些软件模块(产品)的版本配合关系不同。那么对于运行中心来说,需要面临同时满足业务产品和软件产品的双重要求,既要保证业务产品的完整性和多样性,又要保证软件产品的一致性和兼容性。因此,对于投产管理来说,也有同样的配置管理的要求,是必须在企业级来考虑的。
配置管理中的版本管理和变更管理
配置管理中要记录、控制、报告各种属性(配置项)的变化状态,这就是配置管理中的版本管理和变更管理,有变更才有不同的版本,版本又成为变更控制的主要对象,这两者是紧密关联的。
首先要澄清一下版本的概念。在配置管理中,每个配置项的每个状态都可以称为一个版本,配置项的演变过程就可以体现为一棵版本树。而我们平时经常说的版本,实际是指软件产品的版本,不是具体配置项的版本。一个软件产品版本是由众多配置项组成的,每个配置项最多只能选取它的一个版本组成一个特定的产品版本。因此,在我们平时谈到“版本”时,需要明确是配置项的版本还是软件产品的版本,否则容易在沟通中带来混淆。既然版本管理是配置管理中的一项内容,那么对于在软件产品版本管理中遇到的各种实际问题,就需要放在配置管理这个大背景中,基于配置管理的理论、方法和工具来考虑,才能逐步理清。
项目中的变更管理是大家都已经很熟悉的工作,从概念上来说,变更管理也属于配置管理工作的一部分。在软件开发项目中,无论是功能需求的变更、技术需求的变更还是服务需求的变更,也都可以将变更要求与配置项建立对应关系,演变成为配置项的变更,配置项在变更前后形成不同的版本,这样就使得变更管理能够有的放矢。如果不能将变更要求落实到具体的配置项上,项目中许多的变更控制就难以具体落实。
具体来说,在每一项开发任务中,都需要首先设定开发基线,确定各个配置项的开发初始版本,在开发过程中,开发人员基于开发基线的版本,开发出所需的目标版本。当发生需求变更时,通过对变更的评估,确定变更的影响范围,对被影响的配置项的版本进行修改,根据变更的性质使配置项的版本树继续延伸或产生新的分支,形成新的目标版本,而对于不受变更影响的配置项则不应发生变动。同时,应能够将变更所产生的对版本的影响进行记录和跟踪,必要时还可以回退到以前的版本,例如当开发需求或需求变更被取消时,就需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中,其实就是将部分配置项的版本回退到开发基线,将对应不同需求的不同分支重新组合归并,形成新的升级包版本。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/