代码版本管理规范_v1.1.docx
文本预览下载声明
XXXXXXXX
代码版本管理规范
历史版本
版本号主要作者修改记录完成日期0.1XXX新建文档2015/12/160.20.30.4
目录
TOC \o 1-3 \h \z \u HYPERLINK \l _Toc438038110 历史版本 PAGEREF _Toc438038110 \h 2
HYPERLINK \l _Toc438038111 1 引言 PAGEREF _Toc438038111 \h 4
HYPERLINK \l _Toc438038112 1.1 目的 PAGEREF _Toc438038112 \h 4
HYPERLINK \l _Toc438038113 1.2 管理工具 PAGEREF _Toc438038113 \h 4
HYPERLINK \l _Toc438038114 2 现状概述 PAGEREF _Toc438038114 \h 5
HYPERLINK \l _Toc438038115 3 现状分析 PAGEREF _Toc438038115 \h 5
HYPERLINK \l _Toc438038116 3.1 现状详述 PAGEREF _Toc438038116 \h 5
HYPERLINK \l _Toc438038117 3.2 目标细化 PAGEREF _Toc438038117 \h 6
HYPERLINK \l _Toc438038118 3.3 SVN版本管理 PAGEREF _Toc438038118 \h 6
HYPERLINK \l _Toc438038119 3.3.1 概述 PAGEREF _Toc438038119 \h 6
HYPERLINK \l _Toc438038120 3.3.2 使用对比 PAGEREF _Toc438038120 \h 7
HYPERLINK \l _Toc438038121 4 完整的实施方案 PAGEREF _Toc438038121 \h 9
HYPERLINK \l _Toc438038122 4.1 开发阶段 PAGEREF _Toc438038122 \h 9
HYPERLINK \l _Toc438038123 4.2 预发布测试阶段 PAGEREF _Toc438038123 \h 9
引言
目的
为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。
管理工具
沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。
现状概述
目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。
这样会造成如下两点影响：
会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。
一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部分问题是由于其他项目代码引起的。
因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。
现状分析
现状详述
当前代码版本管理现状如下：
所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。
提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。
测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。
总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试通过的代码。整个流程也较为复杂消耗了大量人力，从而间接的增大了研发成本。(参照下图)
开发库
测试服
开发库
测试服
再提交
预发布
发现橙色bug
提交
开发库
他人修改的代码
修复Bug
以上描述的过程还可能出现在正式环境上，导致更严重的后果。
目标细化
结合第一章节提及的本文目标、SVN工具的能力以及之前工作中遇到的具体问题，将本规范的撰写目标具体细化为：
提交到测试服务器的代码只能包含本次需要测试的内容。
发
显示全部