中小型组织的源代码控制方法

目标读者

本指南为团队开发提供了适用于主开发人员、开发人员、测试团队成员和系统管理员的指南。如果您计划或目前正在参与基于团队的源代码控制项目，请阅读本指南。

您应该知道什么

要使用本指南来建立适合源代码控制的团队开发环境和开发流程，您必须具备使用源代码控制工具进行软件开发的一些经验。您还应该了解传统上与基于团队的软件开发项目相关的普遍问题和挑战。理想情况下，您应该具有使用源代码控制系统（如 Microsoft 的 Visual SourceSafe）的经验。您应该非常熟悉诸如固定（Pinning）、标记（Labeling）、分支（Branching）等功能的用途和用法。

注意：本指南重点介绍将 VSS 版本 6.0c（与 Visual Studio .NET 企业版附带的版本）作为源代码控制系统。然而，许多指导和讨论的流程同样适用于其他变更管理系统，其中许多可以直接集成到 Visual Studio .NET IDE 中。

引言

首先，我想指出的是，关于像源代码控制这样广泛的主题，现有的文章数量非常有限。另外，虽然这些概念和方法已经或多或少地被不知疲倦地讨论和同意，但似乎总是缺乏更易于理解和用户友好的文档。通过本文，我想征服，即使不能全部，至少是冰山一角。

摘自 Microsoft

"源代码控制在很大程度上是一种思考软件开发的方式，就像它本身是一种工具一样。它可以促进并行开发并实现开发隔离，但它无法保证两者。只有通过制定并贯彻一项战略，团队才能充分发挥源代码控制的潜力。"

我与源代码控制的缘分始于 4-5 年前，当时团队开发项目比单纯的项目更像一场噩梦。那时，我们评估了几款源代码控制工具，并最终选择了 Microsoft 的 Visual SourceSafe，因为它与 Microsoft 的开发工具集成方便。

虽然决定很迅速，但集成是另一回事。对于独立的 GUI 应用程序，集成正如 Microsoft 所宣传的那样——易如反掌。但对于基于 Web 的应用程序，则远非如此。

本文的重点更多地在于源代码控制的方法；集成问题及其解决方案未在此涵盖，您可以在我后续的文章中阅读到与 Microsoft Visual SourceSafe (VSS) 和 Microsoft Visual Interdev 的集成步骤和问题。但我之所以提到这些集成问题，是因为如果没有一个周密的策略；这些问题将是巨大的。

访问控制和角色分配

那么，切入正题，即中型应用程序的源代码控制方法。首先，我相信，作为任何工具进行源代码控制的规则；设置授权角色和提供权限是起点。

以下是基本角色及其应提供的权限的图表

角色	文件夹	读取	检出/检入	添加/重命名/删除	销毁
管理员（默认）	ALL	Y	Y	Y	Y
配置控制器	ALL	Y	Y	Y	Y
所有其他用户 （开发人员、QA 团队成员等）	开发	Y	Y	Y	Y
	质量保证	Y	N	N	N
	生产	Y	N	N	N
	归档/分支/文档	Y	N	N	N
发布控制器	生产	Y	Y	Y	Y
匿名用户	ALL	Y	N	N	N

主要角色

管理员

作为管理员，您的职责是使源代码控制数据库中的文件对客户尽可能有用。授予权限、创建用户等功能是您的职责。默认情况下，您对所有文件夹和项目都拥有完全权限。

配置控制器

作为配置控制器，您负责在项目中实施配置管理活动。

为了实现上述目标，您与源代码控制方法的交互最多。您必须确保已识别的软件工作产品的更改受到控制，并保持可配置代码的完整性。

发布控制器

作为发布控制器，您是配置控制器发布的源代码的保管者。您的职责是根据项目计划管理最终产品的发布，使其上线。

目录和文件夹结构

现在我们来看目录/文件夹结构（如上所示）——在 Visual SourceSafe 术语中也称为项目结构。以下是应该遵循的文件夹结构的示例。

在更详细的级别上，以下是结构的示例，其中包含一些样本项目。

Directories
- $/
   - 1 Development

       - 1 GUI Projects
        - 1 Visual Basic Projects
                + 1 XYZ Project
                + 2 ABC Project
                + 3 LMN Project
        + 2 PowerBuilder Projects

       - 2 Web Projects
            + 1 XYZ Project
            + 2 ABC Project
            + 3 LMN Project

    - 2 Quality Assurance
       - 1 GUI Projects
        - 1 Visual Basic Projects
            + 1 XYZ Project
            + 2 ABC Project
            + 3 LMN Project
        + 2 PowerBuilder Projects

       - 2 Web Projects
        + 1 XYZ Project
        + 2 ABC Project
        + 3 LMN Project

    + 3 Production
    + 4 Branches
    + 5 Documents & Archives

目录和文件夹结构（续）

我们来详细分析一下推荐该结构的原因。乍一看，您会发现文件夹在逻辑上分为六个主要区域——即

1. 开发

此文件夹将包含项目文件，并为所有相关开发人员提供完整的访问权限。此文件夹的主要目的是为开发人员提供一个受控的环境，让他们可以在其中根据需要检出、检入代码并进行修改。

您会注意到上图中的此文件夹进一步细分为源文件和 Web 文件。它们是开发人员实际使用的项目文件。这种逻辑划分不仅为开发人员提供了易于理解和使用的便利，而且还灵活地授予/撤销源代码控制的权限。

2. 质量保证

此文件夹只是 Development 文件夹的镜像。实际镜像，但有访问限制。此文件夹将包含 Development 文件夹中所有项目文件的共享。这些文件还将固定到可用于测试/质量保证的项目的最新版本。

此文件夹的目的是只允许配置控制器访问要分发给质量保证团队供其使用/测试的项目文件。如上所述，它们不会是实际的项目文件，而是 Development 文件夹的共享和固定版本。一旦在此文件夹中正确共享和固定了文件，配置控制器就可以分发最新版本或为相关团队提供对结构的只读访问。此外，开发人员可以独立于测试团队继续他们的开发。当发生检入/检出时，版本和历史信息仍会附加到所述文件。但是，由于固定过程，质量保证只能获得该文件的特定版本。

3. 生产

此文件夹也像一个万花筒，包含从 Development 文件夹共享的相同物理文件，并固定到生产服务器上的实际版本。一个显着的区别是，单个文件可以提供有关开发服务器上的版本（开发人员可修改）以及项目文件在使用该代码的生产环境中可供客户使用的版本的信息。

4. 分支

这是一个关键的文件夹，在源代码控制的模式化设计中起着重要的作用。此文件夹的目的最好通过示例来解释。

假设一个已分发到上述三个文件夹中的项目已上线并处于生产状态，但现在需要进行错误修复。还假设需要修复错误的那一部分模块已经在开发区域作为新版本发布的一部分进行开发。

简单来说：模块 A 在 Production 中固定为版本 2.0。在 Development 中，正在开发版本 3.0。版本 2.0 中存在一个错误，需要在此处修复，方法是将文件版本增加到 2.1。

在这种情况下，需要修改和测试文件，而不会回滚当前进行的版本 3.0 的更改。这时就用到了 Branches 文件夹。由于这个文件夹的存在，配置控制器可以将所述文件从 Production 文件夹共享并分支到 Branches 文件夹（将提供 Production 中固定的版本）。

现在可以将此文件交给开发人员进行错误修复（版本 2.1）。完成更改后，可以根据需要将文件移入质量保证和 Production。之后，修复了错误的版本 2.1 可以与 Development 中的版本 3.0 文件合并，以便包含所需的错误修复和增强功能。

5. 文档和归档

这些是自explanatory 的文件夹。文档和项目归档可以保存在这些相应的文件夹中。

最后

一旦您获得了授权并建立了上述推荐的文件夹结构，剩下的一切就是制定对于每个组织都至关重要且独特的策略和流程。下面提供了一个针对新项目和维护项目的建议流程。

对于维护项目

• 用户请求更改，并告知分配给该项目的配置控制器。
• 分配的开发人员将有权访问 Development 文件夹（如上方矩阵所示）来检出所需文件。
• 分配的开发人员负责在完成时添加检入注释。
• 分配的开发人员将更新并通知配置控制器在质量保证文件夹中固定/取消固定所需文件。
• 分配的开发人员还将与 UAT 团队协调 UAT 的开始。
• 收到 UAT 团队的确认后，分配的开发人员通知配置控制器在 Production 中固定/取消固定所需文件。

对于新项目

• 配置控制器必须在每个所需项目文件夹（Development、Quality Assurance 和 Production）中创建一个 Project 文件夹，同时提供访问权限。
• 为进行测试，配置控制器将在质量保证文件夹中共享/固定文件。
• 上线时，配置控制器将在 Production 文件夹中共享/固定文件。
• 上线后的进一步更改将遵循上述维护项目部分中提供的流程。