精细化的访问控制（一）

基本信息

用户单位：某通讯设备制造企业
用户规模：200人以上
组织过程水平：中等
CMMI评审等级：3级
Subversion使用时间：2年

客户需求

该公司对Subversion访问控制的需求主要包括

精细化的授权体系

1、多重线索的授权体系：

根据公司实际需求，一个人的需求由以下三条线索决定：

1. 个人在公司中的角色，如总经理、配置管理员、系统管理员等
2. 个人在项目中的角色，如项目经理，程序员，测试人员等
3. 个人特定的权限

权限的设定遵循以下逻辑

1. 对于某个文件或目录的授权状态分为授权、未授权和禁止授权三种方式
2. 下级文件或目录如果未授权（处于未授权状态），则遵循其上级目录（如其上级目录也处于未授权状态，则逐级上索）
3. 不同线索的授权发生重叠时，相同的授权采用“与”逻辑操作，禁止授权和授权发生冲突时遵循“禁止授权”操作

另外对控制的粒度

1. 在提交操作中要能区分修改、创建及删除操作
2. 操作的对象要能区分文件和目录
3. 特别的排除逻辑

问题解析

Subversion的访问控制技术上有通常有两种实现途径，一是访问控制文件（一个纯文本文件），以路径为线索的访问控制，其控制内容为读和写，支持用户和用户组两种授权模式。而是钩子（主要是Pre-Commit）。

其中，访问控制文件是最简单和直观的实现方式，在需求相对简单和数据量较小的情况下可以通过直接修改该文件来实现访问控制，但对于大数据量和较为复杂的控制逻辑，实现起来就非常困难了——因为靠手工去维护一个频繁变更且条目众多的文本文件是非常不现实的。

钩子也是一种相对简易的实现方式，根据Subversion本身提供的规则，其可以处理比访问控制文件负责的多的访问控制逻辑，但其也有一定的局限性，如只能处理会触发钩子的操作，而对不能触发钩子的操作，如CheckOut则无法进行控制。

我们的解决方案

我们的解决方案如下图所示：

如上图所示，所有的访问请求分为读以及读以外的操作两部分，读操作通过授权控制文件来进行控制（授权控制文件的内容由系统根据各种授权信息自动生成并实时的自动更新，从而避免了相关手工作业可能导致的错误），而读以外的所有操作则通过钩子（Pre-Commit，Pre-Lock等）向规则验证服务（Service）发送验证请求，并通过验证规则对其进行验证，然后将验证被允许的访问发生给服务器上的配置库，而验证拒绝的访问请求则直接返回错误。

精细化的访问控制（二）

基本信息

用户单位：某大型软件企业
用户规模：500人以上
组织过程水平：中等
CMMI评审等级：3级
Subversion使用时间：2年

客户需求

该公司对Subversion访问控制的需求主要包括

1、精细化的授权体系

其相关需求和上一案例：精细化的访问控制（一）基本相同

2、特殊的访问控制需求

a、对IP来源的控制，即只允许若干特定IP段的访问来源进行访问

b、对访问时间的控制，即只允许若干时间段内进行访问

c、上述二点需求可以根据不同的用户、项目及角色信息等进行设定

问题解析

该客户的第一点需求已经在上一案例中很好的解决了，但第二点需求则无法用访问控制文件+钩子的方式来进行控制，因为对于访问的IP来源的控制这两种技术手段都无能为力，而至于对访问时间的控制虽然钩子可以比较好的实现，但访问控制文件的实时更新（需随着时间、用户等信息进行自动更新）显然又需要在服务器端添加一个系统服务——显然这不是个好方法。

因此，需要在上述两种技术手段之外寻找途径。好在用户的Subversion是通过在Apache服务器来部署的，所以可以通过添加额外的Apache模组来实现相关的控制。 相对来说，这是一种较为底层的实现方式，理论上可以实现任何的访问控制，所以添加了Apache模组后，访问控制文件和钩子都可以不再使用，而访问的效率也可以因此有所提高。

我们的解决方案

我们提供的解决方案如下图所示：

如上图所示：所有的访问请求都被附加的Apache模组截获，并由其向规则验证服务（Service）发送验证请求，并通过验证规则对其进行验证（验证的内容可以包括IP来源和系统时间），然后将验证被允许的访问发生给服务器上的配置库，而验证拒绝的访问请求则直接返回错误。

自动构建与发布

基本信息

用户单位：某大型通讯企业
用户规模：500人以上
组织过程水平：良
CMMI评审等级：4级
Subversion使用时间：1年

客户需求

该公司对构建及发布相关的需求主要包括

1、每日构建——用于构建内部发布版本。

2、大版本的正式发布——包括完整的版本信息、历史版本及缺陷列表。

3、补丁的发布——频繁的补丁发布（大部分补丁需直接提供给客户现场），补丁的来源有两个：一是内部发布，二是对客户所报缺陷的修复。此外，在客户现场的技术人员需要能够直接通过网络获取相关的补丁程序。

问题解析

Subversion本身作为一个版本管理系统并不提供对构建及发布的支持，所以除了可以利用其提供最新版本检出的功能外其他的相关需求都需要衍生开发。

我们的解决方案

我们所提供的解决方案如下图所示：

1、对构建脚本的进行管理，用以维护任意多个适用于不同构建需求的构建脚本

2、通过构建引擎实现构建过程的自动化并自动输出构建日志

3、对于正式发布的版本，在成功发布的同时自动输出发布包括，发布报告除了发布相关信息外，还包含了修订历史及缺陷列表。

4、对于补丁的发布，则直接发布至公司的FTP服务器，然后通过一个专门的发布门户（Release Portal）供客户现场的工作人员获取其所需的相关补丁。该门户除了可对获取权限进行控制外，还可接收客户现场人员提交的缺陷并将其转至相关开发部门。

以只读方式实现对配置库内容的调阅

基本信息

用户单位：某应用软件研发企业
用户规模：200人以上
组织过程水平：中等
CMMI评审等级：无
Subversion使用时间：2年

客户需求

由于公司的客户为军工企业，相关资料（主要是设计文档等技术资料）对保密具有较高的要求，具体到实际的使用需求就是Subversion版本库中的部分内容（以MS Office文档为主）在被开发人员调阅的时候只能被其读，但不允许以任何方式复制文档的任何内容！

问题解析

Subversion本身提供的所谓“读”权限只能提供对“检出”的控制，如果授予“读”的权限就意味着用户可以将被授权的文件检出或导出（下载）到本地，因此用Subversion本身的“读”权限显然是无法满足客户要求的。

通过分析，可以将客户的需求归纳为以下几点：

a、需增加额外的“浏览”权限控制

b、用户不能用Office程序直接阅读文档（因为可以被保存和复制）

c、阅读的时候需要屏蔽包括拷屏在内的一切复制手段

我们的解决方案

我们所提供的解决方案如下图所示：

如上图所示：首先，系统提供了独立于读、写等权限以外的“调阅”权限设置。当用户对相关文档提出“调阅”请求后，系统会根据用户的相关授权信息（包括项目、用户及角色等相关授权信息）对验证请求进行核准，被核准通过的验证会在服务器端将相关文件检出一个临时的工作拷贝，然后在客户端通过ActiveX控件进行调阅。

由于客户端在调阅的时候是通过ActiveX控件使用浏览器实现的远程调阅，相关的文档在客户端本地并没有保存任何拷贝，而ActiveX控件本身屏蔽了所有复制及保存的功能（包括拷屏），因此用户在客户端只能浏览而不能进行任何其他操作。

客户现场模式的分布式开发

基本信息

用户单位：某应用软件研发企业
用户规模：100人以上
组织过程水平：中等
CMMI评审等级：无
Subversion使用时间：1年

客户需求

由于公司每次向新客户提交软件的时候都需要派出一个小规模的团队到客户现场进行一段时间的软件定制和维护。此外，老客户系统的重大升级和功能扩展也需要一个小团队在客户现场进行一段时间的开发。因此，异地开发的配置管理就是一个比较突出的问题了。

虽然SVN本身提供了通过Http协议进行远程访问的能力，但出于安全的考虑，作为存有公司核心资产（源代码）的配置库在物理上和外部公共网络是相隔离的，所以必须采用分布式的管理模式。相关的具体需求可以归纳为：

1、需要从主配置库中分离部分内容创建用于在异地开发的远程配置库

2、远程配置库的访问权限能够直接从主配置库中直接获取

3、可以对远程配置库进行单独的授权控制和管理

4、当派出团队回到公司总部时需要对两个配置库的内容进行同步

5、派出团队在异地时也需要用非在线的方式（如邮件、即时通信工具、FTP等）对两个配置库进行数据的同步。

问题解析

Subversion作为一种集中式管理的版本管理系统，本身并不支持分布式的开发管理，所以需要一些额外的技术手段。目前唯一支持SVN的分布式版本管理系统是SVK——一款基于脚本实现的开源软件。但该软件除了在使用上较为繁琐外，并不能满足用户对访问控制及离线同步等方面的要求。

同时，根据分布式开发模式的特点，适合采用“远程代码线”的分支结构模式。因此，最为可行的解决方案应该是在“远程代码线”的模式的基础上通过技术上的一定扩展从而实现用户的所有相关需求。

我们的解决方案

我们所提供的解决方案如下图所示：

首先，在主版本库中采用远程代码线的分支结构模式，并通过远程代码线创建客户现场所使用的远程版本库，然后通过在线和离线两种方式进行数据的同步。
在这种操作模式下，为了保证数据的完整性和一致性，我们采用了若干技术手段提供了如下的约束机制：

a、主版本库中的远程代码线在下一次同步操作前一直处于冻结状态，不允许进行任何检入操作。

b、远程版本库中的主代码线、主版本库中的远程代码线以及主版本库中的主代码线三者的同步必须按照一定的顺序完成一个周期（如上图所示）

另外，通过建立远程开发团队的相关信息，在创建远程版本库的时候，将继承主版本库的团队成员相关的访问控制权限，并提供对远程版本库的访问控制进行单独定义的机制。

配置管理和缺陷跟踪的整合

基本信息

用户单位：某制造业软件研发企业
用户规模：100人以上
组织过程水平：中等
CMMI评审等级：3级
Subversion使用时间：2年

客户需求

由于公司开发的产品在交付每个不同客户的时候都进行了较多的定制开发，所以当项目进入开发后期以及交付客户后的初期，缺陷的修复便成了开发团队的一个主要工作。根据公司制定的相关流程，在相关软件已经提交客户后，为了保证开发主线上代码质量的稳定性，因此所有的缺陷都必须在独立任务分支上完成，验证通过后由专人负责进行相关的合并操作。

公司原先采用开源的缺陷跟踪工具（BugZilla）来对缺陷进行跟踪和管理，从该软件本身的功能上来说基本能够满足缺陷跟踪的所有需求。但由于该软件和Subversion的操作无法进行整合，版本库内大量的操作（如创建任务分支、授权及合并操作等）都需要手工来完成，在缺陷提交相对频繁的时候，无论是对相关人员的工作量还是相关操作的准确性都是一个不小的考验。

另外，对于部分相关的人员（如负责质量保证的QA等）希望以在线的方式（而非检出到本地）对缺陷修复的相关代码进行审查，这也是BugZilla当前无法完成的。

综上所述，客户对缺陷跟踪的相关需求可以归纳为：

1、需要从主配置库中分离部分内容创建用于在异地开发的远程配置库

2、远程配置库的访问权限能够直接从主配置库中直接获取

3、可以对远程配置库进行单独的授权控制和管理

4、当派出团队回到公司总部时需要对两个配置库的内容进行同步

5、派出团队在异地时也需要用非在线的方式（如邮件、即时通信工具、FTP等）对两个配置库进行数据的同步。

问题解析

从客户的相关需求可以得出以下结论，BugZilla对于缺陷跟踪本身是可以满足要求的，而不足之处主要的是在和Subversion的操作整合上，由于Bugzilla本身是一个独立的软件，要通过对其进行扩展使其和Subversion完全整合无疑是一个非常困难的工作。因此，结合各种因素和现有的资源，我们最终选择了直接开发一个和Subversion完全整合的缺陷跟踪系统，从而来彻底满足客户的相关需求。

我们的解决方案

我们所提供的解决方案如下图所示：

首先，提供一套功能和BugZilla相当的缺陷管理系统，在和Subversion的整合方面提供以下功能：

a、在分配任务的时候自动创建相应的任务分支并自动完成相关的授权。

b、缺陷完成验证后，自动由任务分支向主开发线合并代码并（在合并成功后）关闭任务分支

c、提供以在线方式（通过浏览器）查看缺陷相关的每个提交版本的代码内容以及相关的差异比较，并对该调阅功能提供授权控制。

合并跟踪

基本信息

用户单位：某制造业软件研发企业
用户规模：100人以上
组织过程水平：中等
CMMI评审等级：3级
Subversion使用时间：2年

客户需求

合并是并行开发中一个令人头疼的环节，众多的冲突和缺陷均源于此。在缺乏有效的合并跟踪的情况下，会导致众多的问题出现，相关的情况有很多种，以下是一个典型的场景：

由此可见，在持续的并行开发环境下，有效的合并跟踪机制是必不可少的。这种合并跟踪机制概括起来就是：当被跟踪的代码线（大多数情况下为开发主线）发生变更（如提交或合并）时，所有可能受到影响的相关分支/代码线应该被及时跟踪到并告知进行相关的同步操作。

问题解析

Subversion虽然在其重要升级版本1.5后提供了有限的合并跟踪功能，但该功能相对较弱，尚无法实现上述的跟踪机制。而要实现上述的跟踪机制，一个重要的前提就必须将分支/代码线的所有操作（包括创建、合并及更新等）置于受控状态。

我们的解决方案

我们所提供的解决方案如下图所示：

首先，通过系统底层的操作将非受控的分支/代码线操作屏蔽掉，所有代码线操作都必须在特定应用系统（SmartChangeEE）中完成，这样所有的分支/代码线都处于受控状态。如上图所示，分别演示了两种情况：

第一种情况：缺陷01源于代码线V1.0a，且属于V1.0a的特性部分，而不属于公共应用部分，因此其他代码线不包含该缺陷，所以缺陷修复后无需进行任何同步合并操作。

第二种情况：缺陷02源于主开发线，且属于公共应用部分，因此在V1.0a后面创建的代码线都应该包含有该缺陷，所以缺陷修复后在向主开发线合并后会自动从主开发线向V1.0b和V1.0c代码线进行代码同步操作，以自动修复这些代码线上存在的Bug