基于SVN的校级统一信息系统版本管理系统的设计与实现

2011-10-18钟文锋付小龙

中国教育信息化 2011年12期

关键词：校级开发人员分支

钟文锋，付小龙，杜炤

（清华大学计算机与信息管理中心，北京 100084）

基于SVN的校级统一信息系统版本管理系统的设计与实现

钟文锋，付小龙，杜炤

（清华大学计算机与信息管理中心，北京 100084）

清华大学服务于校级统一信息建设的版本管理系统，以开源工具为基础，实现了对软件系统研发版本的有效管理。版本管理系统采用先进的Subversion版本管理为基础平台，创新性地以基线加更新文件的版本管理模式，实现了清晰的更新管理、精确的版本定义和高效的自动编译，同时支持多分支并行开发，解决了清华大学在消除信息孤岛，建设校级统一信息系统的过程中，软件系统更新频繁、开发部署时间短、多系统并行开发整合等多方面困难，在清华大学的校园信息化建设实践中取得了良好的应用效果。

版本管理；基线；变更控制

一、系统背景

清华大学信息系统建设目前正处于建设全局性统一信息系统阶段。信息系统建设正由各业务部门的独立业务系统建设，转变为全局信息化的统一信息系统建设，信息整合成为现阶段重要工作内容。

在统一信息系统不断合并原业务子系统的过程中，原有基于CVS的版本管理方式遇到了很多挑战。首先是代码库访问权限不满足要求。随着统一信息系统规模的扩大，研发人员数量在增多。各个研发人员的角色和负责模块都不尽相同，需要对每个研发人员精确地设置不同的权限。而CVS的权限认证只能到文件夹，不能满足复杂权限控制的要求。其次是版本定义过程耗时过长。CVS在给系统打标签的过程中需要依次处理文件夹下的所有文件，耗费了大量的时间，在信息系统业务范围扩大、更新频繁的情况下，定义版本效率低下的缺点愈加明显。再次是缺少对版本和缺陷的检索和统计功能。CVS没有缺陷管理功能，研发团队无法查询缺陷的修改时间、是否已经发布等信息,也无法从宏观上通过报表得知系统的更新频率和开发人员的工作效果。这些原因都促使必须要升级版本管理系统以适应新的要求。

开源软件SVN(Subversion)是CVS的替代产品，它在CVS的基础上加强了对目录版本的控制，在安全性方面也有了改善。但SVN系统也存在某些限制，如整体复制的版本定义方式虽然能很快完成标签，但无法直接将某个文件标定到特定版本上，没有版本状态、缺陷管理功能等。因此在SVN基础上，清华大学自主开发了版本管理系统，通过增加完整的版本定义、编译、发布和缺陷记录、检索和统计等功能，实现对版本的全面高效管理。

二、系统功能

基于SVN的校级统一信息系统版本管理系统实现了以下功能：

1.记录、检索与统计缺陷

SVN提交文件时可以填写注释，在注释中记录修复的缺陷描述，但是这种缺陷记录方式只能以文件或目录为视角，列出历史上曾对文件或目录所做的修改及注释。这无法满足日常的以缺陷为视角的，查询某个缺陷修改时间和是否已经部署上线的要求。为此，版本管理系统设计了规范的编译申请入口，要求开发人员在提交编译申请的同时必需填写修改说明、部署说明等信息。这些申请信息以固定格式的归档邮件存储在服务器上。版本管理系统提供归档邮件搜索服务，研发人员可方便地搜索缺陷信息。在此基础上，版本管理系统还提供了缺陷统计功能，使得版本管理员能直观地了解各个系统的升级频率。

2.编译发布自动化

学校正在运行的信息系统差异很大，有基于Java的 B/S(Browser/Server)应用，也有基于 PowerBuilder的C/S(Client/Server)程序。甚至有些系统部分功能基于B/ S，部分功能基于C/S。不同系统的编译方式不一样，但都须经过版本定义、编译构建、文档记录和提交归档等发布过程。为此，对不同系统的版本发布过程做了分析，抽象出不同系统在发布过程中的相同操作，将这些共同的操作编写成自动编译发布脚本，并将系统间的区别记录至配置文件，在版本管理系统中实现了一个自动化工具，能通过加载不同配置文件的方式对构架差异悬殊的系统统一进行编译和发布。统一的自动化编译发布替代了繁琐的人工操作，显著提高了版本管理的工作效率。

3.产出全量安装包和增量补丁

版本管理编译的结果通常是整个系统的全量安装包，而全量安装包在运行环境上的部署必须先暂停相关系统的服务，这样会影响在线用户的正常使用。如果只是修改某个功能的代码，可通过部署增量补丁的方式避免暂停整个系统服务，避免影响用户的使用。版本管理系统在编译后同时产出全量安装包和增量补丁。系统管理员可以选择以全量或者增量方式部署更新。增量补丁部署方式无需重启整个系统，增加了部署的灵活性。

4.支持多分支并行开发

统一信息系统划分为多个子业务模块，具体的子业务模块由多位研发人员共同开发和维护。从单个子系统的角度，版本管理系统提供了共用的存储池，使得子系统内部的开发人员能共享彼此的工作成果并完成任务。从整个统一信息系统的角度，版本管理系统将这些子模块的修改彼此隔离，使之不相互影响。版本管理系统利用SVN的分支功能，通过给不同子业务系统开设不同分支的方式，支持了互不影响的并行开发。

三、关键技术

1.版本管理流程

规范且有效的流程是实现高效版本管理工作的前提。版本发布过程由版本管理员和开发人员共同完成。开发人员接到缺陷修改或者新功能开发任务后先确认子系统分支路径，并在分支上修改提交代码。在分支测试通过后，子系统开发人员将分支上的修改合并至主干。同时负责该模块的开发人员填写系统名称、修改说明、修改文件列表等信息，向版本管理系统提交版本发布申请。版本管理系统接收申请后通知版本管理员审核。版本管理员审批申请，将单个或多个申请划入本次要处理的版本中,并向版本管理系统发起自动工作命令。然后版本管理系统自动根据这些申请单定义新的版本基线，从SVN主干目录上取出源代码、编译增量全量包、生成说明文档、保存结果至共享目录，最后向版本管理员、研发人员和系统管理员发出编译发布任务结束通知。

2.基线加变更版本定义模型

基线加变更模型精确了定义版本,解决了子系统合并进度不一致和SVN整体复制定义基线之间的冲突。基线 (Baseline)是被明显标识和记录下来的源代码整体版本。绘制基线的工作就是定义版本的过程。这个过程可以是整体拷贝，也可以通过对某些修改过的文件打标签来完成。SVN通过整体复制定义基线，使用SVN能够按照某个时刻来界定版本，凡是在当前已提交到应用系统SVN主干目录的代码都会被编译。此外，如果有不希望将所有文件的最新修改都纳入新版本的情况，如两个子系统恰好同时合并分支至主干，其中一个分支已经合并结束且提交了编译申请，而另一个分支刚合并了一部分代码后发现有冲突，还需要手工合并和测试。这时定义的版本应该只包含已经合并结束分支的修改，如果简单地以时间划定版本，那新定义的版本将会错误地包含还未合并结束的分支上的修改。基线加变更模型解决了上述问题。

基线加变更模型：以旧基线和新更新文件的标识来定义新基线。新基线不再是简单地以某个时刻为边界来划定，而是在某条旧基线基础上，通过更新若干个新修改文件的节点作为新的基线。

如图所示，每一条垂直向下的实直线表示单个文件的时间轴，在这个时间轴上修改过文件的时刻画圈记录文件的变更。用一条水平虚线将各个文件某个时刻上的修改状态串连起来，这条虚线就是某个时刻源程序的一张快照，这就是基线。基线1表示系统初始时刻的版本，而基线3则表示软件几经修改后在当前时刻的版本。SVN通过整体复制的方式只能得到水平的基线，如果需要定义如基线2所示的版本，那使用SVN是无法直接操作的。基线加变更模型精确定义了版本：在B时刻将基线2定义为：在基线1的基础上接受文件1、文件2和文件4的最新修改。通过这种方式就可以将存储池内文件3在A时刻之后做的所有更新都忽略掉。