3）敏捷发布策略

　　此种模式在采用敏捷开发模式（例如Scrum）的项目中广泛采用，这些项目有固定的迭代周期（例如Scrum中每个Sprint的两周时间），新的功能开发都在Task branch(Feature branch)上进行，在接近迭代周期的发布阶段时候，新建Release branch来完成本迭代周期的发布，各Task branch(Feature branch)的功能merge到Release Branch中。在完成发布后，Release branch的功能merge到Trunk和尚在进行的Task branch中。

　　采用敏捷发布策略要求主干的版本：

　　● 任何时候都可以发布 ：在任何时候，产品所有者都可以基于主干的新版本，发布新版本的产品

　　● 希望尽早发布

　　此种模式较适合敏捷开发软件的要求，但对程序员及SCM要求较高。

　　关于敏捷发布策略可以参考：多个敏捷团队之间的版本控制

　　2、配置管理策略

　　根据目前公司的实际情况，建议采用稳定主

　　干策略为主。淘宝也采用了类似的版本管理策略。

　　具体操作策略如下（尚需要细化）：

　　1）trunk保持稳定，保证可以随时发布。trunk只有SCM人员才具有写权限，开发人员等只有读权限。

　　2）为降低SCM分支管理的压力，branch的权限可以授予给指定的几个组长

　　3）在每一个项目开始前，采用Branch per feature(Branch per Task)的分支管理模式（Common Branching Patterns ），由各组长或SCM人员按照branch管理规范建立对应项目的开发分支development branch，例如airline_product1_feature_leader_date、airline_product2_bug_leader_date。

　　项目定义：新功能开发、bug修复、需求变更等

　　4）在每周的上线发布后，在主干建立基线release版本（通过svn tag），以当前的主干作为基线，建立下一发布周期的test branch

　　5）开发人员在所在项目的development branch完成开发及集成测试后提交上线单，由SCM人员根据项目上线单的分支名称merge分支代码到本发布周期的test branch，进行测试。如果在测试过程中有新的上线单且有可能与其他上线单存在冲突，则在merge到test branch的过程中，SCM人员可以很容易及时排查问题。

　　只要对上线单命名按照规范进行定义（例如与分支名称相同），此部分工作可以由脚本来自动化，存在冲突再人工干预。