软件项目开发中的环境配置和分支策
策略1:一个分支+开发服务器+生产服务器
源代码管理可以使用VSS或CVS等开源软件等来进行。在这里不需要启用任何分支，仅仅将源代码受控即可以了。整个开发由于需要小组协作，所以需要有一天专门的开发服务器，开发服务器可以同时承担数据库服务器和应用服务器。
对于生产环境需要专门的一天数据库服务器和应用服务器。如果考虑硬件的多层部署，这里可以应用服务器和数据库服务器分开。
其它问题分析:
1。没有启动分支，紧急BUG的部署困难，所以设计开发中要考虑新功能开发绝对不要影响老功能已有的接口。
2。没有单独的测试环境，测试过程不稳定，测试和开发工作有相互影响。
适用情况
1。适用于新项目的开发...全部
策略1:一个分支+开发服务器+生产服务器
源代码管理可以使用VSS或CVS等开源软件等来进行。在这里不需要启用任何分支，仅仅将源代码受控即可以了。整个开发由于需要小组协作，所以需要有一天专门的开发服务器，开发服务器可以同时承担数据库服务器和应用服务器。
对于生产环境需要专门的一天数据库服务器和应用服务器。如果考虑硬件的多层部署，这里可以应用服务器和数据库服务器分开。
其它问题分析:
1。没有启动分支，紧急BUG的部署困难，所以设计开发中要考虑新功能开发绝对不要影响老功能已有的接口。
2。没有单独的测试环境，测试过程不稳定，测试和开发工作有相互影响。
适用情况
1。适用于新项目的开发，旧项目的版本的维护期。
2。小于5人的软件开发团队
策略2:开发分支+开发服务器+测试服务器+生产服务器
启用测试分支和测试服务器主要目的是保证维护版本的顺利发布和测试环境的稳定性。
在项目配置了专门的测试人员后，必须要保证测试环境的稳定性。测试服务器上需要安装测试数据库，测试环境的部署主要是同步开发数据库->测试数据库。然后将开发环境打包的接口拷贝到测试服务器相关目录。
其它问题分析:
1。
没有测试分支，维护版本的BUG部署困难。
适用情况
1。项目有专门的测试人员
2。项目进行每日构建，需要保证测试环境的稳定性。
策略3:开发分支+测试分支+开发服务器+测试服务器+生产服务器
启用测试分支了可以基本解决掉维护版本BUG部署困难的问题。
整个测试环境的部署也修改为了直接去编译测试分支的内容进行打包和部署。
其它问题分析:
1。测试的多个BUG必须要测试人员全部测试通过才能够部署。
2。无法很好的解决同时要部署新功能的测试版本，又要部署维护版本的测试功能的问题。
3。正式版本发布过后，在下个版本没有发布前，很难重现或重新编译出生产环境的部署包。
适用情况:
1。运行中的项目，经常需要处理BUG发布维护版本
2。项目有专门的测试人员，需要保证测试环境的稳定。
策略4:开发分支+测试分支+集成分支+开发服务器+测试服务器+生产服务器
启用集成分支了项目中的开发，测试和生产三套环境从数据库到代码完全独立开来。三套环境互不影响和冲突，都可以进行独立的编译和构建。
在这种策略下生产环境的部署可以转移到专门的运维人员进行。启用集成分支的目的是保证在集成环境遭到破坏的时候可以快速的重新构建出生产包进行重新部署。
其它问题分析:
1。当新功能的开发和BUG的修改涉及到同样一个源代码文件时候，没有办法做到仅仅对BUG内容单独部署。
适用情况
1。运行中的项目，经常需要处理BUG发布维护版本
2。项目有专门的测试人员，需要保证测试环境的稳定。
3。系统需要保证集成环境独立性，在需要情况下可以再现集成环境。
策略5:开发分支+测试分支+集成分支+开发服务器+测试服务器+BUG分支+BUG数据库服务器+生产服务器
在运行中需要既进行新版本功能开发，又需要对已经部署的版本进行维护和BUG修复的时候。
往往项目需要设置专门的维护人员，维护人员使用专门的BUG分支和BUG数据库服务器对BUG进行修改并发布维护版本。
维护版本的发布可以直接在BUG分支基线后发布，注意问题是
1。必须所有BUG都改好并测试通过后才可以发布维护版本
2。
BUG分支的内容要及时Deliver到开发分支，当出现Merge冲突的时候要优先保证BUG修改内容。
维护版本的发布如果要在集成分支发布，需要注意问题
1。BUG先Deliver到开发分支
2。
Deliver到开发分支的BUG及时Deliver到测试分支，在测试分支打包后交测试人员测试。
3。测试人员测试通过后，BUG分支修改的内容直接Devlier到集成分支后在集成分支打包进行维护版本部署。
4。存在一个问题是新功能开发完成发布时候统一Deliver到集成分支的时候存在Merge冲突问题。收起
