如何设置权限以在 Accurev 中升级文件
所有，
我们在工程师在没有对代码进行彻底测试和审查的情况下推广文件时遇到了问题。他们最终打破了底线。我不想假设工程师只会在经过审查和测试后推广他们的代码，而是想限制他们推广的能力，直到他们获得许可为止。例如，在代码审查之后，我想选择一个或多个用户以及允许他们升级的文件。我怎样才能自动化这个过程？
你们其他人如何处理工程师有意或无意地升级最终打破基线的文件的“问题”？ 感谢您的帮助。
All,
We have had problems with engineers promoting files without the code being thoroughly tested and reviewed. They eventually ended up breaking the baseline. Instead of assuming the engineers will only promote their code after it has been reviewed and tested, I want to restrict their ability to promote until they are given permission to do so. For instance, after a code review, I would like to select the user/users and the file/files which they are allowed to promote. How can I automate this process?
How do the rest of you handle this "problem" of engineers deliberately or accidentally promoting files which end up breaking the baseline?
Thanks for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有几种方法可以解决这个问题。最简单的方法是在目标流上加锁，本质上是“只有特定用户或特定组可以升级到此流”。这是通过在流浏览器中点击流来完成的。所以现在你最终遇到了进入该流的障碍，这是你可以控制的。您也可以添加额外的流层来补充此方法。例如，如果您当前有：
Prod_Stream -- Build_Stream -- Workspaces
...您现在可以制作：
Prod_Stream -- Build_Stream -- Review_Stream -- Workspaces
将升级锁放在 Build_Stream 上，以便他们可以随心所欲地破坏 Review_Stream，但是您可以在 Build_Stream 中保持更原始的环境。
听起来您没有使用AccuRev Change Packages，即链接源文件到发布记录的功能。这些也成为一种强大的控制机制，您可以在其中对这些变更包的升级设置限制，例如，除非名为“状态”的问题字段的值已切换为“通过审核”，否则不允许“审核构建”升级。然后，这些就变成了程序控制，而不是手动实现的控制。
在 AccuRev 中有很多方法可以剥皮。如果您需要更多信息，可以联系 AccuRev 支持或您的特定客户团队讨论替代方案。
问候，
〜詹姆斯
There are several ways to address this. The easiest one is to put a Lock on the destination stream that essentially says "Only a specific user or a specific group can promote to this stream". This is done via point-and-click on a stream in the stream-browser. So now you end up with a barrier to entry to that stream which is something you can control. You can add additional layers of streams to supplement this approach as well. For example, if you currently have:
Prod_Stream -- Build_Stream -- Workspaces
... you could now make it:
Prod_Stream -- Build_Stream -- Review_Stream -- Workspaces
Put the promote lock on Build_Stream so that they can break Review_Stream all they want but you keep a more pristine environment in Build_Stream.
It sounds like you are not using AccuRev Change Packages, the ability to link source files to issue records. Those also become a powerful mechanism of control, where you can put constraints around promotion of those Change Packages, for example not allowing a Review to Build promotion unless the value of an issue field called "Status" has been toggled to "Passed Review". Those then become programmatic controls, as opposed to manually implemented ones.
There are plenty of ways to skin the proverbial cat in AccuRev. If you want more information, you could contact AccuRev Support or your specific account team to discuss alternatives.
Regards,
~James