为了从敏捷配置管理方法中获益，分布式的项目和企业必须平衡部分敏捷配置管理实践的固定实现，尤其是固定的源代码控制使用、持续集成、和自动化测试。我们不能夸大经常检入和稳定构建维护的重要性，因为被时区或地理位置分开的团队成员需要访问完成的可操作的系统版本。当某些部分损坏或过期后，没有其他位置的团队成员可以帮你一把。
为了给分布式项目维护敏捷配置管理解决方案，必须检查源代码控制，包括构建脚本和本地环境设置。在任何一个位置的改变都必须自动复制到其他的开发场所。这是因为分布式团队协作和大系统的复杂性决定的。一旦开发过程中系统仅在一处开始出现离奇的行为时，也许需要花费很长时间才能找到问题的根源，而这一问题仅仅是因为没人会想到引起如此问题的服务器或虚拟机的设置。
除此之外，与数据库相关的所有部分都需要被复制与共享。这可以通过定制所有数据库的改变和检验源代码控制实现。 4 它还可以通过某种数据库复制的形式实现。最后，项目必须解决连接或开发行为必须执行的第三方系统的问题。每处场所都必须具有访问相同系统的能力。
有两种普遍的实现分布式和敏捷配置管理环境的方法。第一种就是建立一个单一的开发环境，它可被所有开发团队连续访问。这种环境包括 -- 至少 -- 单一的源代码控制系统，全部数据库和连接系统，执行持续集成的能力。这种解决方案适合于工作在临近时区且具有可靠网络访问能力的团队。第二种方法是构建概念上的单机开发站点。每个团队具有一个完整独立且相同的开发环境，包括源控件，数据库，附加的系统安装，和持续集成安装。每天的复制计划必须保证所有站点的代码，数据，和环境的同步改变。同步行为必须尽可能的自动化。而且，自动化测试必须有规律的编写与执行。如果没有执行每天的复制和完整测试（就是说，如果没有同步化操作），企业也许不久会发现自身处于梦魇中。最后，项目和企业可以使用中立的解决方案，即部分敏捷配置管理环境集中实现，而剩余部分由各个站点单独实现。例如，企业具有通用的源代码控制和构建系统，但是在不同开发场所维护本地数据库实践和其他第三方系统。
通过灵活的工具与流程集成的可扩展性
如果在创建良好构建流程和自动化前进行了充分的考虑与准备，那么它会成为十分有用的开发资产，这些设施能够（应该）在多个项目间做到平衡。大企业的低效源自于为每个软件项目创建一个新的构建系统。结果是以专门的硬件资源和配置管理人员支持多个定制的构建程序。这样就使得大型企业不能根据规模效益从资源池、人员和最佳实践知识中获益。
如果企业计划在任意规模实现敏捷实践（意味着在多个团队、项目和/或操作平台上同时进行 编码-构建-测试-部署周期），那么应当仔细思考这些系统如何通信、交互以创建平滑的编码-构建-测试-部署周期。如果跨团队的，跨系统的整合不是全部开发策略的因素，那么团队常常会发现隔阂，等待周期，和函数间的错误通信会造成开发进度的迟缓。如果没有追踪和收集每个阶段信息的设施，那么团队很难确定系统真实的健康度和发布状态。
此文章共有8页 上一页 1 2 3 4 5 6 7 8 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
