使用版本控制的分支合并进行开发,模拟,运营环境的统一部署

 

为了运营环境的发布管理
我们会使用版本控制软件
来将所有发布在运营环境的内容进行系统管理
以保证能够及时的回滚到前一个发布状态
但是当流程链涉及到跨部门合作时
我们如果仍旧只是简单的分割管理层次
在不同部门之间使用简单文件传输进行沟通
就会导致比较大的沟通损耗
特别当一次发布内容比较多时
运维发布的操作就会特别琐碎
开发需要保证找出所有需要发布的内容,按照原来路径位置和目录打包
而运维则需要保证所有文件按照文档的所标识的位置覆盖或者新增文件
这这种发布文档.最大面临的问题就是文件有缺少或者位置错误.
而且这种开发环境以及运营环境独立的模式.
会导致需要在各个环境保持一台独立的版本控制服务器来保存各种副本.

如果是涉及到整个开发运营流程
我们可以只使用一套SUBVERSION服务器进行对一个项目的分割管理
在同一个项目内建立不同的分支
而在需要发布时,由开发将需要正式发布的内容合并至发布分支
运营环境直接从发布分支中获取更新后的程序发布即可
这样在整个流程链中.可以保证不会由于目录写错或者文件名写错等等导致的发布问题
因为开发环境的目录和分支后的发布目录的路径是一致的.
再复杂的目录也不会因为人为的目录书写问题而出错,因为其中不需要人为去书写目录以及文件名

整个流程如下
1.建立两套服务器.配置一直.程序发布的目录等设置也保持一致
2.其中一套作为开发测试环境使用.一套作为对外公布运营使用
3.建立SVN Repository,建立trunk目录作为主代码分支(本人习惯使用develop或者maincode.这个按照实际情况可以更换.),建立branch目录作为其他分支(这里我使用release目录作为发布分支).
4.开发人员使用develop分支进行开发,开发测试环境使用此分支进行同步.在模拟环境内进行测试.
5.当开发人员确认某个测试版本稳定后.将develop分支的内容合并(merge)到release分支.
6.运维组将release分支的内容update到运营环境中.

操作详解与注意事项
1.建立代码树的时候.把最初的源代码放在repository的一个分支目录下.而不要放在根下.否则会对做分支造成很大的困难.
例如本例中.开始的文件存放在svn://61.142.253.163/test这个repository下的develop目录下.

2.签出代码
在开发人员的PC上
建立目录
进入目录
选择SVN checkout
输入svn repository节点地址
输入用户名和密码

3.创建分支
在开发目录中选择Branch/tag

在To URL中选择需要创建的分支

4.合并
在开发客户端上新建立一个目录
将release分支的内容update到新目录
在release目录内选择Merge

然后在上面From中选择需要从哪个分支合并过来

选择起始revision号
默认在To中的分支和From分支应该是一致的
选择结束的revision号.
则这段之类commit的内容
都会合并到目前的目录内
点击merge
合并结束后本地release目录已经包含了从develop分支合并过来的内容
然后再本地目录commit.将合并后的内容提交到release分支上

5.从开发树中抽取文件更新到发布树
目前的流程会面临一个问题
就是当一个开发人员在develop分支内一次提交的内容即包含bugfix,又包含特性增加
则这次revison内的内容无法单独提取出来去更新release分支
因为可能运营环境需要增加的只是一部分bugfix
当然这个问题也能够通过更细致的分支操作来解决
即是每个开发人员对于bugfix以及特性增加
都有不同的分支树来处理.而之后再分部分的合并到develop分支上
而测试通过之后.可以将区分的内容去合并到release分支上
就是开发人员每次提交的内容如果不属于同一部分
是不允许一次性同时提交的.
另一个解决这个问题的方法
是在开发树中show log

然后选择对应revison中的对应文件.选择save revision to
将保存的文件覆盖发布树的对应文件

这样从一次混杂着bugfix以及新特性增加的commit中提取需要内容来做更新的操作
就可以顺利完成了