敏捷配置管理实践

  精简进程和自动化是敏捷配置管理方法的基础。3每一个活动(来自于代码检测确定损坏测试)都应很容易的执行,并为单个程序员和整体团队提供快速反馈。而且,敏捷团队力图使得这一行为自动化的记录于文档中。例如,自动化的构建仅需要写入它的执行脚本中。可以很容易的得出包括由 Microsoft Word 所创建的过期文档,"指南"文档在内的良好自动化构建脚本收集的好处。

  已根据各种项目环境中的用途标识出了组成敏捷配置管理的实践 -- 无论大或小,简单或复杂。 我将在本部分中探讨实践,下一部分讨论针对大型企业特殊需求的应用。

  源代码控制

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

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

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

  构建自动化

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

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

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

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

  自动的移植及部署

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

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