发新话题
打印

[讨论] 关于配置库权限设置的讨论( 此文章被查看:1268次,被回复:8篇!! )

关于配置库权限设置的讨论

大家一起来讨论一下配置库权限设置
大家是怎么规范企业里各个角色对应那些权限呢?
目前我们公司的权限设置比较混乱,也比较死。
刚刚针对我的环境初步想了一下,我是这么打算的:

本着以下的实际情况来考虑的,
我们的开发环境角色大概有以下角色:
老总、技术总监、运营总监、部门经理、项目经理、开发人员、测试人员、QA、CM等。
为所有人员拥有灵活的、必要的权限,对CM人员来说方便设置、放心让相关人做相应操作。

*超级用户-配置管理人员,拥有所有的权限。
*高级用户-老总、技术总监、运营总监、部门经理,对他们来说只是对所有项目的监控(除非涉及项目的具体工作),因此给予这些角色所有项目的read、execute权限。
*普通用户-项目经理、开发人员、测试人员,该角色只涉及自己负责项的项目,因此有read、write、execute权限。对项目经理另外增加打标签等项目管理需要的操作(由于项目人数一般较少,因此项目里就没有再细分开发组、测试组。但对项目大、人数多的项目则项目内再细分,但是一般都不想再细分了,以后维护工作量太大了,权限需求也时常发生变化)。
*初级用户-对具体项目外的其他项目的人,他们经过上级部门确认,需要学习某项目的东西,可以给予read、execute权限

大家说说自己的环境是怎么规范的,发表自己的看法嘛。
知无不言,言无不尽哦。。。。。

大家展开激烈的讨论嘛



© 本文为 tuohzSCMLife 共同所有,未经同意,请勿转载 ©如该文侵犯了您的版权,请联系管理员

TOP

其实UCM的权限更好控制点
虽然base和UCM都是一样的原理



© 本文为 amongSCMLife 共同所有,未经同意,请勿转载 ©如该文侵犯了您的版权,请联系管理员
Where are we ?

TOP

我们用UCM的权限控制,做法比较简单。先建立一个vob,然后设置权限,再然后把vob import成一个component来用。因为组员比较少,所以也没有做细分。都是775。
感觉我们的做法和在base方式下没什么区别。



© 本文为 ambergirlSCMLife 共同所有,未经同意,请勿转载 ©如该文侵犯了您的版权,请联系管理员

TOP

反正具体到一个元素就是,owner ,group,other,每个对应个读写执行,自己看着办了

© 本文为 yunyun123 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员
我后悔带着痛觉来到这个世界

TOP

和你们差不多。只不过基本每个项目都分开发组和测试组。

© 本文为 zsc123 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

高级用户和项目经理是全部权限
开发人员有核心组和普通组  核心组有全部代码和文档的权限  普通组有文档和部分代码的权限   测试人员有文档权限  QA有read权限   其他根据具体情况再设


© 本文为 紫火 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员
西山采薇

TOP

累死了

© 本文为 among 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员
Where are we ?

TOP

引用:
原帖由 紫火 于 2006-12-12 14:12 发表
高级用户和项目经理是全部权限
开发人员有核心组和普通组  核心组有全部代码和文档的权限  普通组有文档和部分代码的权限   测试人员有文档权限  QA有read权限   其他根据具体情况再设

同意用6楼的方法。最近发现大家对这个权限控制讨论的比较多哈^_^

© 本文为 singwa 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

对 高级用户 的问题我有话说:
虽然他们是老总、总监。。但是他们只是了解项目情况,完全没有必要给他们write权限、打标签等权限,他们也没有哪个必要,也不可能深入到项目的具体事项,所以给他们读和执行的权限就够了。不给他们写权限还有一个好处,免得他们无故CO文件,迟迟不CI,影响开发组成员,也避免了配置人员需要经常去提醒他。
至于一些部门经理可能涉及到具体项目的开发和管理,此时再增加相应项目的写权限。

© 本文为 tuohz 所有,未经同意,请勿转载
©如该文侵犯了您的版权,请联系管理员

TOP

发新话题