软件变更与配置管理（Software Change and Configuration Management，SCCM）考虑到软件开发的完整的生命周期，从变更最初的出现（请求、顾客增强、缺陷）一直到实现、构建、测试，以及最后软件发布的形成和同一父本中同一级别事件的管理。软件配置管理（Software Configuration Management，SCM）单纯关注软件中跟踪以及控制变更的过程（也因此成为 SCCM 的一个组件）。

        主要软件提供者使用了各种 SCCM 标准；然而，有效软件开发的基石是十分清晰且容易被人理解的。复合产品的存在能够使终端到终端的 SCCM 策略和过程有效地实施并能够日复一日地运行。不尽人如意的是，尽管当今有许多商业上可利用的免费的开源解决方案，但是仍然有许多公司继续使用电子表格和纸制系统。

        这篇文章讨论了 SCCM 市场的时间相对较近的变更问题，尤其是开源 SCM 产品 Subversion 的出现和成功。这篇文章的目标读者是 SCCM 决策者或构架师，这些能够定义和强制他们的组织中有这些过程和方针的人群。SCCM 产品财务经理也可能在这里找到他们的兴趣点。

软件变更和配置管理的历史

        源代码管理的基本原则最初由 Leon Pressor 教授在二十世纪六十年代记载。然而，首个较严肃的源代码管理解决方案直到二十世纪七十年代才出现。早期解决方案的创建是用来帮助个人管理个人空间的数量较少的文件；而现代工具却能够处理不同地区成千上万用户的更多种类更复杂的文件。

        在商业市场最大的变更之一是 1992 年 Atria Software 创建（随后被 Rational Software 收购，最后又被 IBM® 收购）。 ClearCase 与它的 Dynamic View 方法有着根本上的不同，最后导致IBM 开发了（并且购买）多种工具来管理终端到终端的软件开发过程，比如 IBM Rational®ClearQuest®， IBM Rational RequisitePro®， IBM Rational Build Forge®等等，并创建了更受欢迎的 SCM 方法， IBM Rational Unified Process®（RUP®）。

开源 SCM 的产生

        在当前经济下，每个组织都严格检查成本和查找可能较低成本的机会。同时开发人员想利用更少的过程，约束以及控制，而采用更简单更倾向于变更和配置管理的解决方案。Subversion 似乎能够满足 SCM 两方面的需求：没有许可成本，使用简单，学起来快速，并且对管理和维持的费用也不是很高。

        Subversion 确实有一些不足之处，在下面有具体的描述。更重要的是，Subversion 只是这个模式的一半，因为有效软件开发过程的另一个关键组件是变更管理。不管组织采用了哪个 SCM 策略，在众多案例简明的集成中最有价值的是在变更管理和版本控制工具之间。在一个变更管理工具中记录一个变更组合能够激活或者简化下面的能力：

使用一个标准过程进行持续集成
完全审计，跟踪，以及变更的详细历史
改进的通信和可视化贯穿整个组织（包括与客户的交流）
减少重复的工作——例如，相同的缺陷记录了很多次
自动化构建
自动且详细的发布版本通知
改进的测试——例如，每个请求都能够在发布版本之上进行特定的测试
遵从标准，比如 ISO 和 Sarbanes-Oxley，等等。
贯穿个体开发人员的管理和工作平横的问题
改良的报告和管理信息
尽管比较重要，但是通常认为能够简单地将软件和数据迁移到新的配置管理工具中，比如 Subversion，而不是将变更记录和过程移到一个新的变更管理工具中。

        开源软件的成功之处在于，毫无疑问，对传统的供应商方案来说有一定的作用。聪明的供应商比如 IBM 包含有开源解决方案，从而展开他们的产品并提供灵活且完整的功能开发环境，从而帮助他们满足软件开发组织的需求和请求。

SCCM 的挑战

        软件开发行业很清楚，变更和配置管理工具需要增加价值，提高软件质量，以及减少正在进行的成本，尤其是当开发小组逐渐变得庞大，且分布在不同的地方，需要开放更加复杂的产品时。要支持有效的软件开发，对这些工具来说它已经不能满足需独立存在的需求，他们需要集成的，灵活的，且能够适应的工具。

        在软件开放过程中所使用的所有工具中，最简单的集成是变更管理和配置管理之间的集成。此外，这种集成通常能够比其它的集成显示更多的利益 （对投资有最大的回报率）。

达成理想的 SCCM 解决方案

        任何一个 SCCM 系统的目标和关键请求都将随着单个用户的角色和任务而变化：

        从一个开发人员的角度来看，一个理想的 SCCM 解决方案必须

低调但是用起来很方便。
允许开发人员从事一个或者更多的活动。
赋予他们同时处理不止一个工作项目的能力，但是每个工作项目之间不能相互影响。
将同一次确定的变更记录的决定与其它变更记录联合起来。
使它们的代码能够被测试快速且方便的利用。
记录请求，使它们能够清晰地被理解（XP/Agile）或者定义（RUP）。
管理合并——例如，只合并那些实际上需要被集成的文件。
从一个专门为每个开发人员安排的“待办”列表的工作项开始做（也会允许这个管理人员优先选择工作条目）。
从一个开发团队领导或项目经理的角度来看，理想的 SCCM 解决方案必须

容易接受，评估，以及管理变更请求。
容易分配工作项目或者将一个工作拆分为适合小组或者目标交付的细节的更小的单元——例如，单个的工作可能需要被拆分为更小的单元，因为小组能力，时间限制，或者最初工作条目目标交付灵活度的原因。
区别哪些工作项目是完整的哪些是不完整的。
简单地为一个构建安排工作条目的测试和包含内容。
在各种不同的参差提供可视化，包括项目的状态，发布版本，组件，以及单个变更。这包括管理报告，比如小组成员中变更记录的分配，故障确定的平均时间，等等。
为单个开发人员的工作和进展提供可视化展示。
从一个业务分析师或经理的角度来看，理想的 SCCM 解决方案必须

允许他们请求或登记新的需求。
允许按照人员、成本，项目状态等运行报告。
使他们的客户保持与新发布版本进展的步伐一致。
实现一个供应商的 SCCM 解决方案

        所有的软件开发组织都希望 SCCM 解决方案是可扩展的、灵活的、适应能力强的，包罗万象的，并且能够从单一的即将适应现存开发方针和过程（以最低的可能成本为标准）的供应商那理想地提供整个工具（包括穿越测试和部署过程的请求定义）的组合。首先，整个驱动器要避免制造和维护集成，并且实施了可靠且经过考验的不会把集成拆分为新的版本更新解决方案。

        通常有这样一种说法“如果我们能够从一个供应商那购买我们自己的完善的开发环境，我们将成为最好的，”但是事实上这种情况很少发生。原因各种各样：每个产品的影响力都有它们自己最喜爱的供应商和产品；以前遗留下来的工具深深地扎根于组织中，使它们很难被迁移，随着时间的流逝新的工具进入这个市场，使用带有优于上个月“选择的工具”功能的现代技术。无论您怎样看它，对于大多数组织来说，实际上是一个软件开发产品的混合。

当今 SCCM 市场中供应商的解决方案

在当今软件开发的市场中，存在以下类型的供应商：

单个的旗舰产品，对于 SCCM 组合的其它方面有着潜在的集成
来自声称要无缝地进行集成供应商的多个高端产品
针对端到端 SCCM 的一个产品供应商解决方案
单一授权，包含全面的应用系统生命周期管理（Application Lifecycle Management，ALM）解决方案
在远程服务器上托管的解决方案；例如，软件即时服务（SaaS） 
        其实有很多种选择，任何一个决定都可能是令人吃惊的且十分困难的，每个都有它自己的优势和缺陷。如果您今天开始启动一个开放团队，选择上面的4和5听起来都是明显的选择。但是这些选项的问题是一个解决方案不能满足所有的问题。不可避免，许多组织将会认识到一个可选择的产品能更好地部分满足他们整个的解决方案，他们正为他们将不再使用地部分解决方案买单，或者说这个解决方案对他们的首选的开发技巧来说还不够灵活（XP，敏捷的，迭代的等等。）。这种“不确定” ALM 解决方案得真谛是，所有的客户都不同，因此转化为 ALM 系统中的功能越多，它就越难适应和自定义满足过程和每个客户的解决方案。最好的 ALM 解决方案十分轻巧，而且允许客户调整或者将它们与其它产品集成在一起。

        没有人愿意为每个软件开发项目使用一个不同的产品或者供应商，但是如果不从可利用的高端工具广泛的选择中尝试大量不同的产品就很难找到理想的工具。其中的挑战在于需要更紧密更干净的集成。理想的世界应该是，不管潜在的是什么样 SCM 产品，都有一个共同的界面。