【IT168 技术文章】

    软件变更与配置管理（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 的挑战

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

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