版本制作自动化方案
(文章来源于GAME-LAB 欢迎大家来GAME-LAB!地址:http://game-lab.org/?p=96)
最近工作比较忙,游戏功能相关的代码就敲个不停,根本无暇去思考一些东西。趁着周末,整理下上周关于版本制作流程的优化的一些想法,有时间就立马去实现,希望能提高项目组做版本的速度,省得每次程序兄弟每天等版本等的都想哭,还有做版本的兄弟,天天就重复着在一堆svn revision list里面挑来挑去,如此机械的工作,希望脚本可以帮他们完成一部分。既省了时间,也省了人力。只期望以后少加点班。
问题
有两个svn分支,一个用于开发(主干Trunk),一个是对外发布的分支(BranchA)。根据要发布的内容列表,合并主干相关的revision到BranchA,有冲突解决之。
这里,要发布的内容列表就是taskid列表,某个要发布的功能都会对应唯一的一个taskid,代码提交的时候,提交日志里面一般都会标有相对于的taskid。制作版本的核心,就是根据这些taskid从主干代码提交日志里面去找相应的日志条目所对应的revision,然后合并到BranchA,合并过程中有冲突则找相应的程序予以解决。重复上面的操作,直到tasklist里面所有功能相关的revision都被合并入BranchA。然后提交,编译,测试。
版本制作现状
手动维护一份未从Trunk分支合并到BranchA分支的revision列表,Trunk新提交的日志也只能手动复制下来,格式化处理一下,然后复制到未合并列表中。根据需求,将要发布的功能,一个一个在未合并列表里面手动查找,然后去合并,有冲突就通知相应的开发程序去解决冲突,合并好之后把相应的条目从未合并列表中删除。全部手动完成的,机械并且效率低下,并且很容易漏掉某条提交revision,实在于心不忍啊!
解决方案
对于上述问题和现在版本制作现状,提出下面的解决方案。实现制作版本的脚本化,提高工作效率。
注意:版本制作的自动化,刚开始实施可能会有点问题。因为大家的提交日志,虽然包含了功能taskid,但格式千奇百怪,没有统一,虽然脚本可以识别大多数提交日志,但还是存在挑错revision的可能,对此也不必担心,在此提供了一个工具去检测这些不符合规格的提交日志,可以先手动去改下这些提交日志即可。希望以后svn提交日志的格式也符合指定的规格,这样更加利于版本制作的自动化。
版本工具脚本
- config 用于配置一些相关参数,比如svn主干或分支的路径、未合并revision列表文件、task列表文件、版本制作日志等等。
- getlog 根据指定的revision或revision1:revision2从主干上抽取相应的日志,并格式化处理之,格式化处理的文件有3种格式,下面会有详细介绍。
- pickup 根据要合并的功能列表文件(tasklist)从未合并列表unmergelist中挑选出要合并的revision列表,并将其从未合并列表中删除。生产一个要合并的revision列表文件mergelist,和新的unmergelist文件。
- merge 根据mergelist提供的revision,将主干Trunk中相应的revision合并到BranchA中,没有冲突就自动提交并继续下一个revision,有冲突就会停止并给出提示,此时可以让相应的提交者解决冲突。
- resolve 冲突手动解决完后,执行该脚步,自动解决所有的冲突然后提交到BranchA,继续执行merge脚步直到结束。
三种版本日志格式
- list revision数字列表文件。
- xml xml格式的提交日志,提供了详细的提交信息,版本号、提交者、日期和时间、提交日志等。
- txt 文本格式,只提供版本号、提交者和提交日志。
整体流程
制作版本的整体流程图如下:
- ready 准备阶段,设置配置。
- getlog 提取主干日志。
- pickup 挑版本。
- merge 合并。
- resolve 解决冲突。
准备工作(ready)
执行所有脚本之前,请先做好准备工作。详细内容如下:
- 准备好当前的未合并列表文件(unmergedlist)
- 准备好要发布的功能列表文件(tasklist)
- 创建一个工作目录,脚本生成的结果和中间结果都会在此目录下
- 配置config脚步里面相关的参数,包含svn路径、工作目录等等相关信息。
准备工作
提取日志(getlog)
从主干中提取指定版本范围的提交日志。此操作根据需求可选。生产的gelostlist文件的路径还有版本范围都在config配置中可进行设置。
挑选版本(pickup)
完成版本挑选过程,代替人工挑选版本的机械重复劳动。
合并版本(merge)
自动完成版本的合并工作,并提交至BranchA。有冲突就会停止,手动解决完冲突后继续执行该脚步。合并完所有mergelist里面的revision。
解决冲突(resolve)
merge的时候发现冲突了,让相应的提交者修改完冲突后,执行该脚本,完成解决冲突的工作并提交至BranchA。然后继续执行merge脚本。
总结
希望上面的脚本可以实现版本制作的自动化,上面的内容不包含编译、打包、测试等过程。对于版本制作者而言,上面这些工作占据了大量的时间,并且非常容易出错。希望该方案可以解决版本制作中的一些问题。
2011/08/21 12:49 上海·松江 david++