1、XXXXXXXX代码版本管理规范历史版本版本号 主要作者 修改记录 完成日期0.1 XXX 新建文档 2015/12/160.20.30.4目录历史版本 .21 引言 .41.1 目的 41.2 管理工具 42 现状概述 .53 现状分析 .53.1 现状详述 53.2 目标细化 63.3 SVN 版本管理 .63.3.1 概述 63.3.2 使用对比 74 完整的实施方案 .94.1 开发阶段 94.2 预发布测试阶段 91 引言1.1 目的为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。1.2 管理工具沿用 SV
2、N 管理工具来进行开发的版本管理，源代码管理和开发资料归档。2 现状概述目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。这样会造成如下两点影响： 会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部分问题是由于其他项目代码引起的。因此，随着公司和项目规
3、模的壮大，对软件代码版本管理提出了更高的要求。3 现状分析3.1 现状详述当前代码版本管理现状如下：1. 所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。2. 提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。3. 测试出 bug 以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此 bug 再做测试。这就导致了除了此 bug 之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布 bug 数量。总体来说，当前工作流程是：预发布出 bug，研发修改，再提交
4、测试，然后预发布测试通过的代码。整个流程也较为复杂消耗了大量人力，从而间接的增大了研发成本。(参照下图)开发库 测试服开发库 测试服再提交预发布发现橙色 bug提交开发库他人修改的代码修复 Bug4. 以上描述的过程还可能出现在正式环境上，导致更严重的后果。3.2 目标细化结合第一章节提及的本文目标、SVN 工具的能力以及之前工作中遇到的具体问题，将本规范的撰写目标具体细化为：1. 提交到测试服务器的代码只能包含本次需要测试的内容。2. 发布到预发布环境的代码只能包含这次需要测试的内容。3. 发布到正式环境的代码只能包含本次发版的内容。3.3 SVN 版本管理3.3.1 概述为了达成上述我们设
5、定的版本管理目标，在指定具体的策略之前，我们需要理解 SVN 的版本管理思路，这里简单将其阐述如下：首先，SVN(Subversion)有一个很标准的目录结构，如下:project+- trunk+- branches+- tags (此目录为只读)这个标准的目录结构在大多数的开源项目中都能看到，这套标准目录结构为软件开发提供了一种非常好的宏观的版本库管理机制，特别是在产品类项目管理中。其中，trunk 目录为主开发目录，branches 目录为分支开发目录，tags 目录为存档目录，也就是基线库。其各自含义描述如下：Trunk中文翻译为“主干”，在项目运作过程中，日常的开发和管理资料都在此目
6、录中进行维护和更新。Branches中文意思为“分支”，在项目运作过程中，用于存放阶段性的成果或者版本，这些阶段性的成果或者版本必须是可维护的。同时，这里的开发成果物必须要保持每天一到两次把主干上的内容合并过来。tags中文意思“标签”，此目录对一些阶段性的成果进行存档。此目录为只读目录，不允许进行修改。3.3.2 使用对比以下假设一个开发场景，并设想当前管理机制和 SVN 管理思路下的不同流程和结果，以便更好的理解 SVN 管理思路和带来的收益。场景描述：设备管理模块，其 v1.0 已经上线，正在做 v2.0 的开发。在这时，研发在开发库中正在做 v2.0 的开发，同时备份有 v1.0 的代
7、码，现在有一个紧急需求，需要在 v2.0 发版之前就应用到正式环境中去。3.3.2.1 现有的发布流程1. 在当前开发库（v2.0 ）的代码上直接修改实现紧急需求。2. 开发完成后，将本紧急需求连同 v2.0 的半成品代码（但编译能通过）一起打包提交到测试服务器。3. 测试只针对此紧急需求进行测试（v2.0 的内容不测试） ，并测试通过。4. 发预发布环境，同时测试（过程同上） 。5. 发到正式服务器。3.3.2.2 SVN 的发布流程1. 2.0 开始开发，trunk 目录下此时的代码内容为 v2.0 的开发版（半成品未完成） 。2. 基于 v1.0 的 tag 新建此紧急需求的开发分支 (
8、branchv1.1）此时的目录结构为svn:/proj/+trunk/ ( dev 2.0 )+branches/+dev_1.1(copy from tag/release_1.0)+tags/+release_1.0 (copy from trunk)3. 在 v1.1 branch 目录中进行紧急需求开发，在 trunk 目录中进行版本 v2.0 开发 。4. 在 v1.1 branch 开发完成后，基于 v1.1 的 branch 做现有的发布流程。这时在 v1.1的 branch 版本里只涉及了本次要发版的紧急需求，不含有其他修改，很好的规避了现有流程中的弊端。5. 根据需要选择性
9、的把 v1.1 这个分支 merge 回 trunk（是否执行和具体执行时间需要根据具体需求分析） 这是一种标准的开发模式，在很多公司中都有采用，此种模式下 trunk 永远是开发的主要目录。4 完整的实施方案分为开发阶段和测试阶段来分别阐述此方案：4.1 开发阶段1. 每一次正式版本发布后，存档形成一个版本基线，例如 v1.0，v1.3，v1.3.3。2. 拿到新需求（可以是多个）后，开发人员估计在下一次发版（v2.0）时能否开发完成。确定能开发完成随 v2.0 一起发版的则直接在主线上开发。3. 若不能确定在下一次发版时能一起发版的，或者修改很大的的情况，就需要新建一个分支，然后在这个分支
10、上面开发。需要注意的一点是为了保障发版前合并到主线尽量少产生冲突，需要至少每天把主线上的代码合并到自己开发的分支中来。4. 紧急发版（如 bug 修改）情况下，需要在下次发版前紧急再发一个版本的情况，就需要基于最新的基线新建一个分支，然后在这个分支上面进行开发，测试，发版。完成后再将其合并到主线上。4.2 预发布测试阶段预发布阶段的情况会稍微特殊一些，流程如下：1. 在预发布的时候先在 Tag 中做一个发布版本的同步快照2. 然后发布到预发布环境进行测试3. 若发布测试通过要正式发版的时候，如果在发布版本上有了修改(如 bug 修复) ，需要再往预发布环境发布的时候，就需要先和 Tag 中的快照进行版本比对，评估修改带来的影响范围。4. 针对影响范围重新进行测试5. 测试通过后把修改的内容合并到 Tag 中的同步快照中。总之，在这个阶段的核心思想是，预发布中发现的问题，在修复后提交时需要先和 Tag 中文件进行对比评估出影响范围，针对影响内容进行测试后，才能提交合并到 Tag 中。
