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>

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

该文件信息如下：

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

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

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

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

#! /bin/sh
if [ "${java_1_3_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. 根据项目要求不同，无纸件则省略此操作。