软件配置管理（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解决方案需要足够灵活，以便允许整个团队使用的是相同的代码，或者允许个别团队成员使用"专用"的代码分支。当需要专用分支时，系统就需要能够控制那些专用分支和项目集成区域之间的变更流。
　　目前软件的复用很重要，因为它可以降低成本。因此，如果能够实现一种"食物链"的开发方法其价值不可估量。这种方法是开发团队何时生成打算被该项目的其他团队使用的可交付工件。这样的组件应该只能被它的制造者更改。
　　如果正确理解和实现，这些特性能创建一个受控的开发环境，从而使开发人员的工具更具生产力，并且生成更具预测性的项目日程安排。
　　业务价值：
　　软件复用对于降低成本很重要。你需要设置实现这个目标以及其他目标的策略。该上下文中的控制是关于计划如何工作以及建立这些规则的适当实施。有多少伟大的成功是在没有计划、过程或者路标的情况下获得的呢？不是很多。
　　控制看上去是一个缓慢的过程，但是它创建了更好实现指定结果的顺序。它与决定行人走人行道类似。如果我们都同意行人走人行道，卡车走机动车道，那么我们就不会被卡车撞。这种计划和控制就是很好的业务。   
　　可审计性
　　开发软件是一个迭代的复杂过程，需要能理解发生的所有事情的敏锐眼光。它与我们对落地大座钟的感觉类似。从外面看，指针移动，闹钟报时，你就能知道时间。但是在内部，存在着连续的移动。齿轮啮合，按照不同的速率转动。特殊的齿轮经过校正，可以精确到毫秒。所有部件协调起来实现了绝对精确--从外部看来如此简单的和谐。
　　软件与此类似，除了一点不同--它本质上要复杂的多。并且在所有的活动中，你有时必须问个究竟。
　　这就是可审计性存在的理由。可审计性指的是在任何时候询问关于软件发布的特定版本或配置的who、what、when和where问题的能力。它还必须能够强调版本之间的区别。构建工程师、经理和开发人员必须随时回答诸如下面的常见查询：
　　. 组件 foo.y 根据最新需求更改了吗？ 
　　. 谁对 3.2.4 版的第 10249 行做了变更？ 
　　. 在修订版中所有迫切的bug都得到了修复吗，以及谁将它们登入？ 
　　答案对于平稳解决像构建脚本或包含文件中的错误至关重要。手工查找信息消耗宝贵的时间。确实，因为不能向SCM系统询问这些关键信息而感到气馁的开发人员可能只是让构建和测试团队挑选出东西--从而浪费了更多的时间，并极大地降低了项目效率。

上一页12下一页