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" inv-*)case "$CVS_USER" inzbwangjian | fengcui)exit 0 # ok;;*)echo "$CVS_USER does not have permission to perform this tag operation!" 1>&2exit 1;;esac;;DataCenter-*)case "$CVS_USER" inbuilder)exit 0 # ok;;*)echo "$CVS_USER does not have permission to perform this tag operation!" 1>&2exit 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" inv-*)case "$CVS_USER" inuser1 | user2)exit 0 # ok;;*)echo "$CVS_USER does not have permission to perform this tag operation!" 1>&2exit 1;;esac;;DataCenter-*)case "$CVS_USER" inbuilder)exit 0 # ok;;*)echo "$CVS_USER does not have permission to perform this tag operation!" 1>&2exit 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. 根据项目要求不同，无纸件则省略此操作。
