求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 
   
分享到
产品配置管理操作规范
 
作者 ,火龙果软件    发布于 2014-05-05
 

1. 开发库结构规范

1.1. 概述

本规范用于指导SCM经理创建开发库,保证开发库结构的通用性。

1.2. 开发库结构规范

开发库结构参考《开发库结构模版.zip》。

2. 帐号命名规范

2.1. 概述

本规范归纳总结了配置管理过程中配置库的帐号命名规范。便于SCM工程师进行及时查询,保证用户帐号的唯一性和易用性。

2.2. 开发库帐号命名规范

开发库帐号的命名,主要依据用户的邮箱而定,根据邮箱不同而略有变化,每个用户的帐号名称统一为英文小写。如下:

将邮箱域名中@变为“.”(不包括引号),然后作为cvs的登录帐号名称。

例1:用户,李四

邮箱为,lisi@***.com

帐号为,lisi.***.com

例2:同名用户,李四

邮箱为,zblisi@***.com

帐号为,zblisi.***.com

2.3. 交付库帐号命名规范

1. 与开发库的帐号名称要保持一致;

2. 与开发库命名规范相同;

2.4. sympa帐号命名规范

1. 以对应开发库名字作为帐号开头;

例1:开发库是scm

sympa帐号为,scm@scm5.***.cn,scm-dept@scm5.***.cn等

2.5. bugzilla帐号命名规范

1. 每个用户以工作邮箱作为帐号;

2.6. rt帐号命名规范

1. 每个用户以工作邮箱作为帐号;

2.7. tcedit帐号命名规范

1. 每个用户以工作邮箱作为帐号;

2.8. vpn帐号命名规范

1. 与开发库的帐号名称要保持一致;

2. 与开发库命名规范相同;

3. 帐号需直属总监批准才能开通;

2.9. 帐号密码命名规范

1. 用户的帐号密码是由数字和字母随机生成的。例如:A86345、dFd438、7yue3s;

2. 密码中不能包括“:”“@”等特殊符号;

3. 每个帐号的密码是唯一的。

2.10. 集团邮箱清单

3. 帐号权限管理规范

3.1. 概述

公司为每个产品建立对应的开发库、交付库,为了便于管理项目组不同成员对配置库的访问权限,SCM工程师需要根据此规范进行操作。

3.2. 帐号权限管理规范

1. SCM经理在完成配置库的创建后的1个工作日内,给项目经理、产品经理,业务领域总监、QA工程师开通相关的配置库帐号,并发出“新建配置库的创建通知”或“不采用默认结构配置库的创建通知”或“新项目使用原有配置库的创建通知”邮件通知;

2. 产品经理、项目经理从开发库获取《配置库结构及权限表》,将相关帐号、权限信息填入其中。完成后,将《配置库结构及权限表》作为邮件附件发给SCM工程师;

3. SCM工程师应在收到邮件后的1个工作日内,完成帐号开通工作,发送“全体人员帐号通知”邮件给项目经理,同时抄送给帐号持有者、本领域总监、和QA工程师;

4. 对于帐号、密码详细信息,SCM经理或SCM工程师须发送“CVS个人帐号通知”和(或)“FTP个人帐号上传权限通知”和(或)“FTP人帐号下载权限通知”单独邮件通知给各帐号持有人。

5. 在某些特殊情况下,SCM工程师可以根据口头通知开通帐号、权限,但需同步更新《配置库结构及权限表》;

6. SCM工程师需要长期保留收到、答复的开通、变更帐号、权限信息的相关邮件,存档备查。

3.3. 权限的基本规则

1. 权限按目录分别定义,避免对具体的文件定义权限;

2. 权限按角色划分为权限组,不同的权限组有不同的权限,避免组与组之间权限相同;

3. 不同的权限组有不同文档、源代码目录的权限,避免某个权限组有所有文档或源代码目录的权限;

4. SCM工程师新建配置库时,提交的《配置库结构及权限表》中的权限信息是依照以上规则定义的默认权限,项目经理可以根据配置库的具体情况略做修改,但需符合以上规则;

5. SCM工程师在开通、变更权限时,需检查是否符合以上规则,不符时需及时反馈确认。

6. 开发库的权限一般不要超过三级目录。

4. 邮件列表管理规范

4.1. 概述

通过邮件列表将公司各邮箱用户按所在项目组的不同进行分组,类似于群发邮件的功能,它提供便捷的项目团队沟通方式。

4.2. 邮箱地址规范

邮件列表只用于集团内部沟通,邮件列表中的邮箱地址只允许使用集团邮箱。集团邮箱清单参见2.5节。

5. 版本管理规范

5.1. 概述

按照一定的规则保存配置项的所有版本记录,避免发生版本丢失或混淆等现象,并且可以快速准确的查找到配置项的任何版本。

5.2. 源代码的版本命名规则

1. 一般格式:“英文项目名或模块名.项目版本.流水号”。

其中,项目版本格式:“主版本号.子版本号[.修正版本号]”;

例如:

webshop.3.0.2.1。其中,webshop,是英文项目名;3.0.2,是项目版本;1,是流水号;

webshop.3.0.2.12。其中,webshop,是英文项目名;3.0.2,是项目版本;12,是流水号。

2. 维护项目格式:“英文项目名或模块名.维护项目版本.流水号”。

其中,维护项目版本格式:“{sp|fix|hotfix|…}主版本号”;

例如:

***.sp1.1。其中,***,是英文项目名;sp1,是维护项目版本;1,是流水号。

5.3. 文档的版本命名规则

1. 一般格式:“v.项目版本.流水号”;

其中,项目版本格式:“主版本号.子版本号[.修正版本号]”;

例如:

v.3.0.2.1。其中,v,是固定前缀;3.0.2,是项目版本;1,是流水号。

2. 维护项目格式:“v.维护项目版本.流水号”;

其中,维护项目版本格式:“{sp|fix|hotfix|…}主版本号”;

例如:

v.sp1.1。其中, v,是固定前缀;sp1,是维护项目版本;1是流水号。

5.4. 版本的TAG标识

1. 源代码和文档的版本号在开发库中用tag进行标识,由于CVS规定tag中不能有“.”,因此,版本中的“.”在tag中用“-”替换;

2. 一般格式:“英文项目名或模块名-项目版本-流水号”、“v-项目版本-流水号”;

其中项目版本格式:“主版本号-子版本号[-修正版本号]”

例如:webshop-3-0-2-1、webshop-3-0-2-12、v-3-0-2-1。

3. 维护项目版本格式:“英文项目名或模块名-维护项目版本-流水号”、“v-维护项目版本-流水号”;

其中维护项目版本格式:“{sp|fix|hotfix|…}主版本号”

例如:***-sp1-1、v-sp1-1。

6. 自动编译操作规范

6.1. 概述

为保证开发库中源代码与交付库中程序包的一致性,提高源代码的编译效率,SCM工程师需要依据此规范进行自动编译的操作。

6.2. 确定编译信息

SCM工程师需根据《项目编译手册》、《虚拟机清单》的内容确定编译机、编译工具、编译所需环境变量等信息。

6.3. 搭建自动编译客户端编译环境

搭建客户端编译环境主要针对环境变量的配置,和编译工具的安装。

例如,编译信息中指定安装apache-ant-1.6.5,定义环境变量ant1.6.5:

1. 在编译机器上安装此程序;

2. 找到cc-agent的安装文件夹,以记事本的形式打开start.bat,并填写一条环境变量记录:set ant1.6.5=e:apache-ant-1.6.5;

6.4. 建立builder用户

SCM工程师建立builder用户到该项目,并分配到BD权限组里面,便于编译系统能通过builder用户获取源代码。

修改tagcheck文件,便于自动锁定自动编译标记的源代码tag。

tagcheck文件示例如下

#! /bin/sh
# TAG add/mov/del repo files...
# $1 $2 $3 $4 ...
case "$1" in
v-*)
case "$CVS_USER" in
zbwangjian | fengcui)
exit 0 # ok;;
*)
echo "$CVS_USER does not have permission to perform this tag operation!" 1>&2
exit 1;;
esac;;
DataCenter-*)
case "$CVS_USER" in
builder)
exit 0 # ok;;
*)
echo "$CVS_USER does not have permission to perform this tag operation!" 1>&2
exit 1;;
esac;;
*)
exit 0 # not reserved, ok.;;
esac

6.5. 配置自动编译服务器端环境

自动编译客户端环境变量及工具配置完成后,开始对自动编译服务器端进行配置。

1. 首先,进入到自动编译服务器端的如下目录:

$cd /cruisecontrol/projects/project11/

在该目录中可以看到两个xml格式的模版:0linux.xml和0windows.xml分别针对linux系统的编译机和windows系统的编译机。根据实际编译机系统情况进行选择复制,并将名称修改为“英文项目名或模块名-项目版本.xml”的形式,名称开头必须和开发库名称一致,以保证tag锁有效。

以0linux.xml为例,介绍一下如何修改配置文件。

(“*”号处为需要修改的内容,“#”号后为注释)

<?xml version="1.0" encoding="GBK"?>
<cruisecontrol>

<project name="***" buildafterfailed="false"> #英文项目名或模块名-项目版本,如***-1-0

<property name="module" value="***/***"/> #编译脚本所在目录

<property name="module2" value="***/***"/> #检出到本地的编译脚本所在目录(windows注意斜杠方向为“”)

<property name="ftp2.dir" value="/repository/ftpdata/***/Output/${project.name}"/> #项目配置库名称,比如cvstrain

<property name="tag" value="***"/> #系统集成工程师打上的tag号,为了便于记忆,取编译脚本名称中“.”的前缀作为tag号,例如:编译脚本名称是“build.sh”,tag就是“build”

<property name="buildfile" value="***.sh"/> #编译脚本名称,例如:build.sh,windows为build.bat

<property name="cvsroot" value=":pserver:builder:***@scm3.***.cn:/repository/***"/> #输入所建立builder的密码

<property name="agent" value="agent.name=***"/> #编译服务器的agentname,可以到《虚拟机清单.doc》中查询到

<property

name="buildresultsurl" value="http://scm3.***.cn:8080/cruisecontrol/buildresults/${project.name}"/>

<property name="mailto" value="***@***.cn"/> #执行编译操作人员的邮件地址,若有多人需接收时,使用邮件列表

<property name="mailhost" value="mail.***.cn"/>

<property name="returnaddress" value="cruise@mydomain.com"/>

2. 然后,返回上一级目录,配置config.xml文件。

该文件信息如下:

<cruisecontrol>
<property name="cruise.dir" value="/opt/cruisecontrol-2.7.1"/>

<property name="jetty.dir" value="/opt/jetty-6.1.6"/>

<property name="log.dir" value="${cruise.dir}/logs/${project.name}"/>

<property name="checkout.dir" value="${cruise.dir}/checkout/${project.name}"/>

<property name="output.dir" value="${cruise.dir}/output/${project.name}"/>

<property name="ftp.dir" value="/repository/ftpdata/${project.name}/Output" />

<property name="status.file" value="${log.dir}/status.txt"/>

<pluginname="distributed" classname="net.sourceforge.cruisecontrol.builders.DistributedMasterBuilder"/>

<pluginname="labelincrementer" classname="net.sourceforge.cruisecontrol.labelincrementers.CVSLabelIncrementer"/>

<include.projects file="${cruise.dir}/projects/***"/> #项目xml文件的路径

<system>

<configuration>

<threads count="20"/>

</configuration>

</system>

</cruisecontrol>

至此,编译环境配置完成。

6.6. 显示编译项目记录

打开cruisecontrol编译页面,例如http://scm1.***.cn:8080/cruisecontrol5/,并没有新建的编译项目记录,此时,应该先点击预先设计好的一个测试项目工程,例如cvstrain-win-5-0,点击build按钮,触发后就看到了刚新建的编译项目记录。

6.7. 记录编译环境信息

编译环境搭建完成后,

1. SCM工程师记录编译环境信息到《项目基线记录表》中;

2. SCM工程师回复邮件“自动编译通知”给系统集成工程师;

3. 系统集成工程师按照邮件中提示进行操作,给需要编译的代码打约定的tag号,然后登陆相关页面进行编译工作。

注意:

1. 如果该项目并非第一次进行自动编译,可以简化以上操作:

SCM工程师检查《项目编译手册》和前序版本的《项目编译手册》,如果编译环境说明相同,就可以仅对自动编译服务器端配置新的编译项目记录。

首先,进入到自动编译服务器端的如下目录:

$ cd /cruisecontrol/projects/

在该目录中可以选择该项目的前一版本的xml文件作为模板,进行复制,并将名称修改为此次项目的版本名称,形式为“英文项目名或模块名-项目版本.xml”。

进入该配置文件,修改project name为本次项目名称,如果没有特殊说明,其他都同之前版本,配置完成后,保存退出。

然后,返回上一级目录,配置config.xml文件。复制前一版本的include节点信息,并修改xml文件名字为上面修改的.xml文件的名字即可。

l 搭建完成后,SCM工程师回复邮件“自动编译通知”给系统集成工程师。

2. 编译过程中,若有问题,SCM工程师需及时协助编译人员解决问题,直至编译成功;

3. 自动编译系统故障、网络故障等情况,暂时无法使用自动编译时,SCM工程师要以邮件方式通知相关QA和SCM经理,获得批准后,由SCM工程师根据系统集成工程师提供的tag号,按规范标注新的tag号,手动编译,手动上传至交付库(FTP)上,交付库目录的规则为:最后成功自动编译tag号-*(*为字母a,b,c…),比如:VOMS-1-1-7-a,VOMS-1-1-7-b

4. 经批准暂不采用自动编译的项目,由系统集成工程师或SCM工程师手动编译,由SCM工程师手动上传至交付库(FTP)上,交付库目录的规则为:tag号-a,比如:VOMS-1-1-7-a,VOMS-1-1-8-a;记录不采用自动编译的原因到《项目基线记录表》中,比如:经批准不做自动编译

7. 自动编译调用接口文件规范

7.1. 概述

SCM工程师协助系统集成工程师根据此规范准备编译脚本,并验证编译脚本的规范性,反馈存在的缺陷。

7.2. 交付库(FTP)上传文件规则

为了保证版本的一致性,《产品项目工作成果清单》中列名的程序包、工具包文件必须通过自动编译工具上传到交付库上,而后让部署人员从交付库上获取,除非自动编译系统出现故障。

7.3. 自动编译规则

只要不是《产品项目工作成果清单》中列名的,也就是不在版本控制范围内的文件,可以不经过自动编译,方式不限,直接发给相关人员。

7.4. 获取文件方式

最终发布前,部署人员、测试人员需要从开发库中获取《产品项目工作成果清单》中列名的的文件,这些文件只有在最终发布时,才会由SCM工程师放到交付库上。

7.5. 自动编译的启动接口文件

要实现cruisecontrol下的自动编译,要求项目源代码必须能够以命令行方式完全自动编译,项目组和SCM工程师商定自动编译的启动接口文件名,比如build.bat或build.sh。

在项目源代码的根目录下添加build.bat或build.sh文件,内容为调用项目代码自动编译。

1. windows系统编译使用build.bat,linux系统编译使用build.sh;

举例:

在windows系统编译ant项目,在项目源代码的根目录下添加build.bat,内容如下

setlocal
if "%java.1.3.0%" == "" goto ERROR

if "%ant.1.5.0%" == "" goto ERROR

set JAVA_HOME=%java.1.3.0% //标红部分根据实际使用的版本号修改

set ANT_HOME=%ant.1.5.0%

set PATH=%JAVA_HOME%bin;%ANT_HOMEbin;%PATH%

ant //标红部分就是实际的编译程序,不同项目会不一样

IF %ERRORLEVEL% NEQ 0 GOTO ERROR

echo Succeeded!

endlocal

exit 0

:ERROR

ECHO Failed!

endlocal

exit 1

在linux系统编译ant项目,在项目源代码的根目录下添加build.sh,内容如下:

#! /bin/sh
if [ "${java_1_3_0}" = "" ]; then exit 1 ; fi

if [ "${ant_1_5_0}" = "" ]; then exit 1 ; fi

export JAVA_HOME="${java_1_3_0}" //标红部分根据实际使用的版本号修改

export ANT_HOME="${ant_1_5_0}"

export PATH="${ANT_HOME}/bin:${JAVA_HOME}/bin:${PATH}"

ant //标红部分就是实际的编译程序,不同项目会不一样

if [ $? -ne 0 ]; then exit 1 ; fi

2. 对接口文件的要求:

JAVA_HOME= 等这些定义,不要直接写绝对路径,用调用环境变量的方式,保证基本的可移植性;

build.sh或build.bat 不带任何参数时即执行编译,不要包括cvs的相关操作,这些都由CruiseControl去做了;

编译结果放在output目录下,CruiseControl会自动把output下的所有内容传到ftp上,但cvs中不能有output目录,需要在编译时新建;

build.sh或build.bat执行异常时要能中断退出,报exit 1,便于CruiseControl判断build.sh或build.bat执行是否成功;

build.sh或build.bat要放在cvs中的源代码的根目录下,作为源码的一部分,便于CruiseControl调用;

编译结果建议以tar、zip形式放在output目录下,便于使用。

8. 基线管理操作规范

8.1. 概述

对于产品中经过评审、批准的重要工作成果,SCM工程师需要根据此流程对该配置项进行基线管理。

8.2. 确认配置项

1. SCM工程师接收到项目组签字后的《工作成果签字确认表》、《阶段验收签字确认表》或“评审通过确认邮件”之后,确认要入基线的配置项的名称、版本、路径在开发库中是否确实存在且完全一致,是否符合《项目工作成果清单》说明,如果表中的信息不正确,需退回重新确认。

以工作成果确认表为例:(请看图中红字标注的几个注意点)

8.3. 获取配置项

1. 在Wincvs中,选择checkout(检出)或Update(更新)该配置项到本地;入基线时,必须根据指定的Rev.将配置项下载到本地。如图:

2. 检查配置项提交的格式是否正确,是否能正常打开。

8.4. 建立基线

1. 单击指定Rev.号的配置项,如下图所示,点击 ,在弹出的对话框“New tag name”地方写上基线版本号(命名规则:详见版本管理规范),确定;

2. 若想取消已打的Tag号,点击 后,在“Delete tag”中填写要取消的Tag号->确定。

自动编译的源代码入基线是不用打tag的;

关于锁tag:修改CVSROOT下的tagcheck文件红色标注处;

#! /bin/sh
# TAG add/mov/del repo files...

# $1 $2 $3 $4 ...

case "$1" in
v-*)
case "$CVS_USER" in
user1 | user2)
exit 0 # ok;;
*)
echo "$CVS_USER does not have permission to perform this tag operation!" 1>&2
exit 1;;
esac;;
DataCenter-*)
case "$CVS_USER" in
builder)
exit 0 # ok;;
*)
echo "$CVS_USER does not have permission to perform this tag operation!" 1>&2
exit 1;;
esac;;
*)
exit 0 # not reserved, ok.;;
esac

注意:

tagcheck文件修改完毕后,保存退出并commit提交修改。

8.5. 保存邮件

SCM工程师将电子审批/确认通过邮件另存为htm格式文件,提交到开发库中相应的基线目录下保存。

若包含多个基线工作成果,则每个相应的基线目录下都保存一份。

注意:

1. 根据项目要求不同,无邮件则省略此操作。

8.6. 更新基线状态

在开发库(AccessControl)目录中,SCM工程师更新《项目基线记录表》。填写以下容:

基线名称 配置项(cvs路径) Rev. 基线版本(tag) 交付成果 & MD5码 ftp路径 时间 备注
注意:

1. 一个项目建一个excel文件来记录。

2. 在备注栏记录入基线的mail通知在开发库中的全路径信息。

8.7. 保存基线记录表

当SCM工程师对《项目基线记录表》中的内容进行了更新,同时需要提交到开发库中保存。

注意:

1. 配置项入基线时,配置项不用上传到交付库中;

2. 关于无QA工程师跟踪的项目,项目的流程方面的问题请和质量信息管理员联系,相关的文件的“QA工程师”栏中填质量信息管理员。

8.8. 发送基线通知

SCM工程师提交《项目基线记录表》后,以邮件方式发送“配置项基线通知”给QA工程师、项目经理、SCM经理和项目组相关人员。

8.9. 签字确认

SCM工程师在收到纸版的《工作成果签字确认表》后,需要确认纸版内容和电子版一致,然后签字。

注意:

1. 根据项目要求不同,无纸件则省略此操作。

简化流程1

针对测试经理更新的测试用例文档的基线管理,可以采用以下简化流程。

1. SCM工程师接收到测试经理发出的测试用例文档入基线的mail通知时,检查mail中配置项基线信息是否完整、正确,否则退回给测试经理重新确认。

2. 参照8.3节要求获取配置项。

3. 参照8.4节要求建立基线。

4. 参照8.5节要求保存mail通知。

5. 参照8.6节要求更新基线状态。

6. 参照8.7节要求保存项目基线记录表。

7. 参照8.8节要求发送基线通知。

简化流程2

针对数商 业务组件、界面组件、数商ZV3.2项目升级的模块的详细设计文档(不包含数据库设计)的基线管理,可以采用以下简化流程。

1. SCM工程师接收到开发经理发出的评审纪要入基线的mail通知时,检查mail中配置项基线信息是否完整、正确,否则退回给开发经理重新确认。

2. 参照8.3节要求获取配置项。

3. 参照8.4节要求建立基线。

4. 参照8.5节要求保存mail通知。

5. 参照8.6节要求更新基线状态。

6. 参照8.7节要求保存项目基线记录表。

7. 参照8.8节要求发送基线通知。

9. 交付管理操作规范

9.1. 概述

在项目交付阶段,需要最终明确交付的工作成果和版本的正确性。

9.2. 检查交付内容

SCM工程师在收到包含电子版的《项目发布审批表》或《组件信息表》mail之后,检查表中各栏目是否按照规范填写完整,是否符合《项目工作成果清单》说明;

在《项目发布审批表》或《组件信息表》中,需要SCM工程师确认的内容如下图红色字体标注的地方:

注意:

若有编译依赖,则需按图中样式记录。

9.3. 检查基线状态

SCM工程师检查待交付的配置项是否已形成基线,对于未形成基线的配置项,参照8.1-8.6节规范建立基线。

9.4. 交付配置项

1. 在Wincvs中,选择checkout(检出)或Update(更新)该配置项到本地;

2. 接着把项目配置项从cvs中取出,并生成相应的MD5码,一同交付到交付库的相应目录。

3. 对于为了便于运营经理部署操作,而提供的第三方非配置项或根据《系统部署安装配置手册》、《产品升级指南》(升级项目)对上线配置项二次制做后的非配置项,可以由SCM工程师确认,并手动上传至交付库的相应目录。

9.5. 更新交付状态

在开发库(AccessControl)目录中,SCM工程师更新《项目基线记录表》。填写以下内容:

基线版本(tag) 交付成果 & MD5码 ftp路径 时间 备注

9.6. 填写发布审批表

SCM工程师在完成产品的交付工作后,需要填写电子版的《项目发布审批表》或《组件信息表》,全部答复mail。

9.7. 保存基线记录表

当SCM工程师对《项目基线记录表》中的内容进行了更新,同时需要提交到开发库中保存。

9.8. 发送交付通知

SCM工程师提交《项目基线记录表》后,以邮件方式发送“配置项交付通知”给QA工程师、项目经理、SCM经理和项目组相关人员。

9.9. 签字确认

SCM工程师在收到纸版的《项目发布审批表》或《组件信息表》后,需要确认纸版内容和电子版一致,然后签字。

10. 代码行统计操作规范

10.1. 概述

为辅助项目度量、考核,SCM工程师根据QA工程师要求,对项目源代码版本的代码行进行统计。

10.2. 统计方法

QA工程师将需要统计的项目基线版本、文件类型等信息,以邮件方式发送给SCM工程师。

SCM工程师将相应的源代码获取后,使用指定的统计工具进行代码行统计。

10.3. 更新统计状态

在开发库(AccessControl)目录中,SCM工程师更新《项目基线记录表》。填写以下内容:

配置项(cvs路径) 文件类型 基线版本(tag) 统计代码行数 项目tag号 时间 备注

10.4. 保存基线记录表

当SCM工程师对《项目基线记录表》中的内容进行了更新,同时需要提交到开发库中保存。

10.5. 发送统计通知

SCM工程师提交《项目基线记录表》后,以邮件方式发送“代码行统计通知”给QA工程师、项目经理、SCM经理和项目组相关人员。

11. 结项管理操作规范

11.1. 概述

在项目结项、暂停、取消时,最终审核配置项的完整性、一致性,清理非配置项。

11.2. 配置库审核

SCM工程师在收到“服务交付阶段结束及项目结项开始通知”(针对内部研发和组件项目)和“Beta测试阶段结束及项目结项开始通知”(针对产品项目)邮件后,根据《项目工作成果清单》、《项目基线记录表》,确认各配置项的状态、完整性、一致性,反馈项目经理存在的问题。

SCM工程师和项目经理协商清理配置库中的非配置项。

清理配置库中的非配置项标准:

1. 入过基线的版本不能清。

2. 未入过基线,但确定要保留的版本不能清。

3. 未入过基线,测试中的版本不能清。

4. 最新2次的编译版本不能清。

清理完毕后,将清理信息记录到《配置库清理记录.txt》中。

11.3. 更新编译状态

在自动编译服务器上的配置文件config.xml中,SCM工程师清除相关自动编译项。

11.4. 更新结项状态

在开发库(AccessControl)目录中,SCM工程师更新《项目基线记录表》。填写以下容:

项目编号 项目tag号 状态(结项/暂停/取消) 时间 备注

11.5. 保存基线记录表

当SCM工程师对《项目基线记录表》中的内容进行了更新,同时需要提交到开发库中保存。

11.6. 发送结项通知

SCM工程师提交《项目基线记录表》后,以邮件方式发送“配置项结项通知”给QA工程师、项目经理、SCM经理和项目组相关人员。

12. 运营维护支持操作规范

12.1. 概述

产品交付上线后,SCM工程师根据产品维护升级的需要,提供相应的配置管理支持。

12.2. 基线管理

1. 确认纳入基线的配置项

SCM工程师收到项目管理平台发送的主题为“….(状态:完成)”的《维护任务单》之后,检查《维护任务单》中各栏目是否按照规范填写完整,如果配置项信息不正确,需退回给相应的项目经理、QA工程师重新确认。

《维护任务单》的配置项中只需文档入基线,代码不入基线。

对于客户端项目,因不涉及运营,代码通过维护任务单入基线。例如:qihuo-athena项目。

2. 获取配置项

参照8.3节要求获取配置项。

3. 建立基线

参照8.4节要求建立基线。

4. 保存邮件

参照8.5节要求保存任务完成邮件。

5. 更新基线状态

参照8.6节要求更新基线状态。

6. 保存基线记录表

参照8.7节要求保存项目基线记录表。

7. 发送基线通知

参照8.8节要求发送基线通知。

12.3. 交付管理

1. 检查交付内容

SCM工程师在收到包含电子版的《项目-运营系统变更确认表》mail之后,检查表中各栏目是否按照规范填写完整,是否符合《项目工作成果清单》说明;

在《项目-运营系统变更确认表》中,需要SCM工程师确认的内容如下图红色字体标注的地方:

注意:

若有编译依赖,则需按图中样式记录。

2. 检查基线状态

参照9.3节要求检查基线状态

3. 交付配置项

参照9.4节要求交付配置项

4. 更新交付状态

参照9.5节要求更新交付状态

5. 填写运营变更表

SCM工程师在电子版的《项目-运营系统变更确认表》,全部答复mail。

6. 保存基线记录表

参照9.7节要求保存项目基线记录表

7. 发送交付通知

参照9.9节要求发送交付通知

8. 签字确认

SCM工程师在收到纸版的《项目-运营系统变更确认表》后,需要确认纸版内容和电子版一致,然后签字。

注意:

1. 根据项目要求不同,无纸件则省略此操作。

相关文章

每日构建解决方案
如何制定有效的配置管理流程
配置管理主要活动及实现方法
构建管理入门
相关文档

配置管理流程
配置管理白皮书
CM09_C配置管理标准
使用SVN进行版本控制
相关课程

配置管理实践
配置管理方法、工具与应用
多层次集成配置管理
产品发布管理
 
分享到
 
 
   


软件配置管理的问题、目的
软件配置管理规范
CQWeb 7.1性能测试与调优指南
为什么需要使用ClearCase
ClearCase与RTC的集成
利用ClearQuest 进行测试管理
更多...   


产品发布管理
配置管理方法、实践、工具
多层次集成配置管理
使用CC与CQ进行项目实践
CVS与配置管理
Subversion管理员


配置管理实践(从组织级到项目级)
通号院 配置管理规范与应用
配置管理日构建及持续集成
丹佛斯 ClearCase与配置管理
中国移动 软件配置管理
中国银行 软件配置管理
天津华翼蓝天科技 配置管理与Pvcs