|
这一实践的目的是将构建流程简化为一个任何程序员都可以执行的点击一个按钮的 行为。这一行为应该包括相关系统的全部代码，不论程序员工作于什么组件或接口上。同时，系统必须能够快速编译。更快的工作站、增加的编辑和可选择的编译器可以使得编译时间更加短暂。对于程序员来说，写新代码的同时快速构建系统的能力具有许多好处。首先，它帮助程序员验证编码时设想的正确性 -- 例如，检验一个外部 API 是否如设想似的工作。其次，规则化的代码构建可以预防问题的发生。最后，它能够识别未知的很少通过本地构建显现的"远离"系统部分依赖关系。项目管理者联盟
自动化的构建将会减少团队编辑和收集问题的时间。程序员不再需要等待数小时或者执行一组费劲的任务以确信新写的代码能够编译。取而代之的是，在程序员编写代码后不久，他就能够知道是否新代码与旧有代码集成到了一起。这表示编译与集成错误将会变得显而易见，且处理起来更迅速更容易。项目管理者联盟
最后，自动化的构建对于更大系统更加重要。 大项目会继承或连接大量其它平台的系统，尤其是需要考虑有意义的联合构建流程的实际策略。在这种环境中要想获得较短的编译时间是极具挑战性的。文章的后面我将会探讨一些处理大系统构建的方法 -- 就是说，对于一个团队来说，编译与测试完整的系统并不是现实的。项目管理者联盟
自动的移植及部署项目管理者联盟
这是在自动构建之后的步骤。自动化的移植与部署行为的原因是为了精简与增强来自测试环境开发与生产环境的构建提升的可预见性。大量的问题往往来自首次引入系统测试、用户验收测试、在生产环境摸索的项目。在自动化移植中，团队可以将代码转入干净的"生产级" 环境，在那里可以执行自动化的单元和系统级测试。通过在接近生产环境下测试，团队可以在系统测试前识别出环境、集成和性能方面的问题。这样可使得团队更加熟悉实际的产品部署流程。最后，当自动化的实现了主要的产品部署流程时，就可以从公式中去除了人所犯的错误。项目管理者联盟
另一个移植与部署的重点是这些行为由一个专职团队负责管理。将这些流程集成入项目团对每日的行为中能够为各个团队带来有效及时地平衡。无可否认的是，对于大型企业来说这是极具挑战性的，因为他们的规模、报告结构和多重地理范围的因素。下面我将会更深入的探讨这一问题的解决方案。项目管理者联盟
测试自动化项目管理者联盟
自动化的测试是了解当前系统是否达到准备发布状态的第一步。自动化测试应伴随系统中的全部新代码。除此之外，当老的、未测试的代码被改变的时候，程序员应为代码编写新的测试。最后，当在验收测试或产品中发现缺陷时，应记录这一测试以证明缺陷，并且这一新测试应加入到全部测试集合中以避免今后发生相同的问题。当系统中所有的单元测试全部通过后，程序员应当对其代码有信心，相信不会影响系统的其他部分。www.mypm.net
从敏捷的观点来看，自动化的单元级测试是构建流程的扩展。程序员每次运行构建流程并成功编译代码时，应遵循所有的应用单元测试。在敏捷配置管理环境中，损坏的单元测试与损坏的构建严重程度是一样的。这样小问题就不会扩展为大问题了。大问题(诸如全部程序停止工作)不会隐藏在后台。取而代之的是，团队可以在问题发生时定位，不断增长的单元测试集增加了准确监测错误的可能性。项目管理者联盟
我要补充一点关于单元级和系统级测试的内容：明智的项目和企业会进行 测试数据管理。这样就使得测试数据很容易的创建、修改、维护(当系统数据结构发展变化时)、存储(在每次测试前)。当数据模型发生大的变化时，甚至是在某些情况下，当开发数据库被清理掉时，依赖于脆弱的以及被随意修改的数据结构的大量自动化测试集就可以得到迅速的调整。项目管理者联盟
持续集成项目管理者联盟
持续集成与源代码控制、自动化构建流程、值得信赖的自动化测试集共同保证了开发过程中系统的稳定性和系统性能。在持续集成的环境中，程序员需要编写代码，在工作站上运行构建和测试，一天内多次进行检入。同时，有一台构建机(或一组机器)用以编译整个系统，在类似于产品配置的干净的环境中运行所有测试。这种行为可通过手动或者自动的方式启动 -- 或者间隔固定的时间或者由程序员检查代码。当代码没有在干净的环境中通过构建和测试时，无论什么原因，都会在检查后提醒全体成员。大部分情况下，敏捷团队都不会允许任何人检入额外的代码，直到解决了问题。项目管理培训
持续集成带来的好处是，它灌输了一种开发原则，不鼓励检入低质量的代码，且当问题发生时需要立刻解决。由于每天要进行多次代码检入 ，处于集成环境中的程序员很少或从不改变引起不稳定构建的代码。除此之外，如果遇到未完成的代码，团队的构建机制能够在几小时内记录它，而不是几天或几周。因此，程序员在中断代码前，不得不仔细考虑整体设计，甚至需要进行一些测试。这意味着处于持续集成环境中的程序员很少会在系统代码中直接进行试验，很少出现写了一半却忘记完成的函数，或是将系统组件遗忘在某处。当编写代码后立即监测出错误，解决问题所花费的时间往往少于几天或几周后才发现时所花费的时间。 这样，就保证了高质量的代码和更加迅速的发行周期。项目管理者联盟
对于大系统的可扩展的敏捷配置管理项目管理者联盟文章
大型企业经历过许多类似中小型项目遇到过的 CM 问题，还有部分附加的多系统、多项目、多初始属性的问题。例如，当小项目未监测出一个缺陷或者遇到了需要花费几个小时甚至几天才能解决的集成问题时，对于大型企业来说也许会花费几周的时间才能解决。相似的还有，对于小项目的源代码控制和版本的问题相比较于大型企业没有可依赖的配置管理系统时所遇到的系统回滚或多应用重新部署问题来说，简直是微不足道的。依据其规模与复杂度来说，适当的配置管理实践对于大企业是十分必要的。项目管理者联盟
配置管理的敏捷方法能够帮助大企业定位配置管理问题，同时保持对客户需求变化、进化的业务环境、不断提高的技术的灵活性。除此之外，敏捷配置管理方法还能够帮助新项目重复使用现有系统与项目的构建流程加快构建与运行的脚步。项目管理者联盟
本部分中，我们将会探讨在大型开发组织中使用敏捷实践的三个主题。第一，我们将探讨如何灵活的执行敏捷的 CM 流程为单个项目团队和大型开发组织带来好处。第二，如何在地点分散的企业中的分布式项目上使用敏捷配置管理方法。最后，企业如何通过深思熟虑的应用与流程集成加速软件交付周期，增强规模经济。club.mypm.net
有效的团队协调：共享代码库和链式构建项目管理者联盟
每天的项目环境中往往需要团队间共享代码，使用通用库，甚至共享一个又一个的构建流程。例如，一个项目也许需要包含其它项目的构建与测试行为。这可能包括获得共享库的更新版本以确保其它项目的改变不会影响团队的代码，或是保证团队代码库德变化不会影响另一个项目代码的功能。而且，项目间可以共享随时更新的核心资源。这种资源可以包括通用类或类似于测试工具与测试数据生成器等。这种情况在大型企业中十分普遍，它们会自然而然的形成，不需要企业自身的协调。项目管理者联盟
敏捷方法为开发团队提供了更有效合作、实时通信以保证项目进展的机会。通过提供构建成功/失败的快速反馈，开发者能够在最恰当的时候检测与解决问题。项目管理者联盟
为了在大型开发组织中更加有效，敏捷实践必须在单个团队级别上实现，但是应由企业级配置管理最佳实践支持。当执行企业级敏捷配置管理方法时，团队必须负责起多项任务。第一，必须允许基于实践的可靠的敏捷配置管理执行。第二，必须使得流程对于其他团队可见。第三，适当的时候必须包括自身构建与测试行为的系统构建流程。最后一步不需要程序员在每天的工作中完成，但它必须由一个自动化流程尽可能多的执行(理想情况下，从一天一次到一周一次之间)。当其他系统出现问题时，必须快速解决。项目经理博客
为帮助所有团队执行敏捷配置管理， CM 组织还将负有不同的责任。这些任务属于共享的服务实体(常常被称为 Engineering Services Groups)。这种企业会提供一个通用的、用户友好的工具集获平台，所有团队可通过它们完成与共享源代码控制、构建、和测试行为。这种平台包括诸如源代码控制、构建、和测试系统的组件。而且，企业应在 敏捷配置管理实践的执行中提供支持与引导，提供一组可重复使用的 CM 流程或最佳实践推荐以实现一致性和可靠性。最后，企业必须确保每个团队必须具有足够的 CM 流程控制的能力。这看起来有点像在搞平衡，但是对于有效的软件交付来说是有必要的。最终，仍然是团队构建软件，企业的工作是帮助每个项目获得最大的成功。项目管理者联盟
支持分布式团队和组织项目管理者联盟
许多敏捷方法论确实没有考虑分布式团队的情况，但是这一大企业中的普遍特征不会被希望改变软件开发产业的进步所忽视。尽管缺乏具体的关注，但是敏捷配置管理方法仍然对于具有分布式团队环境的项目和企业来说十分有效。项目管理者联盟
为了从敏捷配置管理方法中获益，分布式的项目和企业必须平衡部分敏捷配置管理实践的固定实现，尤其是固定的源代码控制使用、持续集成、和自动化测试。我们不能夸大经常检入和稳定构建维护的重要性，因为被时区或地理位置分开的团队成员需要访问完成的可操作的系统版本。当某些部分损坏或过期后，没有其他位置的团队成员可以帮你一把。www.mypm.net
|
