发布服务器管理权限建议
本帖最后由 phoben 于 2024-9-20 19:52 编辑自从有了发布服务器的管理，发布确实方便不少，不过这里存在一个隐藏的风险，希望引起重视。
由于协作人员较多，我们曾经就出现过这样的“事故”，某开发人员发布的时候手快，点击了“正式环境”，由于服务器IP都是相同的不容易察觉
结果就把未开发未成的新版本发布到正式版进行覆盖了，这就导致应用直接跑不起来，严重影响了客户的生产。
为了避免这样因为疏忽导致的“意外事故”，能否给服务器加个锁？ 毕竟无论前面开发的再好，发布环节一旦错误，会引起不必要的麻烦。
至于加锁的方式，我能想到的建议就是两个方法：
1. 给服务器加密码，如果设置了密码，任何人选择该服务器发布时，都需要验证。不过这样又多一个输入密码的苦恼，还有忘记密码的处理，有些麻烦；
2. 绑定设计器中葡萄城通行证，允许那些人才能选择正式服务器进行发布；
发布这里事还挺多的，主要是不是所有团队或者流程都是所谓的“正规”的情况。
比如，超哥这里点在于测试环境和正式环境是同一个~;P
加上估计也是把administrator权限给所有正式开发了~;P 小萝卜David 发表于 2024-9-20 16:31
发布这里事还挺多的，主要是不是所有团队或者流程都是所谓的“正规”的情况。
比如，超哥这里点在于测试环 ...
你说得对啊，因为用户，环境等关系，我们测试服也是需要和正式服同一个服务器的，分开会涉及到授权、用户等问题。
至于administrator账户也是必须公开的，否则测试版也发布不出去。
这里主要建议是在设计器端进行管控，避免误操作 超哥，我理解你的想法和担心的点。
在想这个是不是通过当前发布的权限分配可以解决呢，按道理测试环境和正式环境的权限是分开的，也是不同的服务器，正式环境的administrator权限是集中在一个负责的人身上的。
活字格加了根据通行证控制的功能，还是挡不住团队内部把权限都给分配了一遍，到时候这个问题还是没有解决。
如果资源受限，测试环境和正式环境不得不是一个服务器的话，在当前管理控制台将发布到服务器的权限设置细化到应用级别，超哥你看是不是也能解决？ Brian.Zhang 发表于 2024-9-20 18:42
超哥，我理解你的想法和担心的点。
在想这个是不是通过当前发布的权限分配可以解决呢，按道理测试环境和 ...
嗯，对的。我想的都是从本地设计器来解决发布问题，你说的从服务端控制也是个不错的办法。
根据发布账号决定哪些用户允许发布该应用。
团队内部再分配好账号就可以，不过这样有一个小小的弊端，就是用户数本来就捉襟见肘的情况下，还要腾出来给开发人员建立发布账户，成本有点高。 本帖最后由 phoben 于 2024-9-20 19:37 编辑
Brian.Zhang 发表于 2024-9-20 18:42
超哥，我理解你的想法和担心的点。
在想这个是不是通过当前发布的权限分配可以解决呢，按道理测试环境和 ...
假设，这个需求就是专门针对误将测试版本发布到正式版本中的话。
那么我觉得解决方案或许可以做的更有针对性。
比如允许在“发布服务器”管理中，允许设置一个星标服务器，或者叫“主服务器”，凡是想要选择带有此标识的服务器进行发布，就弹出警告提醒，这样一来有时候误操作看到提醒就会明白。
毕竟大部分时间，我们都是发布测试版本，看不到这个提醒，只要提醒做的显眼，还是能起到作用的。
另外，也建议在设计器里增加一个选项“不允许发布自定义服务器”或者叫“隐藏发布设置”，来限制开发人员将应用朝自定义服务器发布，只允许发布到设置好的服务器中。
总之，现在的工程基本都是多人协同，希望多在协同场景下考虑考虑管控问题！谢谢！
phoben 发表于 2024-9-20 19:34
假设，这个需求就是专门针对误将测试版本发布到正式版本中的话。
那么我觉得解决方案或许可以做的更有针 ...
超哥，我理解您的问题，您列的这个确实是一个不错的方式。
就是活字格在用户需求上不断做加法，就会导致现在功能越来越多，都会带来越来越高的理解成本。
所以当前，建议的就是通过人为控制，将测试环境和正式环境的权限分开，正式环境的administrator权限集中在一个负责的人身上的。
页:
[1]