敏捷中的配置管理有如下几个方面需要考虑：
1、适应敏捷需求的变化，快速的纳入需求版本管理
2、适应频繁的代码构造和频繁的发布；
3、能够提供准确的发布版本的内容；
4、如何和持续集成结合，做好持续集成的最后的结果输出，提高持续的交付能力
配置管理与持续集成
在传统的软件开发方法中配置管理系统或是工具是独立存在，可以独立运行。没有持续集成概念，缺乏需求-〉设计-〉开发-〉测试-〉构造-〉发布整个流程的连续性。
在敏捷方法中的一个重要的最佳实践是持续集成，它实现了代码-〉单元测试-〉构造-〉部署-〉集成测试-系统测试过程，这个过程是软件研发过程中中间那段核心过程点，但是也缺乏连续性。它缺少的正式产品管理-需求管理和发布管理两部分，这部分内容正是配置管理中管理的两个重要的功能点。
综上，考虑整合现有的配置管理和持续集成，做成一个统一管理平台如何？
产品规划：在平台中进行产品结构设计，完成产品定义，业务模块定义，发布定义（可以是安装盘形式，也可以其他某种形式如war包）。
开发设计：完成开发模块定义、开发模块与业务模块关系定义。
初始配置：代码配置库的建立，可以按开发模块建库。
持续集成：集成构造、集成打包、集成测试、集成做盘（生成安装宝过程）、安装部署、系统测试。
版本发布：根据测试结果和发布评估后，可以直接在集成版本库中提取，最后的安装盘进行发布。
补丁发布：根据每次集成过程的代码提交信息获取获取需求或缺陷列表，通过集成状态结果可以清晰的指到那个需求已经被集成，在那个版本的安装盘中，是否被测试通过等等信息。根据这些信息选择要打入补丁的需求，根据需求id查找代码提交事件id，根据事件id找到文件变更信息。依次就可以打出一个比较完成的补丁包，并可以附加上所有集成和验证的信息。
综上讨论:在敏捷中基于持续集成系统或平台，实现配置管理工作，使得流程更加顺畅，版本控制更加严谨和变更追溯性强等。整合配置管理和持续集成是敏捷方法中的一个比较好的配置管理实践方法。
欢迎大家讨论。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
