Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

重新规划业务管理方式 #72

Open
annProg opened this issue Nov 2, 2018 · 2 comments
Open

重新规划业务管理方式 #72

annProg opened this issue Nov 2, 2018 · 2 comments
Labels
enhancement P2 priority Medium

Comments

@annProg
Copy link
Collaborator

annProg commented Nov 2, 2018

以app为粒度管理业务,可能太细,目前情境下app基本对应某个业务的一个模块,通常一个人要负责很多个app。通过cmdb管理k8s部署方式下,测试人员要使用更是要添加几倍于研发人员的app数量,也会造成app联系人过多过乱,测试人员收到报警等问题。

考虑改为以业务线来管理,需要实现:

  • 业务线支持层级(类似组织)
  • 业务线联系人分角色(负责人,产品,研发,测试),负责人可以编辑业务线信息,添加人员。k8s联系人管理逻辑中自动添加测试人员,然后测试人员就可以部署业务并了
  • 人员负责的APP只作为报警订阅使用?没有人订阅的app,默认发整个业务线的研发产品及负责人。
@annProg annProg added enhancement P2 priority Medium labels Nov 2, 2018
@annProg
Copy link
Collaborator Author

annProg commented Dec 6, 2018

  • 对于报警和k8s对象查看编辑权限,如果app有明确负责人,那么使用此负责人,否则使用业务线联系人(除了测试产品)
  • 研发人员有权限添加或者删除所在业务线内自己负责的app

@annProg
Copy link
Collaborator Author

annProg commented Oct 30, 2019

重新考虑业务管理方式:

现有业务线定义保持不变,把组织用起来,组织分级,业务线不分级。好处:设置用户只能查看自己业务线的CI,数量会比较少,更清晰一些。问题:如果组织划分不合理,可能会出现一个用户负责2个组织业务的问题,用户就会无法查看其中一个组织的CI。另外可能导致工单分配出问题

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement P2 priority Medium
Projects
None yet
Development

No branches or pull requests

1 participant