6）测试人员完成本发布周期test branch所有上线单的功能测试后，由SCM人员将本发布周期的test branch合并到trunk，并通过打tag来release 一个上线版本

　　7）系统人员利用自动化部署脚本从trunk检出对应的release版本进行上线部署

　　此部分工作采用自动化脚本完成，自动化脚本主要完成如下操作：从trunk检出完整的release 版本并打包，并包含部署包的md5验证码-> 上传部署包到生产系统各服务器->校验发布包的md5验证码是否正确，保证文件正确传输->完整备份生产系统的运行包->部署生产系统

　　8）每日晚上对trunk进行持续集成，保证能够正常编译和部署。工具建议采用hudson

　　9）对于核心代码及后台代码的修改，采用Pre-commit review模式，必须通过code review后，才能够提交到trunk中。工具可以采用reviewboard

　　10）其他一些值得讨论的问题

　　开发分支的生命周期问题 ：上线后，原有的development branch变为只读的或者可以定期删除掉。

　　紧急上线策略 ：紧急上线不遵循每周两次的上线周期，因此对于需要紧急上线的程序可以从trunk检出近的release版本代码建立临时测试分支（test branch），紧急上线仍然需要按照规范建立对应的development branch，然后与临时测试分支合并，测试通过后上线，同时由SCM人员将紧急上线的development branch合并到当前的测试分支，继续进行测试。

　　不同项目的配置管理策略 ：对核心框架、后台应用、前端页面开发可以采用不同的配置管理策略，例如核心框架可以采用不稳定主干策略（The unstable trunk strategy）；后台应用采用稳定主干策略（The stable trunk ）

　　3、版本控制工具选择

　　SVN的集中管理模式较为适合目前公司协作开发的需要，例如SVN所提供的集中式权限控制，对代码、二进制文件及文档的集中管理，类似 TortoiseSVN的支持工具以及Eclipse 插件等。而Git/Mercurial（hg）的分布式管理特性，很适合开发人员本地版本开发管理。

　　因此可以结合SVN和Git/Mercurial（hg）来作为版本控制工具。用SVN进行集中管理，用Mercurial（hg）在多个不同机器上进行开发，功能完善并测试完成后再提交至 SVN Repository。可以借助git-svn、HgSubversion、hgsvn这样的工具来结合使用。考虑到目前的开发环境为Windows环境，建议采用Mercurial。

　　值得一提的是SVN从1.5版本开始，对branching merge的支持有很大的提升，大大简化了分支合并的难度。

　　4、一些工具

　　code review
　　http://www.reviewboard.org/

　　持续集成
　　https://hudson.dev.java.net/

　　自动部署
　　http://www.smartfrog.org/
　　http://www.capify.org

　　商业软件中采用atlassian的系列产品倒是不错的选择：Jira+Crucible+FishEye+Bamboo