互联网敏捷开发配置管理策略思考 由于互联网行业需求变化快、开发迭代周期短、上线频繁的现实状况决定了合理的软件配置管理策略对于软件质量保证、协作开发效率至关重要。 目前公司配置管理在策略上采用的是不稳定主干（unstable trunk）模式，所有的项目都在同一主干上进行修改，在每周上线后并没有明确的 stable 分支版本，基本上是靠 SCM人员手工拷贝代码来管理维护的。这就引起了很多问题： 1）、多个项目组开发人员都可能并发对同样代码进行修改，造成了严重的代码冲突问题。例如张三修改了 a.java 并上 QA 测试服务器，在 QA 测试过程中，李四也对 a.java 进行修改并上 QA，李四的代码覆盖了张三的代码。由于是 SCM 人员并不清楚代码冲突情况，这样张三和李四的代码上 QA 很容易相互影响并很难查具体原因 2）、由于没有明确 stable 分支版本，导致上 QA、上生产只能采用增量更新，上 QA、上生产出问题后的代码回滚很麻烦，严重影响了测试、上线效率。对于生产环境运行的代码的具体版本并没有明确的管理，导致生产系统出问题后要排查问题也很难查。 3）、由于核心基础包没有与上层应用隔离，导致大家都会对核心包进行修改，修改后代码质量并没有有效控制。于是出现因为修改基础包影响整个系统功能等现象 类似的问题很多。要在新的项目实施及后期运营中避免类似问题的重现，至少要从如下几个方面来： 1）、分支管理策略：采用适当的分支管理策略来保证开发库、测试库、发布库的隔离 2）、适当引入每日编译、持续集成、Code Review 等敏捷开发的最佳实践 3）、采用自动化脚本完成上 QA、上生产的部署工作，避免人工失误 4）、对核心框架、后台应用、前端页面开发采用不同的配置管理策略 1、分支策略（Branching Strategy） 代码分支管理策略一般分为 3 种（参考 Branching Strategy Questioned） 1）、不稳定主干策略（The unstable trunk strategy） 此种分支策略使用主干作为新功能开发主线，分支用作发布。此种分支管理策略被广泛的应用于开源项目。比如 freebsd 的发布就是一个典型的例子。freebsd 的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个 stable 分支。freebsd 是每个大版本一个分支。也就是说 4.x，5.x，6,x 各一个分支。每个发布分支上只有 bug 修改和现有功能的完善，而不会再增加...
