配置管理在软件开发项目中极其重要，它记录了软件开发流程的演进过程。它能够实现软件增量式开发，并随时可以追溯或查看任意时间的软件版本。持续集成一书中对配置管理是这样定义的：
配置管理是指一个过程，通过该过程，所有与项目相关的产物，以及它们之间的关系都被唯一的定义、修改、存储和检索。
那么我们怎么做配置管理？
（一）版本控制
（1）首先我们需要一个版本控制系统，Subversion、Mercurial或者Git，对于一个分布式的团队最好优先选择Mercurial或者Git。
（2）把软件开发有关的所有内容进行版本控制。包括源代码、数据库脚本、构建脚本、部署脚本、文档、第三方依赖、MindMap等等。保证新加入的成员能够很容易地从零开始工作，保证在新的测试或者生产中能轻松部署应用。
（3）频繁提交代码到主干。为了验证修改的正确性，快速的得到反馈，以及能够轻松地回滚到某个无错误的版本，提倡频繁提交。
（4）提交注释清晰明了。构建失败时，为了能够通过版本控制器查询是谁破坏了构建，以及他做了哪些修改，提交代码的时候必须使用意义明显的提交注释。建议第一段是简短的总结，第二段是描述更多的修改细节。
（二）依赖管理
第三方库文件是最常见的依赖，我们可以在本地建一个外部依赖库的副本来统一管理所有依赖，如果你使用Maven，你就可以这样做。
（三）环境配置
软件最终的运行环境可能不止一个，而且每个软件都会依赖的硬件、软件、基础设施或者外部系统才能工作。我们必须把环境配置自动且可靠化，可以借助Puppet或者CfEngine之类的工具软件。
持续集成
敏捷宣言首要原则就是尽快的交付可工作的软件到客户手中，为了实现这一原则，控制成本并及早的验证修改的正确性和快速得到反馈，提倡使用持续集成方法。
准备工作：
（1）版本控制
（2）自动化构建
（3）持续集成系统（Jenkins，Go，TeamCity等等）
（4）七步代码提交法则。如下图：
（2）提交前在本地运行所有的提交测试（单元测试、功能测试等）
持续集成改变了以往的软件开发模式，使应用程序任何时候都处于可运行状态，创建了一个快速的反馈环，使你能够尽早的发现问题，而发现问题越早，修复成本越低。
测试策略的设计主要是识别和评估项目风险的优先级，以及决定采用哪些行为来缓解风险的一个过程。
测试有很多种，Brian Marick提出了如下图 所示的测试象限。
好的测试策略会带来很多的积极作用。测试会建立我们的信心，使我们相信软件可按预期正常运行。
相关链接：
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/