首页 旅游门户系统 软件定制开发 网站建设 微信开发 小程序开发 微信营销 H5制作 九州旅游门户系统 客户案例 关于九米 行业资讯 联系我们

游戏后台研发流程与发布流程小总结

标签: 游戏程序发布 游戏开发 游戏 | 作者:九米科技 | 浏览量:0 | 来源:张世夷

在很多游戏相关的课程与会议上,我们经常可以听到一个名词--管线,所谓管线其实就是pipeline,流水线之意。在很久以前我听到这个名词的时候,往往第一反应都是各种游戏引擎的渲染管线,但是这里其实讨论并不是各种技术层面的管线,这里的管线其实讨论的是人员协作流程,其重点说的是成员和成员之间怎么协作,特性组与特性组之间怎么协作,如角色生产管线与关卡生产管线等等。

微信截图_20230510143054

一个游戏产品的研发,有各式各样的管线,而落在游戏研发层面如后台研发,这里其实我们没有提管线这个大的名词,我们更多提的是研发流程与发布流程,而这也是我们本文的主要内容。


游戏后台研发是多人软件研发中的一种,本文意在从游戏后台出发去讨论团队工作协作流程的细节。软件研发是一个多人协作的过程,在团队规模逐渐增大的情况下,合理的流程与规范是保证项目平稳推行的基石,通常我们也称这个流程为workflow,亦即工作流程,一个好的流程应该可以让大家非常自然且平稳的接受,工作过程尽可能少地出现打断,如同流水般自然而然地完成了。如何探索一个适合团队特点的工作流程与如何保证流程规范执行是本文讨论的重点。


从个人经验来看,流程一般有两种,一种是研发流程,一种是发布流程。


研发流程:

研发流程即研发同学彼此之间如何协作,从细节处着力说即研发同学:


如何提交代码

如何减少冲突的可能性

如何保证合入的代码质量性

研发同学如何提交代码?

提交代码是每一个研发同学每日工作中都要执行很多次的过程,甚至在有些特别的部门会以commit量来衡量工作产出,所以如何提交代码是一个很基础而且重要的问题。提交方式实质上基本和各种VCS即版本管理系统如SVN,Git等紧密关联。


如果是SVN,很多团队基本都是选择主干开发,即在trunk分支直接开发,开发完后直接commit到trunk分支,这样的方式好处在于直接简单易懂,在协作人数仅有几人的时候,这种协作效率其实非常的高,但是缺点其实还是很明显的,没有办法在合入前做code review与各种合入前的自动化测试(如单元测试与接口测试),代码质量依靠研发同学水平来保证。


如果是Git,Git因为经过开源项目的实践,已经演变出了很多workflow,如git-flow,github-flow,gitlab-flow


git-flow考虑的协作细节非常多,所以流程非常复杂,所以比较少用软著代申请,找河北九米,电话13785208521(同微信)


github-flow在git-flow上做了大量的精简,通过在主干master分支不断迁出临时分支来进行功能开发与不断提PR(pull request)来将功能合入主干,非常适合需要持续合入,持续发布的情况。但是缺点也是过于简单,现实的情况总是多变的,所以会演变出改进方案。


gitlab-flow则在git-flow与github-flow之间取了一个平衡,即尽可能兼顾了各种可能的协作情况,又尽可能简化了流程


这些协作流程都是需要细细品味日常的工作协作流程才能品出其中的区别,这里需要的是非常仔细地观察研发流程中遇到的各种问题与解决问题过程的思路。


研发同学如何减少冲突的可能性

在代码合入过程中,最令人心烦的便是代码冲突,解决冲突是一个影响工作效率的事情,这个应该要尽量规避。如何规避冲突,其重点在于要尽可能地减少多人同时编辑一个文件的可能性,在日常研发中在冲突有三个痛点:


多人同时一个文件同一行,引起冲突,需要人为介入并解决冲突。以笔者工作经验为例,日常主要经常出在协议文件中,因为协议消息ID全部定义在一个文件中,导致会经常在项目开发中遇到协议id声明文件冲突。

本地多个提交时,进行rebase过程,会连续出现多个冲突,这个可以在本地先将个人的全部提交压缩成一个commit再进行rebase,这样就可以只解决一次冲突。

大特性开发拉分支过久,与主干偏离很多,在合主干时会出现大量冲突,这个时候要尽量让分支存在的时间足够短,即Short-Lived Feature Branches。

研发同学如何保证合入的代码质量性软著代申请,找河北九米,电话13785208521(同微信)


git的生态构建很多生态链,这让我们在代码合入之前有很多工作可以做,基于git的PR/MR流程,我们做了很多工作来保障每一个PR/MR的质量,如:


Review人进行core review后审核合入审批机制

PR/MR必须基于现有的master分支与PR/MR代码,进行合并后,构建一个测试环境,这个环境会进行完整的进程拉起与周详的协议测试用例,如果本步失败,那么则不允许合入,要求代码合入人必须解决出现的问题,这样可以保证每一个PR/MR都可以产出一个可用版本。

单元测试与代码风格检查等

在实践过程中,完成的起服与周详的测试用例自动化测试,是我们平常发现问题最多的点,这一个关键步骤保障了合入主干的代码一定是可用的,而且协议也一定是可用的,这样保证了当前PR/MR合入后服务器可以构建一个稳定版本。


而对于如何构建周详的协议测试用例则是另外的一个问题,我们后面另起文章讨论。


发布流程:

发布流程没有统一的标准的好与坏,如软件工程实践的经典名言一样,没有银弹。发布流程最主要是需要匹配项目团队的实际情况。如何测试,如何发布,如何进行hotfix都是非常重要的问题。而决定这些问题的根源由我们希望以那种形式发布决定,所以这个地方需要有需求前提背景。


假设有这样一个背景:


团队希望以每个大版本(3周),每周发一个小版本的形式来进行版本迭代。那么每一个大版本便是一次大版本发布加2次小版本发布,而且大版本发布以全量更新的方式进行发布,小版本发布以增量更新的形式进行发布。团队基于gitlab-flow的形式进行协作。


这里有几个非常关键的点:


小版本发布时属于增量发布,例如第二周第一天发布时,发布人员拉取Beta1_W2_hotfix分支后,开始用Beta1进行对外发布时,此时Beta1分支内容等于Beta1_W2_hotfix,这个时候发布人员需要确定增量更新的内容,那发布人员只需要信任Beta1的提交,即发布人员需要通过检查第一周在Beta1的新增提交就可以判断本周增量更新内容。

为了保证发布人员可以正确对外发布,所有协作同学进行hotfix时必须进行三线提交,否则会出现遗漏发布的问题。

这里需要建设工具确保hotfix人员有按照规范即三线提交的要求进行提交。

以上就是研发流程与发布流程的一些个人小总结,其实这里面还有很多内容没有一并考虑进来,如没有考虑客户端的分支协作,如何保证客户端也是三线提交?还有这里面还有新的需要考虑的点是,周版本内容与外网hotfix合并外发时,也需要约定如何协作,例如PM什么时候禁止提交,还有就是需要提交后才能测试验证,那么发布人员什么时候确认提交内容已经全部转测呢?会不会把风险提交带出去呢?都是需要进一步思考的问题。软著代申请,找河北九米,电话13785208521(同微信)


温馨提示:

1、凡本网注明“来源:***(九米科技)”的作品,均转载自其它媒体,转载目的在于传递更多的信息,并不代表本网赞同其观点和对其真实性负责。

2、如因作品内容、版权和其它问题需要同本网联系的,请在30日内进行。

征稿启事:

为了更好的发挥九米科技新闻资讯平台价值,促进诸位自身发展以及业务拓展,更好地为企业及个人提供服务,九米科技诚征各类稿件,欢迎实力来稿。

填写您的联系方式获取报价。

* 下载报价如有疑问,请与我们的销售顾问取得联系。