基于DevOps的软件配置项管理

屠趁锋

摘 要：文章简述了DevOps概念，基于DevOps的配置项管理相关活动，通过规范化管理配置项，从而实现DevOps能更好与敏捷开发、TDD、微服务化、Cloud Native等相互配合与协作，最终实现高质量的快速交付产品及版本的频繁部署。

关键词：DevOps；配置项管理；软件配置管理

近几年，在互联网行业、软件行业DevOps理念成了一种趋势。DevOps是一种理念，倡导无缝协作和流水线自动化，它与敏捷开发、微服务化、Cloud Native等相互配合与协作，最终的目标是实现高质量的快速交付及频繁的版本部署。

软件配置管理（Software Configuration Management，SCM），是一套规范、高效的软件开发基础结构。作为管理软件开发过程有效的方法，它早已被软件产业的发展和实践所证明。SCM通过系统地管理软件系统中的各配置项；并全面记载配置项的演进历史过程，包括配置项命名规范、为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。配置项（Configuration Item，CI），是配置管理指定的工作产品的一个集合，在配置管理过程中看作一个单一实体。研发和管理过程中产生的工作产品，是配置管理基本的单元。软件配置管理在研发体系中发挥重要作用的主要体现，是在对配置项的规范管理上[1]。

为了更好地服务于DevOps模式的软件配置管理工作，岌待一套规范完整且适用于产品研发、项目实施的配置项管理活动。

1 基于DevOps的软件配置项管理

DevOps加快了构建、发布、部署的速度，为了达到这种快捷，通过工具实现自动化成了必然，需要工具做的操作，就必须要有一套工具能识别的信息输入规范，所以组成产品的配置项迫切需要有一套规范化的管理机制，成为软件配置管理活动中重要的组成部分[2]。

1.1 配置管理工具

互联网行业和软件行业的软件配置项一般存储在SVN或GIT等版本管理工具上。以笔者所在公司为例，我们使用SVN管理源代码、文档、SQL脚本、配置文件等配置项。配置库的目录结构划分及命名，都有具体的规范要求，举例说明：

branches：存放正在演进中的源代码

script：存放SQL脚本

tags：存放里程牌的产品基线

trunk： 存放需要发布热补的产品基线

1.2 配置项命名规范

软件产品包含的配置项一般由源代码文件、文档、镜像文件（传统模式称二进制文件）、SQL脚本、配置文件等组成。以我公司为例，在推行DevOps模式之前，我们制定了一套配置项名称规范，通过约束条件，让工具识别它、运行它，实现更多操作的自动化。

1.2.1 源代码文件

源代码文件标识，按模块实现的功能命名。

例如：账务管理的源码存放在payment目录；服务开通的源码存放在prov目录。

1.2.2 文档文件

文档标识，由“产品名称”“文档代号”“版本号”3部分组成，产品名称和文档代号之间以下划线分隔。

（1）产品名称：规划部门输出标准名称，产品名称统一用英文小写。（2）文档代号：D。（3）版本号：从1开始按顺序+1递增。

例如：CRM_D1.0—这代表crm产品1.0版本的文档。

1.2.3 镜像文件

镜像文件标识，由“产品名称”“进程名”“制作日期”“归属名称”4部分组成，每项之间用下划线分隔。

（1）产品名称：规划部门输出标准名称，产品名称统一用英文小写。（2）进程名：业务应用简称。（3）归属名称：public、project；public代表是公用产品镜像文件，project是某项目专用产品镜像文件，例如：南京项目project为nanjing。（4）制作日期：由数字标识，即当前制作镜像的时间。

例如：crm_app_public：CD_20180716212907—这代表crm产品app进程在2018.07.16.21.29.07时生成的公用镜像文件。

crm_api_nanjing：CD_20180726212808—这代表crm产品api进程在2018.07.26.21.28.08時生成的南京项目专用镜像文件。

镜像后缀CD_20180716212907用来区分镜像文件，CD流程构建默认为CD_{$datetime}，例如：CD_20180712123405，时间为构建时间。

CI流程构建默认为CI_{$datetime}，例如：CI_20180812123405，时间为构建时间。

1.2.4 配置文件

配置文件标识，由“产品名称”“进程名”“配置标志符”“归属名称”4部分组成，每项之间用减号分隔。

（1）产品名称：规划部门输出标准名称，产品名称统一用英文小写。（2）进程名：业务应用简称。（3）配置标识符：config。（4）归属名称：public、project；public代表是公用产品配置文件，project是某项目专用产品配置文件，譬如，杭州项目project为hangzhou。

例如：crm-app-config-public这代表是crm产品app公用的进程配置文件。

crm-api-config-hangzhou这代表是crm产品api杭州项目的进程配置文件。

1.2.5 全量SQL文件

全量建表脚本标识由“产品名称”“进程名”“数据库用户名”“数据库类型”4部分组成，中间用下划线分隔，名称统一使用小写。

（1）产品名称：规划部门输出标准名称，产品名称统一用英文小写。（2）进程名：业务应用简称。（3）数据库用户名：cc＼rb 等。（4）数据库类型：oracle＼mysql等。

例如：crm_app_cc_oracle.sql—这代表crm产品APP业务应用需要在oracle数据库cc数据库用户下执行的脚本。

1.2.6 热补增量SQL文件

热补的增量脚本标识是在产品热补标识的基础上，后面加在“数据库用户名”“数据库类型”组成。

（1）产品热补号：CRM_R1.0.1。（2）数据库用户名：cc＼rb等。（3）数据库类型：oracle＼mysql等。

例如：CRM_R1.0.1_cc_oracle.sql—这代表crm产品1.0.1产品热补需要在oracle数据库cc数据库用户下执行的脚本。

1.3 配置项控制

1.3.1 流程描述

（1）提交变更。根据不同配置项的命名，配置管理员会为每种配置项增加对应的变更类型并对每个变更申请赋予唯一标识，研发人员可以根据需要变更的配置项提交变更申请，配置管理员根据申请，检查变更的完整性和明确性，如果配置管理员认为申请变更描述不够完整，可以打回提交者重新提交。

（2）审核变更申请。需要对变更申请进行初步审核，如果确认是bug则直接转配置管理员授修改权限，进行修改、测试、发布，如果是需求需要提交软件变更控制委员会（Software Change Control Board，SCCB）审核。

（3）变更评估和分派。SCCB需要对变更申请进行充分的分析评估，涉及对系统性能、接口、可用性、成本、进度、需求的引用原因评估，通过评审后派发给研发人员修改。

（4）變更实施。变更人员需要获取必须的资源，由配置管理员从配置库中获取需要变更的配置项的正式版本，提交变更人员。对代码的修改涉及设计、编码、验证的过程，并且所有相关干系人需要对可能受到影响的文档进行更新。

（5）变更验证及入库。对已变更过的配置项，需要启动单元测试或自动化测试的验证，验证后才允许提交配置库。

1.3.2 输入

研发人员提供变更申请，申请通过后，可以对配置项进行修改，修改过程中严格按照配置项规范操作。

1.3.3 输出

提交经过自动化构建、测试，可供发布的软件配置项入库，配置管理员为变更后的配置项建立的新基线，随时可发布客户运维部署。

具体流程如图1所示。

2 结语

随着DevOps的进一步推广，研发流程对工具自动化要求的提高，灰度发布将成为主流，从而对软件中各种配置项的规范要求也会更高。所以正确地采用、实施规范的配置项，必将提高研发流程各环节的生产力，增强对整个项目的控制，改善软件产品的质量及交付速度。

[参考文献]

[1]珍妮佛，戴维斯，莱恩，等.Effective DevOps： building a culture of collaboration， affinity， and tooling at scale[M].北京：中国电力出版社，2018.

[2]伦恩·拜斯，英戈·韦伯，朱黎明.DevOps：软件架构师行动指南[M].北京：机械工业出版社，2017.

Abstract：This paper briefly describes the DevOps concept， based on DevOps configuration item management related activities， through the standardized management configuration items， so that DevOps can better cooperate with agile development， TDD， micro-service， Cloud Native， etc.， and finally achieve high-quality， fast delivery products and frequent deployments of versions.

Key words：DevOps； configuration item management； software configuration management