小程序
小游戏
企业微信
微信支付
扫描小程序码分享
- 需求的场景描述(希望解决的问题)
有线上版本,同时也有内部测试版本,当测试版本通过之后,才会发布线上的版本,如果只是用一个已创建的项目的话,就需要来回切换appid,非常麻烦,而且为什么一切换就崩溃
- 希望提供的能力
像之前一样,可以同一个目录创建多个项目
3 个回答
加粗
标红
插入代码
插入链接
插入图片
上传视频
你这需求场景不合理。
我们是提供体验版的。同一个appid是可以用于开发版、体验版和正式版。
你好,麻烦通过点击下方“反馈信息”按钮,提供出现问题的。
我们是多人合作开发,分成了多个小组做同一个游戏,例如A组在做一个活动,B组也在做一个活动,但是小游戏就这么一个,当A做完了,需要测试上线,那么B就需要等待着A完全结束才能使用这个小游戏的体验版,这就很尴尬啊。还有就是开发版和体验版与正式版在一起这就是个非常危险的行为啊,如果有一个人把体验版的提交到了正式版,但是体验版的一些配置没有修改,问题就很大了啊。分两个小游戏,就可以完全避免这个事情的发生。为什么这个需求不合理呢?
一个小游戏作为测试使用,一个小游戏作为正式上线的使用,这不才是合理的吗?
这样是把体验版当开发版来使用了。
这样的话,你怎么保证你不会因为人为的错误使用了你正式版的小程序的 appid 去提交了测试版的代码
难道不应该是,
A 开发功能上开发版,测试通过,合体验版
B 开发功能上B的开发版,测试通过,和体验版
正式发布时,测试在体验版做功能回归测试,然后发正式版。
而且版本控制这种东西都交给 git 。
你们需要的是一个好的工作流
你指的体验版是哪个版本的时期?是开发版本的时候吗?我觉得我理解的开发版和体验版,和你理解的不太一样呢
我们在开发的过程中,不同的appid对应的是不同的游戏id和服务器接口,只有正式服的appid才会和正式服的游戏id和服务器接口完全匹配,所以不可能会出现正式的小游戏appid提交到测试的版本,这样的话他自己本地都没办法跑起来。
如你所说的话还有另外一个问题,就是当A开发完,B也开发完,但是这两个功能不是一起上线的话,有一组就需要等待另一组的测试和修复bug了,这个等待时间也很尴尬。因为需要使用同一个小游戏测试。我们的版本是git控制,但是问题点是在于并行开发的时候只是使用一个小游戏就会有时间等待问题。如果并行开发,并且有两个小游戏可以一起测试的话,就会加速功能的开发啊。之前的那种做法不是挺好的吗?为什么又去掉了呢?
这个小游戏账号只能测试一款游戏么,只有一个appid,加入开发多款游戏,这个该怎么办
你们控制测试版还是线上版是通过appid控制的?
额。有两个小游戏账号,一个是用于测试和内部使用的,一个是用于正式版发布的。当测试完毕之后,把完整的内容提到正式版的小游戏上面。只不过appid起到了区别的作用而不是绝对作用。但是我现在只能使用一个小游戏账号创建游戏,另一个小游戏账号没办法创建游戏了。
有点不太理解。不过结合你说的,我的理解是
如果AB组同时开发两个功能,同时做完但是不在用一个版本更新的情况下,先上的功能A确实应该先测试,功能B应该等待,否则同时独立测试是没办法确保AB合并以后不出现问题的。
等到功能A测试完毕合并到主版本以后,再在有功能A的情况下测试功能B。
如果说AB功能本身就是独立的,有A的时候没有B,有B的时候没有A,那这种情况应该不太常见吧,因为游戏代码应该只有一套。
微信开发版是可以有多个的,但是体验版只能有一个。实际进入到测试环节的一般是体验版,但是开发版运行效果也可以做为参考。测试通过的体验版才可以提交审核,而且一般开发人员只有上传代码的权限,策划或者制作人有选择体验版和提审的权限。
开发版有多个是啥意思?哪个算是开发版?哪个算是体验版?我现在有点不太明白
你们有用小程序助手吗
你们游戏的开发都是使用一个小游戏账号吗? 一个游戏两个组同时开发两个活动,完全都是独立的,这个很常见吧?
关注后,可在微信内接收相应的重要提醒。
请使用微信扫描二维码关注 “微信开放社区” 公众号
你这需求场景不合理。
我们是提供体验版的。同一个appid是可以用于开发版、体验版和正式版。
我们是多人合作开发,分成了多个小组做同一个游戏,例如A组在做一个活动,B组也在做一个活动,但是小游戏就这么一个,当A做完了,需要测试上线,那么B就需要等待着A完全结束才能使用这个小游戏的体验版,这就很尴尬啊。还有就是开发版和体验版与正式版在一起这就是个非常危险的行为啊,如果有一个人把体验版的提交到了正式版,但是体验版的一些配置没有修改,问题就很大了啊。分两个小游戏,就可以完全避免这个事情的发生。为什么这个需求不合理呢?
一个小游戏作为测试使用,一个小游戏作为正式上线的使用,这不才是合理的吗?
这样是把体验版当开发版来使用了。
这样的话,你怎么保证你不会因为人为的错误使用了你正式版的小程序的 appid 去提交了测试版的代码
难道不应该是,
A 开发功能上开发版,测试通过,合体验版
B 开发功能上B的开发版,测试通过,和体验版
正式发布时,测试在体验版做功能回归测试,然后发正式版。
而且版本控制这种东西都交给 git 。
你们需要的是一个好的工作流
你指的体验版是哪个版本的时期?是开发版本的时候吗?我觉得我理解的开发版和体验版,和你理解的不太一样呢
我们在开发的过程中,不同的appid对应的是不同的游戏id和服务器接口,只有正式服的appid才会和正式服的游戏id和服务器接口完全匹配,所以不可能会出现正式的小游戏appid提交到测试的版本,这样的话他自己本地都没办法跑起来。
如你所说的话还有另外一个问题,就是当A开发完,B也开发完,但是这两个功能不是一起上线的话,有一组就需要等待另一组的测试和修复bug了,这个等待时间也很尴尬。因为需要使用同一个小游戏测试。我们的版本是git控制,但是问题点是在于并行开发的时候只是使用一个小游戏就会有时间等待问题。如果并行开发,并且有两个小游戏可以一起测试的话,就会加速功能的开发啊。之前的那种做法不是挺好的吗?为什么又去掉了呢?
这个小游戏账号只能测试一款游戏么,只有一个appid,加入开发多款游戏,这个该怎么办
你们控制测试版还是线上版是通过appid控制的?
额。有两个小游戏账号,一个是用于测试和内部使用的,一个是用于正式版发布的。当测试完毕之后,把完整的内容提到正式版的小游戏上面。只不过appid起到了区别的作用而不是绝对作用。但是我现在只能使用一个小游戏账号创建游戏,另一个小游戏账号没办法创建游戏了。
有点不太理解。不过结合你说的,我的理解是
如果AB组同时开发两个功能,同时做完但是不在用一个版本更新的情况下,先上的功能A确实应该先测试,功能B应该等待,否则同时独立测试是没办法确保AB合并以后不出现问题的。
等到功能A测试完毕合并到主版本以后,再在有功能A的情况下测试功能B。
如果说AB功能本身就是独立的,有A的时候没有B,有B的时候没有A,那这种情况应该不太常见吧,因为游戏代码应该只有一套。
微信开发版是可以有多个的,但是体验版只能有一个。实际进入到测试环节的一般是体验版,但是开发版运行效果也可以做为参考。测试通过的体验版才可以提交审核,而且一般开发人员只有上传代码的权限,策划或者制作人有选择体验版和提审的权限。
开发版有多个是啥意思?哪个算是开发版?哪个算是体验版?我现在有点不太明白
你们有用小程序助手吗
你们游戏的开发都是使用一个小游戏账号吗? 一个游戏两个组同时开发两个活动,完全都是独立的,这个很常见吧?