整 理:吴万利
时 间:2015-01-08
说 明:svn管理流程实践
svn目录结构
trunk 主干:存储最新稳定的版本
tags 标记:主要保存比较完整的版本标记,类似里程碑
branches 分支:用于分工操作,以开发分支、用户名、日期为目录存储
svn工作模式
基础结构准备
选定trunk为主要开发文件夹
tag为发布版本的地方(可能也有紧急的bug修复,之后要将代码合并回主干)
branch为分支目录(bug修复、模块独立开发等)
现有的文件结构
trunk/ 主要开发的目录
*.php
tag/ 版本发布目录(发布tag一定要标记信息!)
release_1.0 已经发布的一个版本(1版本号,0修订号)
branch/ bug修复,独立模块开发等
问题应对流程
- 日常的开发怎么办?
答:日常可以在trunk里面进行开发,周期不长开发测试完成可以打包出来进行测试。- 开发完成之后由管理人员操作打包得到
http://svnxxx.xxx.com/svn/vshop2_trade_module/tag/release_2.0 - 在测试机上测试稳定之后就可以准备上线
上线:可以在对应项目目录下面执行svn switch命令(我的方案)
- 开发完成之后由管理人员操作打包得到
- 线上的项目出现问题怎么办?
- 紧急而且简单
- 直接在release里面修改(其实不推荐,而且测试机的配置,同样用switch命令?),然后测试提交,在线上更新。
- 通知trunk、branch里面的dev进行merge(merge前提交所有改动!)
- 不紧急而且较复杂
- 在branch里面copy一个release_1.0版本为dev_1.0_bugfix进行修改
- 测试通过之后发布为tags/patch_1.1 通知trunk等进行合并操作
- 紧急而且简单
- 开发新的独立模块怎么办?
答:可以考虑在branch下复制一个当前稳定版本的dev_2.0_yilucaifu出来进行修改,测试完成之后可以独立上线,但是不要忘记合并。
情景模拟
0. 情景准备
svn仓库结构:
branches
tagsrelease_1.0
trunk
服务器上代码结构:
正式版
tvshop2_online(svn:tags/release_1.0)
测试机
tvshop2_online_dev(svn:trunk)
1. 上线的东西出问题,需要调试
- 对于tag版本出一个bugfix分支
svn cp
http://svnxxx.xxxx.com/svn/tvshop2/tags/release_1.0http://svnxxx.xxxx.com/svn/tvshop2/branches/dev_1.0_bugfix
-m '1.0bug修复' - 测试版切换到分支
tvshop2_online_dev:
svn switch http://svnxxx.xxxx.com/svn/tvshop2/branches/dev_1.0_bugfix - 测试版debug,测试提交
tvshop2_online_dev:
svn ci -m 'debug message' - 发布一个新的版本
svn cp
http://svnxxx.xxxx.com/svn/tvshop2/branches/dev_1.0_bugfixhttp://svnxxx.xxxx.com/svn/tvshop2/tags/patch_1.1
-m 'bug修复' - 改动上线
tvshop2_online:
svn switch http://svnxxx.xxxx.com/svn/tvshop2/tags/patch_1.1 - 清理无用分支dev_1.0_bugfix
svn del http://svnxxx.xxxx.com/svn/tvshop2/branches/dev_1.0_bugfix -m '已经上线'
- 合并改动到主分支
tip:一般线上的紧急调试都不会太大,所以合并一般问题都不会很多- 切换测试机为主分支
tvshop2_online_dev:
svn switch http://svnxxx.xxxx.com/svn/tvshop2/trunk - 合并改动到主分支(推荐在windows下用工具辅助做)
svn merge http://svnxxx.xxxx.com/svn/tvshop2/tags/patch_1.1/ ./ - 下次提交将改动一起提交即可
- 切换测试机为主分支
2. 新的模块的开发
- 开发之前先大致确定一下可能的改动,是否跟原来的开发改动了同一块地方。
- 对于需要共同修改的地方在合并的时候必须小心处理,可以跟原来的开发一起查看改动是否合理。
3. 优点:
- 线上代码稳定,可靠性高(除非有人故意删除release)
- 回退方便,能够很清楚的知道上个版本是哪个
4. 缺点:
- 操作复杂,繁琐,比较容易搞混当前的版本是哪个
- merge回当前开发分支的时候可能会引起冲突(无法避免)
- 线上如果有人修改可能会引起树冲突,所以切换之前需要提交所有改动
5. 原则总结:
- 在执行switch的之前一定要提交所有的改动。
- 每次发布新版本之后其他分支需要从trunk上merge来获取最新的版本(冲突的话需要协商解决)。
仓库迁移记录
- 准备好即将使用的svn仓库
- 在线上先co出两个文件夹备用(svnshop2+svnshop2_dev)
- 将线上的代码export一份作为一个基础版本,并发布一个tag(release_1.0)
- 将本地开发的所有改动提交到之前的仓库
- 将之前的仓库文件导入到现在的svn里面的trunk中
- 在线上测试机co trunk,测试各项功能是否ok(测试一起购、一路财富改动都没有问题)
- 以后上线:trunk发布新的tag,线上执行switch操作(确保线上svn里面的文件没有M状态!)
可能的问题
- crontab怎么办?(直接在服务器上做的alias,没有影响原结构)
- 静态文件上线?(只能针对静态文件单独做合并、上线)
- 以后数据库的改动怎么同步?
1、 “每次发布新版本之后其他分支需要从trunk上merge来获取最新的版本(冲突的话需要协商解决)。”
还有一种解决方法:svn里删除分支重新创建,代码里svn up一遍即可。
2、switch可以简单理解为svn up,只不过源变成了另一个仓库;所以M状态的文件会被更新(仍然保持M状态),也可能产生冲突(两边同时修改,状态C)。
3、个人建议是,所有耗时的操作(修改release上的BUG、开发功能)都在分支里进行。
4、一个活动的资源文件可以单独放一个文件夹,方便活动结束后清理,使仓库的体积维持在较小的范围内。