如何制定配置管理流程

如何制定配置管理流程
【IT168 技术文章】
以下是我们在实际工作中遇到的一个例子，这个例子充分说明了正确的工作流程对于保证软件产品质量的重要意义。

1. 问题描述
某一开发团队为其客户开发业务软件，系统上线之后存在着很多的业务需求变更，同时也有很多业务部门在使用过程中所发现的软件缺陷，我们把需求变更和软件缺陷统称为变更。

开发团队需要迅速响应客户所提出变更请求，把相应的软件版本修复及时地安装到生产系统上去。

为了保证产品质量，该开发团队建立了以下的软件发布流程：
图1
这四个环节分别对应以下四种环境：
开发环境：开发实现客户的变更请求
测试平台：开发团队把软件发布给客户之前做内部系统测试
准生产环境：客户把软件发布到生产系统之前做验收测试
生产系统：最终的生产系统
当开发团队将变更实现提交用户验收测试时，凡是没有通过验收测试的变更将被拒绝，只有通过验收测试的变更才会被部署到生产系统上去。

整个流程如下图所示，假设开发团队总共实现了3个变更，其中变更1和变更2通过了系统测试被提交用户验收测试，但只有变更1通过了用户验收测试，最终只有变更1被部署到生产系统上。

3. 改进建议
为了避免以上所述的这些质量陷阱，我们应该改进现有的配置管理流程。

（1）建立闭环的质量保证流程
造成以上质量隐患的根本原因是系统代码没有被作为一个整体来处理，并且在发布过程中我们发布的是源代码，正确的流程（也是业界较为通行的做法）应该发布构建后的目标码而非源代码。

我们可以建立一个闭环的质量保证流程（如下图所示）来批量地进行软件发布。

图6
其中系统测试过程中发现的缺陷应该被开发人员及时改正，然后再做构建，再测试，直到达到一个比较稳定的版本才会发布到验收测试环节。

同样的，验收测试中发现的问题也会回到开发环节进行修复。

这应该是一个多次循环的过程，不断地发现错误，然后改正，再测试。

这个循环到什么时候结束呢？这个取决于各个软件项目的实际情况：
最理想的情况当然是到所有的缺陷都被改正为止，但是所花的时间比较长，可能赶不上项目的进度要求，现实工作不大可能做到这一点。

折衷的情况是所有严重的缺陷（即那些影响系统使用的的缺陷）都必须被改正，但允许有一些已发现的缺陷遗留到后面再去解决,前提是所遗留的缺陷不会影响其他变更的实现。

大家平时在一些商用软件的新版本中经常可以见到发布说明（Release Notes）中所列的已知缺陷（Known Defects）就是属于这种情况。

我们向开发团队提出这个建议后，马上遭到项目经理的反对：“客户有些紧急的变更需要马上实现并交付生产运营，几乎没有时间来走这样完整的闭环流程。

”
（2）区别对待缺陷和新增功能
通过进一步了解我们发现紧急的变更一般是指影响系统正常使用的软件缺陷，这些缺陷需要及时的修复；而新增功能请求一般不是那么紧急的，允许开发团队有一段时间来开发实现。

但开发人员目前是把所有紧急和非紧急的变更请求混杂在一起实现的，往往是一个紧急的缺陷已经修复，但另外一个正在开发中的新增功能也修改了同一组文件版本，造成两者之间的版本依赖，从而导致紧急的缺陷修复不能按时提交。

我们建议把缺陷的修复工作和新增功能的开发工作区分开来，这就涉及到多个版本的并行开发，开发团队主要面临以下三个版本的开发：
v1.0中的缺陷修复
v1.0的新增功能版本v1.1
下一个版本v2.0
这样缺陷修复和新增功能开发相互独立，保证紧急的缺陷修复不会受到新增功能的影响。

（3）发布版本构建（build）而不是源代码
在这个案例中另外有一个不附合配置管理惯例的地方是在开发、测试、验收、生产四个环节发布的都是源代码，分别需要构建(包括编译)过后才能部署到相应的运行平台上。

由于软件构建的结果很可能会受构建平台及相应编译器版本所影响，最终在生产系统上的运行代码（在生产系统上构建得到）与准生产环境上的运行代码（在准生产环境上构建得到）可能不完全一致，有可能造成质量隐患。

比较通行的做法是所有平台上运行的构建代码应该只在构建服务器上生成一次，一次编译到处运行，这样才能保证各个平台上所用到的同版本运行代码是同一次构建的产物。

构建服务器通常就是由开发平台兼任，但如果是发布多个不同运行平台的版本的话，可以有多个构建服务器存在，例如，同一个软件既有AIX + DB2平台的运行版本，也有HPUX + Oracle平台的运行版本。

除了某些特殊的运行环境外，如IBM主机系统（mainframe）上明确要求在运行平台上对源代码进行编译构建，一般软件系统的开发都可以遵循这一个工作原则。

（4）版本发布管理
对于所发布的构建版本，我们也需要进行有序的管理，可以用版本号来唯一标识每一个发布版本。

一般可以把用于开发团队内部系统测试的称之为内部发布版本，把提交给客户的称之为外部发布版本，这两种软件发布版本都要统一编号管理。

在我们的例子中，内部发布版本可以简单地用构建号来表示，如:
v1.0_build_008 表示版本v1.0开发过程中生成的第8次构建外部发布版本可以由版本号和发布号组合而成，如:
v1.0_rel01 表示版本v1.0的第一个外部发布版本
对于v1.0中的缺陷修复，我们可以通过补丁的方式来发布，一个补丁中可以包含有多个缺陷修复，被修复的缺陷需要在补丁的发布说明（Release Notes）中写明，补丁名称可以由版本号、发布号和补丁号组合而成，如：
v1.0_rel01_p001 表示针对发布版本v1.0_rel01的第001号补丁对于v1.0中新增功能，我们需要制定一个发布计划，根据客户新增功能请求的紧急程度来分期分批实现。

一次发布中可以包含多个新增功能，并且包括所有已改正的软件缺陷。

这些改动都必须在发布说明中写明，发布版本号可以在前一个发布版本的基础上递增，如：
v1.1_rel02 表示版本v1.1的第二个外部发布版本
对于下一个版本v2.0的开发，则与版本v1.0开发的发布管理完全一致，如： v2.0_build_002 表示版本v2.0开发过程中生成的第2次构建在版本发布管理的流程中，发布版本的安装应该由专门的角色负责，可以是配置管理员或者是集成员（integrator）。

开发人员被禁止向各平台（测试平台、准生产环境、生产系统）上安装任何软件，并且各平台上所安装软件的版本号都应该有详细的记录。

当软件缺陷被发现时，我们就可以明确知道问题究竟是出在哪一个版本。

内部发布版本只会被安装到测试平台上，经过“开发->构建->测试->发现缺陷->修改代码”的多次循环之后，内部发布版本的质量趋于稳定，开发团队才会决定做一个外部发布版本。

外部发布版本被安装到准生产环境上，并且只有通过用户验收测试，它才可以被安装到生产系统上去。

如果该版本没有通过用户验收测试，那么开发团队需
要提供相应的补丁来解决用户验收中发现的问题，直到通过用户验收后再将该发布版本及其所有的累积补丁全部安装到生产系统上去。

有些情况下，最终通过验收测试的也可能是下一个发布版本，所以生产系统上安装的发布版本前后之间不一定是连续的，中间可能跳过一些质量不够成熟的版本。

同样的，只有通过用户验收测试的补丁才会被最终安装到生产系统上去。

紧急的补丁经过用户验收测试之后会马上安装到生产系统上，不紧急的补丁可以累积几个以后批量安装上去。

4. ClearCase工具实现
配置管理工具IBM Rational ClearCase可以很好地支持这种并行开发模式。

在ClearCase UCM（Unified Change Management，统一变更管理流程）工作模式中，我们可以在版本v1.0的发布版本基线（v1.0_rel01）的基础上分别创建针对三种版本（v1.0_bugfix, v1.1, v2.0）的开发项目（如下图所示）。

图7
在ClearCase的管理下，这三种版本位于不同的分支上，它们的开发是独立的，互不影响；并且版本v1.0_bugfix中的缺陷修复可以及时地合并到版本v1.1和v2.0中去，版本v1.1中的新增功能也可以在需要的时候合并到版本v2.0中去。

图8
ClearCase也为开发人员提供了方便易用的工作界面ClearCase Explorer，开发人员可以方便地选择任何一个版本项目来进行开发工作，ClearCase Explorer可以迅速准确地准备相应的工作版本。

所以这三种不同版本的开发完全可以由同一组开发人员来完成，大大提高了开发的工作效率。

图9
5. 总结
在这个案例学习中我们看到配置管理流程对于保证软件质量起着非常重要的作用，不恰当的流程可能导致潜在的质量缺陷，开发团队需要根据自身项目的情况来制定一个高效合理的配置管理流程。

有了一个好的流程，还需要一个好的配置管理工具来简化我们的管理工作，从而保证开发人员的工作效率和软件质量。

图2
为了支持这种工作流程，该团队分别在配置管理系统中管理了四种源代码版本：
图3
凡是通过每一个环节的变更所对应的源代码版本将被复制到下一个环节的版本基线中去。

看上去这一流程非常合理，不是吗？
2. 质量陷阱
让我们来看这种流程的两个应用案例。

场景I：未经测试的版本组合
在下面的例子中，文件f1、f2在修改之前的版本都是1，在实现了变更1、变更2后，它们的版本都变为了版本2，表示为f1(v2)、f2(v2)。

在整个的测试过程中，前面三个环境上测试的代码版本始终是文件f1和f2的版本2，但是最后变更1没有通过验收测试而变更2通过了，那么最终被部署到生产系统上去的版本将是：
f1(v1，这是f1原来在生产系统上的版本)
f2(v2，其中已包含了变更2所对应的版本2)
图4
但f1(v1)应该是跟f1(v1，变更1修改以前的版本)相匹配的版本组合，跟f2(v2)相匹配的版本组合应该是f1(v2)，由此可能发生的结果是：在生产系统上运行的是未经测试的版本组合!
场景II：未经测试的版本
在下面的例子中，在前面三个测试环节中，文件f2被测试的版本都是版本4。

当变更2未通过用户验收测试时，文件f2最终被复制到生产系统上的版本为3，这个版本是未经测试的。

图5
结果令人难以置信：在生产系统上运行的是未经测试的版本?!
任何一个软件系统，它的所有代码应该被作为一个整体来进行交付，而不是象上述例子中那样只交付部分的代码（变更相关的代码），这是造成质量陷阱的
根本原因。

一个看上去合理的流程存在本质的缺陷。

配置管理每日构建(一)
2008-03-14 来源：
1. 引言
1.1. 名词解释
先了解一些名词，有的是我自创的：
Nightly Build
字面直译为：每晚编译。

实现了自动编译，摆脱了编译的手工劳动；对于大型系统，编译耗时，在晚间完成则节约了工作成本；实现版本号的自动管理（Build号，每次编译自增）；
milestone 版本
里程碑版本。

在编译时，使用里程碑的代码。

例如定义为RELEASE 的里程碑，可以在每次重新将代码提升为RELEASE 时，删除上一次建立的RELEASE 的LABEL/TAG，再重新为新代码打上LABEL/TAG。

但更好的方法是将稳定的LABEL 记录在一个文件（如：PROMOTION）中，这个文件的最新内容即为里程碑代码的标签（TAG/LABEL），删除LABEL/TAG 的危险动作换成了新建LABEL/TAG 和Checkin 文件。

sticky 版本
固定版本。

有时想要编译某一固定状态（指定的LABEL/TAG）代码，可将这个LABEL/TAG 传给编译系统，进行编译，这种编译方式称为sticky 版本的编译。

nightly 版本
使用最新的代码进行编译。

如果代码自上次编译以来没有更改，则无需编译。

版本号
版本号的格式为：a.b.c.d。

其中 a - 主版本号（Major version）, b - 副版本号（Minor version）, c - 发布号（Release）, d - 编译号（build）。

主版本号和副版本号在项目计划中便已经指定，标志着重要的功能变动。

Release版本号c，用于体现小的功能变更或用来管理项目的分支。

build号则在每次编译时自动加1。

PROMOTION
版本提升。

某一里程碑（LABEL/TAG标记）代码，随着开发周期的继续，如果能够顺利通过各级测试，并最终发布。

则其对应的产品必然经历daily build版本、alpha测试版本、beta测试版本、release版本。

Starteam 版本控制系统，有专门的LABEL 管理这种事件，叫做PROMOTION。

对于其它版本控制系统，我们可以很容易的使用文件记录LABEL的方式相对应。

Starteam 的PROMOTION 请参见我的一篇文章《Starteam Howto》。

版本控制系统
版本控制系统，如：CVS、STARTEAM、PVCS、VSS等，是自动编译系统的基础。

熟练掌握其名利行工具的使用是关键。

推荐使用CVS作为版本控制系统，因为其命令行功能最强大。

1.2. 建立系统的命令行编译过程
如果没有命令行的编译过程，想要构建自动化的编译系统，简直是天方夜谭。

对于UNIX 的系统，支持命令行编译自然不再话下。

简单至一个Makefile，到复杂的SHELL 脚本、automake+autoconf 系统。

对于Windows 上的项目，比如说VC，其实也有命令行支持。

从VC5.0的NMAKE 到VC6.0 的MSDEV 命令。

但是Windows 平台的shell 实在功能有限。

查一下Windows 的关于batchfile 的帮助吧，只有可怜的半页，DOS时代的古董。

我们需要使用扩充的命令行工具来扩展。

可以的选择有JAVA、PERL、PYTHON、CYGWIN。

我选择了Cygwin ，是因为我只会Unix bash。

8-)
1.3. 关于版本号自增
实现BUILD 号自增，其实只要将版本号写入文件，并版本控制。

每次编译成功后，版本号+1，再重新Checkin 即可。

对于只需要一个版本号的系统，非常简单。

对于复杂的系统，比如说一个Windows 平台的程序，可能每一个dll, exe 都需要不同的版本。

也可以把这些相关信息写入一个文件，每次编译更新完毕代码后，在将一个文件控制的众多版本信息分别写到其它独立的版本控制文件中（如VC中的*.rc 文件中的FileVersion, ProductVersion 等）。

版本号的格式，参见：版本号说明。

1.4. 关于代码更新检查
如果代码没有更改，自动编译系统还要去编译，去使版本号递增，实在太傻，浪费时间，也会使开发、测试陷入混乱。

可以将上一次编译的时间记录在一个文件中，再次编译时，先比较自从上次编译以来，到现在为止是否有代码改动，如果有代码改动则版本号自增，并触发编译系统。

这看起来有点不可思议，其实一个命令就够了：
$ cvs -q diff --brief -D "上一次编译日期"
1.5. 关于软件包签名和下载
认为编译完成就完事大吉，是错误的。

如果不进行进一步的处理，下次编译将会冲掉上次编译的结果。

因此需要把生成的软件包，按照规则重新命名，例如加上版本号和编译日期。

如果软件包不便于访问，也不利于工作的开展。

在编译/发布机提供FTP 服务是最理想的。

还要说说软件签名。

不但是为了防止黑客的恶意篡改，也是协助下载用户对软件包进行完整性检查的方法。

参见我的一篇文档：《PGP/GPG HOWTO》。

1.6. 软件开发周期和版本号演进示意图(图略)
配置管理每日构建(三)
2008-03-14 来源：
3.自动编译系统的配置
3.1. 目录结构
工程源代码目录（NBDSOURCE）：在该目录下Checkout 工程的源代码。

它是整个工程的核心。

工程源代码配置目录（NBDSRCCTL）：在源代码目录下，创建一个存放控制文件的目录，如config，或者admin。

主要是放入存储编译日期、版本的文件
Nightly Build编译脚本目录(NBDSCRIPT)：在该目录Checkout 执行自动编译的脚本。

它是整个编译系统的工具箱。

Nightly Build启动目录(NBDHOMEDIR)：同样的编译脚本，要能够编译一个工程的不同的分支，也要能够编译如前所述的nightly, milestone, sticky 版本。

这就需要建立发起编译的目录，该目录主要放置一些能够区分不同编译条件的配置文件，以及启动编译脚本的钩子脚本。

3.2. 配置文件
3.2.1. NBDHOMEDIR/build.ini
用于指定源代码、脚本的路径。

#脚本的根路径源代码的根路径
NBDSCRIPT=/home/Administrator/work/jiangxin/src/nightlybuild/script/
NBDSOURCE=/home/Administrator/work/jiangxin/src/dlltest/
3.2.2. NBDHOMEDIR/LABEL
决定编译的版本：nightly, milestone, 还是sticky 版本。

空文件，或者内容为nightly 的文件，意味着编译nightly 版本。

内容为milestone，意味着编译milestone 版本。

内容为某一真实存在的标签LABEL/TAG，意味着编译该版本的sticky 编译。

3.2.3. NBDHOMEDIR/BRANCH
如果是空文件，或者内容为main，意味着当前代码处于主线。

如果是其它内容，则该内容为分支LABEL/TAG。

这个文件是和CVS 的MAGIC BRANCH 的概念向对应的，参见：《Per Cederqvist's CVS Manual》
3.2.
4. NBDHOMEDIR/nightly.sh
调用真正的脚本的钩子脚本。

#!/bin/sh
#set -x
NBDHOMEDIR=`dirname `
if echo "$NBDHOMEDIR" | grep -q -v "^/"; then
NBDHOMEDIR="`pwd`/$"
fi
NBDHOMEDIR=$
NBDHOMEDIR=$
export NBDHOMEDIR
build_file_name="$/build.ini"
if [ ! -f "$build_file_name" ]; then
echo "not find $build_file_name!" && exit 1
fi
. $build_file_name
cd $NBDSCRIPT
sh nightlybuild.sh "$@"
3.2.5. NBDSRCCTL/VERSION
记录版本号、编译日期
[myapp]
module=RegDllTest otherapp
version=1.3.5.10
buildtime=2003-04-01 20:44:48
revisonfile=RegDllTest/RegDllTest.rc
[mydll]
module=DisplayAppName
version=2.1.3.19
buildtime=2003-02-12 10:21:08
revisonfile=DisplayAppName/DisplayAppName.rc
[global]
version=1.0.0.1
buildtime=2003-04-01 20:44:48
表示一个单元的开始
模块列表，需要检查代码更新的模块列表
定义该单元模块的版本号
上一次该模块编译的时间
包含版本信息的资源文件，用本节定义的版本号去更新资源文件全局配置开始
整个软件包的版本号
3.2.6. NBDSRCCTL/PROMOTION
记录里程碑版本号。

例如：
JOHNSON-V-1-0-1
A. Nightly Build命令行
Synopsis: nightly.sh [options...] [command...]
Options :
-release (-r)
build RELEASE version (default)
-engineer (-e)
build engineer version
-force (-f)
force build.
Command:
nightly (n)
All commands are bind to one. there are three steps to run nightly.
update, compile, link, post
update (up)
1st step of running nightly.
update_source_code : step 1.1
update_version_file : step 1.2
update_rc_file : step 1.3
compile (c)
2nd step of running nightly.
run custom make.bat : step 2.1
link (l)
3rd step of running nightly.
run custom link.bat : step 3.1
post (l)
4th step of running nightly.
cp package to ftp_dir : step 4.1
checkin version file : step 4.2
Other Command:
help
This screen.
config
Additional help.
run nightly.sh config to see additional help.
B. 编程工具的命令行支持
B.1. Unix/Linux
使用autoconf/automake/autoheader工具
用autoconf/automake/autoheader工具来处理各种移植性的问题，用这些工具完成系统配置信息的收集，制作makefile 文件。

然后在打算编译源码时只需要通过“configure; make”这样简单的命令就可以得到干净利落的编译。

GNU Makefile 参见GNU Makefile和configure
BSD Makefile 参见FreeBSD Porter's Handbook
B.2. Visual C++
msdev 提供命令行编译支持，可以直接使用.dsw, .dsp 文件执行命令行编译。

Usage:
MSDEV [myprj.dsp|mywksp.dsw] - load project/workspace
[] - load source file
/? - display usage information
/EX - execute a VBScript macro
/OUT - redirect command line output to a file
/USEENV - ignore tools.options.directories settings
/MAKE [] [...] - build specified target(s)
[ - ]
[[|ALL] - [DEBUG|RELEASE|ALL]]
/CLEAN - delete intermediate files but don't build
/REBUILD - clean and build
/NORECURSE - don't build dependent projects
例如：MSDEV myprj.dsp /MAKE "ALL - Win32 Release" /REBUILD
B.3. C++ Builder
C++ Builder 的工程文件.bpr 文件是XML 格式的文件，不能直接提供给命令行进行编译，需要转换为.mak 格式的Makefile。

将.bpr 文件转换为.mak 文件：BPR2MAK -omyprj.mak myprj.bpr
执行命令行编译：MAKE -B -fmyprj.mak
B.4. Visual Basic
vb6[.exe] [[{/run | /r} projectname] [[{/d compileconst}] {/make | /m } projectname] [{/makedll | /l} projectname] {/cmd argument | /c argument}][ projectname][ or projectname /out filename}][][/sdi] or [/mdi]
B.5. Install Shield
命令行工具Compile.exe 和ISbuild.exe 可以完成命令行方式的打包。

Compile script_file [ifx_obl_file] [isrt_obl_file] [ifxobject_obl_file] switches
ISBuild [switches]
B.6. INNO Setup
命令行工具iscc.exe 可以完成命令行方式的打包。

iscc "c:isetupsamplesmy script.iss"
C. 时钟同步
在实践中，会发现编译机和版本控制服务器的时钟同步非常重要。

因为编译机确定编译的时间，是从本地取时钟，编译成功后，要将编译时间checkin 到版本控制服务器，以便下次执行自动编译时，从该文件获取上次编译时间，比较两个时间间隔内有否代码改动。

如果发布机的时钟和版本控制系统的时钟不一致，会导致代码更新的误判。

最近在网上发现了一篇文章，《A Beginner's Guide to Network Time Protocol--Other Time Software》，非常巧合的是，我在选择时间同步方案的时候，走了几乎相同的路。

对于工作组内平台相对单一，时钟同步是一件非常简单的事情：
加入Windows 域的Windows 平台的机器会定期和域控制服务器时钟同步。

亦可以使用命令"net time /setsntp" 和ntp 服务器时钟同步。

对于Unix服务器来说，则有更多选择的余地。

例如：从最简单的使用13端口的RFC867 daytime 协议；使用基于RFC868 Time Protocol 的rdate 命令从服务器读取时间来设置本地时间；运行timed，保持unix 机器自动同步时钟；以及用ntp 协议和国际标准时同步。

对于复杂的网络环境，使用ntp 确是上选。

Servers that provide synchronization to a sizeable population of clients normally operate as a group of three or more mutually redundant servers, each operating with three or more stratum-one or stratum-two servers in client-server modes, as well as all other members of the group in symmetric modes. This provides protection against malfunctions in which one or more servers fail to operate or provide incorrect time. The NTP algorithms have been specifically engineered to resist attacks where some fraction of the configured synchronization sources accidently or purposely provide incorrect time. In these cases a special voting procedure is used to identify spurious sources and discard their data.
参见：《A Beginner's Guide to Network Time Protocol (NTP)》, 《Notes on setting up a NTP subnet》...
选择几个内部的Unix 服务器非别和一组Internet 上的NTP 服务器保持时钟同步；
前面配置的服务器作为工作组内其它服务器的NTP 服务器；
非别在Unix 和Windows 平台安装客户端软件，和工作组内的NTP 服务器同步。

Unix上的NTP软件：
下载...
Windows上的NTP客户端的配置：
安装软件：automachron；
运行achron.exe /s 运行automachron；
使用工具Microsoft Windows NT Resource Kit: instsrv.exe, srvany.exe 将automachron 加入系统服务中，自动运行；
参见：让程序作为服务运行。

查看automachron 的运行日志，确定automachron 正确执行。