SVN版本控制流程.docVIP

版本控制流程 目录 1. 概述 3 1.1. 版本控制系统工具的选择 3 1.2. Subversion特点简述 3 2. 版本控制流程 3 2.1. 目标 3 2.2. 原则 4 2.3. 流程 4 2.4. 好处 4 3. SVN版本控制 4 3.1. 版本控制目录设置 4 3.2. 版本控制级别 5 3.3. 版本控制目录的权限设置 5 3.4. 测试团队的基线版本 5 3.5. 版本提交流程 6 3.6. 版本提交的时间 6 4. 版本安全 7 概述 版本控制系统工具的选择 采用subversion开源的版本控制系统 Subversion特点简述 目录版本控制 不同于 CVS 只关心文件的内容以及文件是否存在，所有文件、目录的相关操作都是被版本化的，例如文件的改名、拷贝等等； 不可分割的送交 提交操作是不可分割的，修订版本号是基于每次提交操作而非文件。提交日志被附加在每个修订版本中，而不是像 CVS 一样冗余的进行存储； 分支（Branching）与标记（Tagging）操作是轻量级的 效率高； 当你发布了一个正式版，可以建立一个分支，在分支上继续开发下一个版本，而对于后来发现的Bug，可以在主分支上继续改进，如果分支上同样存在这个Bug，可以将两者合并。 版本控制流程目标保证各个环境(开发、测试、主干)的独立，避免相互影响。减少最终发布时合并主干出现冲突的概率。降低冲突处理的难度。原则多个版本（开发版本，测试版本，发布版本）；多次合并。流程?项目开发编码前从当前主干建立一条开发分支，供项目开发人员使用；开发结束，提交测试的时候，从当前主干建立一条测试分支，将开发分支合并到测试分支上，供测试人员进行测试。这样开发人员对开发分支的修改不会影响测试环境；bug fix的时候我们定时将开发分支的修改合并到测试环境中。回归测试的时候，从当前主干建议一条发布分支，将测试分支合并到该发布分支上，在发布分支上进行回归测试。发布前，将发布分支合并到当前主干。 好处多个版本相互独立，互不影响通过多次与主干的合并，这样发布时候和主干做最后一次合并的冲突会大大减少，并且在与主干多次合并过程中的冲突解决都在测试阶段中得到了测试。 建议：如果项目的周期比较长，和主干进行合并的次数也应该加大，以降低处理冲突的难度。 目录 描述 权限 UserName 每个用户有一个独立的目录 主用户：rw 其他已经授权的用户：r TempArea 临时存放文件的目录 AllUase：rw CommonDOC 公共文档，例如需求文档、开发规范等 PM、PL、SA用户：rw 其他已经授权的用户：r DesignDOC 需求分析文档、设计文档（含数据库设计） PM、PL、SA：rw 其他已经授权的用户：r MDOC 正式提交的必须文档（文件属性是M、MI的文档） PL、SA：rw 其他已经授权的用户：r Building Build版本（含代码、配置、数据库） Admin用户：rw 其他已经授权的用户：r alpha 内部测试版本（含代码、配置、数据库、运行） Admin用户：rw 其他已经授权的用户：r beta 用户测试版本(运行环境) Admin用户：rw 其他已经授权的用户：r Demo 演示版本（运行环境） Admin用户：rw 其他已经授权的用户：r 版本控制级别 高 严格控制，PM、PL才有版本的控制权； 中 一般控制，PL、SA及以上岗位有版本的控制权； 低 宽松控制，SA、AP及以上岗位有版本的控制权。 版本控制目录的权限设置 由PM、PL决定 依据项目初期、中期、后期或实际情况，将调整各用户访问目录的读写权限； 通常项目到了中后期，版本目录权限控制将往高调整。 测试团队的基线版本 基线版本是可运行的基础版本； 基线版本正确后构造在目录building/qilin1.0/； 基线版本后的测试版本号,依次为1.1、1.2、……; 所有测试版本,均异机明码备份一份、二进制的subversion版本备份一份。 版本提交流程 版本提交是指：程序员或SA把程序代码、配置脚本、数据库表定义脚本、数据库表基础数据等，提交给测试团队building； 版本控制级别为“低”的提交流程： 测试团队确认building目录已经备份； 临时解开building目录权限； SA、AP提交代码、配置、数据库等； 测试团队building；如果building有问题重复第三步； Building正确后，恢复目录权限 版本控制级别为“中”的提交流程： PL或SA才有权提交，或直接指导AP提交； 测试团队确认building目录已经备份； 临时解开building目录权限； 提交代码、配置、数据库等； 测试团队build