源代码控制 

    这是常常会忘记的重要敏捷配置管理的组件，并不是因为组成敏捷团队不使用源代码控制。它常常被忘记是因为大部分敏捷团队假定每个项目都会有一个源代码控制系统，并且每个项目都会正确的使用它。一般的源代码控制系统都会有许多部分，例如版本化、回滚、打标签以及合并等。但是更重要的是，源代码控制为全部项目团队或开发组织的代码行提供了可靠的记录位置 。这仅仅当每名程序员能够经常性的检入系统代码时才会发生。我的意思是至少一天一次。这时，项目能够了解在哪里找到当前系统。它不会由于不同的开发工作站，或位于不同地点的共享服务器造成支离破碎。当前系统（或仅仅几小时前）总是检查源代码控制系统。

    重申一下，仅仅因为项目或组织具有源代码控制系统不意味着系统支持敏捷配置管理方法。在我管理几个团队的客户端，两百名员工的开发组织使用企业级的源代码控制授权工具。但是系统却有重大的瑕疵：执行一次 check-in 要花费数小时！因此，团队仅仅在不得已的时候才做一次 check in -- 在发布到产品环境之前。一种普通的源代码控制系统对于一家大型企业十分有益（之后会做解释），但是仅仅限于程序员和团队能够以具有时效的方式检入/检出代码的情况。

    我将对源代码控制作最后的解释。团队不应该仅仅对所写代码进行版本控制；还必须对编译与测试代码的流程（或脚本）进行版本控制。如果团队需要先前的代码，那么就可以回溯到所需的构建和测试流程。

    构建自动化

    自动化构建是团队用以评估当前软件或系统稳定性的第一步。而且，自动化的构建还可以降低程序花费在不必要任务上的时间，并且减少了来自开发流程的瓶颈（也就是，团队依靠于一个构建人员或一个独立的构建团队），从而实现了对于改变的更迅速的响应。

    这一实践的目的是将构建流程简化为一个任何程序员都可以执行的点击一个按钮的 行为。这一行为应该包括相关系统的全部代码，不论程序员工作于什么组件或接口上。同时，系统必须能够快速编译。更快的工作站、增加的编辑和可选择的编译器可以使得编译时间更加短暂。对于程序员来说，写新代码的同时快速构建系统的能力具有许多好处。首先，它帮助程序员验证编码时设想的正确性 -- 例如，检验一个外部 API 是否如设想似的工作。其次，规则化的代码构建可以预防问题的发生。最后，它能够识别未知的很少通过本地构建显现的"远离"系统部分依赖关系。

    自动化的构建将会减少团队编辑和收集问题的时间。程序员不再需要等待数小时或者执行一组费劲的任务以确信新写的代码能够编译。取而代之的是，在程序员编写代码后不久，他就能够知道是否新代码与旧有代码集成到了一起。这表示编译与集成错误将会变得显而易见，且处理起来更迅速更容易。

    最后，自动化的构建对于更大系统更加重要。 大项目会继承或连接大量其它平台的系统，尤其是需要考虑有意义的联合构建流程的实际策略。在这种环境中要想获得较短的编译时间是极具挑战性的。文章的后面我将会探讨一些处理大系统构建的方法 -- 就是说，对于一个团队来说，编译与测试完整的系统并不是现实的。

    自动的移植及部署

    这是在自动构建之后的步骤。自动化的移植与部署行为的原因是为了精简与增强来自测试环境开发与生产环境的构建提升的可预见性。大量的问题往往来自首次引入系统测试、用户验收测试、在生产环境摸索的项目。在自动化移植中，团队可以将代码转入干净的"生产级" 环境，在那里可以执行自动化的单元和系统级测试。通过在接近生产环境下测试，团队可以在系统测试前识别出环境、集成和性能方面的问题。这样可使得团队更加熟悉实际的产品部署流程。最后，当自动化的实现了主要的产品部署流程时，就可以从公式中去除了人所犯的错误。

    另一个移植与部署的重点是这些行为由一个专职团队负责管理。将这些流程集成入项目团对每日的行为中能够为各个团队带来有效及时地平衡。无可否认的是，对于大型企业来说这是极具挑战性的，因为他们的规模、报告结构和多重地理范围的因素。下面我将会更深入的探讨这一问题的解决方案。

    测试自动化

    自动化的测试是了解当前系统是否达到准备发布状态的第一步。自动化测试应伴随系统中的全部新代码。除此之外，当老的、未测试的代码被改变的时候，程序员应为代码编写新的测试。最后，当在验收测试或产品中发现缺陷时，应记录这一测试以证明缺陷，并且这一新测试应加入到全部测试集合中以避免今后发生相同的问题。当系统中所有的单元测试全部通过后，程序员应当对其代码有信心，相信不会影响系统的其他部分。

    从敏捷的观点来看，自动化的单元级测试是构建流程的扩展。程序员每次运行构建流程并成功编译代码时，应遵循所有的应用单元测试。在敏捷配置管理环境中，损坏的单元测试与损坏的构建严重程度是一样的。这样小问题就不会扩展为大问题了。大问题（诸如全部程序停止工作）不会隐藏在后台。取而代之的是，团队可以在问题发生时定位，不断增长的单元测试集增加了准确监测错误的可能性。

    我要补充一点关于单元级和系统级测试的内容：明智的项目和企业会进行 测试数据管理。这样就使得测试数据很容易的创建、修改、维护（当系统数据结构发展变化时）、存储（在每次测试前）。当数据模型发生大的变化时，甚至是在某些情况下，当开发数据库被清理掉时，依赖于脆弱的以及被随意修改的数据结构的大量自动化测试集就可以得到迅速的调整。

    持续集成

    持续集成与源代码控制、自动化构建流程、值得信赖的自动化测试集共同保证了开发过程中系统的稳定性和系统性能。在持续集成的环境中，程序员需要编写代码，在工作站上运行构建和测试，一天内多次进行检入。同时，有一台构建机（或一组机器）用以编译整个系统，在类似于产品配置的干净的环境中运行所有测试。这种行为可通过手动或者自动的方式启动 -- 或者间隔固定的时间或者由程序员检查代码。当代码没有在干净的环境中通过构建和测试时，无论什么原因，都会在检查后提醒全体成员。大部分情况下，敏捷团队都不会允许任何人检入额外的代码，直到解决了问题。

    持续集成带来的好处是，它灌输了一种开发原则，不鼓励检入低质量的代码，且当问题发生时需要立刻解决。由于每天要进行多次代码检入 ，处于集成环境中的程序员很少或从不改变引起不稳定构建的代码。除此之外，如果遇到未完成的代码，团队的构建机制能够在几小时内记录它，而不是几天或几周。因此，程序员在中断代码前，不得不仔细考虑整体设计，甚至需要进行一些测试。这意味着处于持续集成环境中的程序员很少会在系统代码中直接进行试验，很少出现写了一半却忘记完成的函数，或是将系统组件遗忘在某处。当编写代码后立即监测出错误，解决问题所花费的时间往往少于几天或几周后才发现时所花费的时间。 这样，就保证了高质量的代码和更加迅速的发行周期。

    对于大系统的可扩展的敏捷配置管理

    大型企业经历过许多类似中小型项目遇到过的 CM 问题，还有部分附加的多系统、多项目、多初始属性的问题。例如，当小项目未监测出一个缺陷或者遇到了需要花费几个小时甚至几天才能解决的集成问题时，对于大型企业来说也许会花费几周的时间才能解决。相似的还有，对于小项目的源代码控制和版本的问题相比较于大型企业没有可依赖的配置管理系统时所遇到的系统回滚或多应用重新部署问题来说，简直是微不足道的。依据其规模与复杂度来说，适当的配置管理实践对于大企业是十分必要的。

    配置管理的敏捷方法能够帮助大企业定位配置管理问题，同时保持对客户需求变化、进化的业务环境、不断提高的技术的灵活性。除此之外，敏捷配置管理方法还能够帮助新项目重复使用现有系统与项目的构建流程加快构建与运行的脚步。

    本部分中，我们将会探讨在大型开发组织中使用敏捷实践的三个主题。第一，我们将探讨如何灵活的执行敏捷的 CM 流程为单个项目团队和大型开发组织带来好处。第二，如何在地点分散的企业中的分布式项目上使用敏捷配置管理方法。最后，企业如何通过深思熟虑的应用与流程集成加速软件交付周期，增强规模经济。