软件配置管理（SCM）是软件开发的幕后英雄，为什么这么说？首先，在以最高效率运行时，SCM 解决方案很难被看到。它们对于用户应该是透明的，让开发人员自由地编码，而无需难以驾驭的过程。第二，很少有人会注意到 SCM，除非它被不必要地插入或者被破坏。所以它执行的越好，你就越少听到过它，或者意识到它。

软件配置管理（SCM）是软件开发的幕后英雄

为什么这么说？首先，在以最高效率运行时，SCM 解决方案很难被看到。它们对于用户应该是透明的，让开发人员自由地编码，而无需难以驾驭的过程。第二，很少有人会注意到 SCM，除非它被不必要地插入或者被破坏。所以它执行的越好，你就越少听到过它，或者意识到它。

SCM 成为英雄是因为良好的软件配置管理产生了正的投资回报（ROI）。实际上，它通过提高团队生产力和保护你的项目资产远离灾难（不管大小），使你获得了良好的经济效益。

是的，它处在幕后，但是项目经理和 CIO 们正在注意到它。他们意识到了良好的 SCM 为项目和公司提供的业务价值。

SCM 如何转化为业务价值？

• 更快的开发意味着更快的投放市场。
• 更高的质量意味着减少了修复错误的时间。
• 更高的可靠性转化为更高的生产力。

ROI 研究提供了有说服力的证据，即正确配置的软件配置管理解决方案可以提高过程和控制中的效率。这些效率将减少手工任务，并在项目中节省无数的时间。你越能优化项目的执行，就越能为公司带来更多价值。

在目前给定的开发复杂程度下，有很多通过SCM增进开发效果的方法。但是，我将它们概括为良好的SCM系统应该拥有的七种属性。一旦被正确理解和管理，这七个属性就会极大地影响你的底线。

这些属性是：

1、安全性
2、稳定性
3、控制
4、可审计性
5、可复制性
6、可跟踪性
7、可伸缩性

在我以前的版本工程师和 SCM 顾问工作中，以及现在的工作中，我都为客户提供如何从软件配置管理（SCM）中获得最大收益的建议。这七大重要的 SCM 功能--安全性、稳定性、控制、可审计性、可复制性、可跟踪性和可伸缩性--是成功进行软件配置管理的关键需求。所以让我们对它们做进一步讨论。

安全性

所有 SCM 系统的首要目标就是保证项目资产（比如，设计模型、源代码、测试用例、文档等）免遭毁坏、无意的破坏、未授权的访问，甚至灾难。这需要两件东西：

安全访问--可以查看或更改项目资产的人只能是被明确授权这样做的人。

可靠的恢复--在未授权用户犯错误时（比如以外删除或覆盖源代码文件）恢复丢失工作的能力。

你不能低估 SCM 安全特性的业务价值。安全特性是软件开发过程中风险转移关键领域的基础。如果不能防止有意或无意的破坏，代码和其他关键项目资产将随时面临不可接受的风险。这种潜在的丢失可能暂时削弱一个项目，更糟的是可能使项目偏离轨道数月，甚至扼杀了该项目。

作为这方面的例子，很多 SCM 系统没有提供再现过去配置的简单方法。这迫使勤奋的开发团队依靠其他方法实现这种功能，比如在出现关键项目里程碑时向磁带或其他备份介质上编写特定的配置。

但是，这不能防止有人无意地恢复了过去的配置而覆盖了现有工作。当然也不允许再现与这些关键项目里程碑不对应的配置。

业务价值：

在你的开发环境中创建安全性意味着有能力阻止未授权用户，并且能够快速恢复被破坏或覆盖的代码。简而言之，它是关键业务资产的保护神。当你不用手工重新创建你软件系统的特定配置，而是可以从知识库中直接取用时，你就节省了不少时间。

稳定性

稳定的开发环境，不管对于开发团队还是个别开发人员来说都是不可缺少的。真正的稳定性具如下两个必要元素：

有保证的稳定工作区域--很多 SCM 系统可能在他人检入新代码时，破坏了个别人工作区域的稳定性。开发人员应该能够将未完成的工作留到第二天（或者未来的任意时间）再做，因为知道他们桌面上的数据未经他们允许不会被改变。

对向工作区域中引进哪些新代码（这些代码可能是最不稳定的）以及何时引进的个别控制--比如，一个独自工作了数周的开发人员应该首先对他的环境有足够的控制，以决定何时向他的环境中以及团队的环境中检入新代码（潜在的不稳定因素）。

除此之外，开发人员还应该能够逐渐更新他的环境，以评估稳定性水平。另一种方法是同时完成这一切，但是会潜在地向开发人员工作区和项目中引入广泛分布的不稳定性。这种级别的控制（选择什么时候向个别工作区引进什么东西的能力）显著地降低了项目风险。

业务价值：

当你向开发人员的环境中引入了不稳定因素时，可能导致向下的螺旋效应，从而引起开发人员和开发团队生产力的急剧下降。这对士气也有负面影响，并且导致进度延迟和质量问题。维护稳定的环境消除了这些问题，并增加了额外的价值。

控制

所有 SCM 系统的一个主要角色就是帮助管理开发生命周期中的变更。系统必须在对项目的总体工作流进行适当的控制和不对个体项目成员施加令人不快的限制之间做出权衡。

目前开发人员通常位于不同的办公室、不同的国家，不同的时区。试图将各个开发团队的工作集成起来需要一个能够控制以下东西的系统：

• 谁在致力于变更请求。
• 变更如何从开发流向集成。
• 谁可以使用特定的开发流。

另一方面，SCM 解决方案需要足够灵活，以便允许整个团队使用的是相同的代码，或者允许个别团队成员使用"专用"的代码分支。当需要专用分支时，系统就需要能够控制那些专用分支和项目集成区域之间的变更流。

目前软件的复用很重要，因为它可以降低成本。因此，如果能够实现一种"食物链"的开发方法其价值不可估量。这种方法是开发团队何时生成打算被该项目的其他团队使用的可交付工件。这样的组件应该只能被它的制造者更改。

如果正确理解和实现，这些特性能创建一个受控的开发环境，从而使开发人员的工具更具生产力，并且生成更具预测性的项目日程安排。

业务价值：

软件复用对于降低成本很重要。你需要设置实现这个目标以及其他目标的策略。该上下文中的控制是关于计划如何工作以及建立这些规则的适当实施。有多少伟大的成功是在没有计划、过程或者路标的情况下获得的呢？不是很多。

控制看上去是一个缓慢的过程，但是它创建了更好实现指定结果的顺序。它与决定行人走人行道类似。如果我们都同意行人走人行道，卡车走机动车道，那么我们就不会被卡车撞。这种计划和控制就是很好的业务。

可审计性

开发软件是一个迭代的复杂过程，需要能理解发生的所有事情的敏锐眼光。它与我们对落地大座钟的感觉类似。从外面看，指针移动，闹钟报时，你就能知道时间。但是在内部，存在着连续的移动。齿轮啮合，按照不同的速率转动。特殊的齿轮经过校正，可以精确到毫秒。所有部件协调起来实现了绝对精确--从外部看来如此简单的和谐。

软件与此类似，除了一点不同--它本质上要复杂的多。并且在所有的活动中，你有时必须问个究竟。

这就是可审计性存在的理由。可审计性指的是在任何时候询问关于软件发布的特定版本或配置的谁、什么、何时和何地问题的能力。它还必须能够强调版本之间的区别。构建工程师、经理和开发人员必须随时回答诸如下面的常见查询：

• 组件 foo.y 根据最新需求更改了吗？
• 谁对 3.2.4 版的第 10249 行做了变更？
• 在修订版中所有迫切的 bug 都得到了修复吗，以及谁将它们登入？

答案对于平稳解决像构建脚本或包含文件中的错误至关重要。手工查找信息消耗宝贵的时间。确实，因为不能向 SCM 系统询问这些关键信息而感到气馁的开发人员可能只是让构建和测试团队挑选出东西--从而浪费了更多的时间，并极大地降低了项目效率。

业务价值：

可审计性需要 SCM 系统跟踪和记录有关变更的元数据（关于数据的数据）。很重要的是，它还允许你查询数据库，以轻松找到答案。可审计性可将寻找答案的时间从数天减少到数秒。假定每天六个问题，乘以每个问题节省的时间，你就会意识到这将带来多么大的业务价值啊！

可复制性

在项目过程中发生的很多变更中，并不是所有的都比原来好。有时候，前面的版本比后面的要好。你必须能够快速复制出前面的配置，以便恢复到项目的之前状态。

可复制性就像是航拍一样。它代表了截然不同的时间，以及项目详细、广泛的视图。

软件开发上下文中的可复制性需要：

• 复制整个开发环境的配置的能力，包括项目生命周期中任何阶段的工具、测试和文档。这很关键，但是从这方面来说很少有产品能完全做到这一点。
• 不但自动重新创建构建中使用的文件，还能自动创建目录结构和整个名称空间的能力。

通常，更早版本的目录结构被识别--文件或子目录名称发生改变，大型目录被分割成更小的目录，并且文件被移动。重新创建早期版本目录结构的能力被称为名字空间版本化。SCM 必须为名字空间版本化提供一种机制，而不只是为文件版本化提供。

比如，它对于将代码基及时回退到不是特别显眼但是体现了更好的代码版本的时刻很有用。回退需要可复制性。根据回退作用域的不同，它可能需要只有名字空间版本化才能提供的大量细节。

业务价值：

将项目回退到一个里程碑或者任意时刻方面的可复制性可能只产生周期性的价值。但是当例行使用以保证正在构建的同时已经过测试时，它在降低风险方面的价值不可估量。

可复制性类似于版本控制--允许你在一个构建中复制精确的文件版本和每个文件的配置。花费项目组数天或数周时间重新构建的东西可能在几秒内发生。

可跟踪性

很多 SCM 系统提供了某种程度的可跟踪性。可跟踪性的综合定义包括如下能力：

• 按照能让 SCM 系统轻易重新创建重新构建、测试和/或运行该版本所需的开发环境（代码、文档、用例等）的方式，标识已部署产品的版本。
• 从特定的软件版本回溯到为实现该版本而实施的变更请求和/或需求。顺便说一句，这种功能目前在涉及项目代理的项目上是必须的，比如 FDA、FAA 或 DoD，所有这些都在它们的投标请求中构建了可跟踪性需求。

有了可跟踪性特性，支持工程师就知道重新创建客户系统的精确配置所需的所有信息，并可以回答该问题："为什么软件这样做"？

业务价值

与可审计性类似，可跟踪性是确定你在项目中位置的一种方法。如果给定了软件开发的复杂性以及涉及的高风险，那么可跟踪性就是必要的。和可审计性一样，可跟踪性节省了手动记录元数据的时间。

可伸缩性

作为整个开发平台的基础，SCM 系统必须支持任何范围的项目。也即是说，它必须伸缩，以自始至终支持大型团队，但是它又不能对小团队带来负担。

可伸缩的 SCM 系统应该：

• 在需要少许控制时是可配置和起作用的。否则团队成员将花费时间与复杂的SCM流程纠缠。小项目不能负担繁重的管理。
• 可用于管理增长。在小项目成功方面 SCM 的可伸缩性变得越来越重要。小项目通常演变为大项目，需要像平行开发这样的高级功能。SCM 解决方案需要能管理这种增长。
• 能够支持地理上分散的团队、远距离工作者和/或外包团队成员。异地投稿者的存在为 SCM 环境添加了压力，因为它需要协调和管理分布式的协作，不管集中办理还是通过复制均可。可伸缩性还暗示了应该实现合理的性能标准。对 SCM 系统不断提高的要求不应该损害可靠性或者影响基本操作。

业务价值：

在你每次雇佣新员工时，必须将业务移交给一个更大的部门。在每次开始一个大项目时，必须购买新的 SCM 解决方案。它可能耗费时间、金钱，并导致极度的烦恼和不舒服。你的 SCM 解决方案如果不可伸缩会影响很多人。

好的 SCM 就是好的业务健壮的 SCM 系统为使用项目资产创建了安全和可预测的环境。它使得个别团体更容易坚持已建立的流程以及"做正确的事情"，同时使得更难做错误的事情。

有效的 SCM 将：

• 为开发管理提供了关键的状态信息和数据。
• 自动完成日常的构建和版本化任务，并提供了对文件和版本信息的快速访问。
• 支持根据前面的文件版本对缺陷和增强进行端到端的跟踪。
• 足够敏捷和健壮，可以使控制轻易地适应不断变化的项目条件。
• 使得做正确的事情很容易，犯错很困难。

这些好处的总数目相当于更有效的软件项目管理--降低了底线成本，并提高了业务价值。

在过去的数年中，我曾帮助很多公司解决他们的软件配置解决方案。我看到了令人敬畏和令人恐惧的事情，并且可能是之间的所有事情。

但是不管情况如何，一旦客户和我理解了一个 SCM 解决方案如何帮助他们的软件开发（七个 SCM 属性），我们就能够实现提高生产力的计划。没有两个计划是相同的，因为没有哪两个业务是相同的。但是这七个属性可作为有关 SCM 实践的会话的上下文。一旦使用，这些最佳实践就将转变你团队构建软件的方式，并且对你的总体生产力产生积极影响。

SCM 的业务价值已得到证实--不管是传闻还是实际经历。好的 SCM 就有很大不同。你可以依靠它！今天的 SCM 是软件开发的无名英雄。但是在很久以前，随着越来越多的项目经理和 CIO 为之扬名，它很快成为了 MVP（最有价值产品）。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。