规划

规划项目安全性共有四个基本步骤。
  1. 确定 Rational® Change 用户的角色,可包括诸如测试者、开发者、经理和团队负责人之类的头衔。

    这些头衔大致对应于个人的职位。但是,一个人可以具有多个角色,甚至可以在不同项目中具有不同的角色。

  2. 确定执行这些角色所需的特权,例如提交、验证、复审、分配和做出结论,以及用于修改某些属性的许可权。

    定义变更请求流程时,可以使用这些特权。然后根据角色需要的特权,对角色进行定义。

  3. 对 IBM® Rational Directory Server 用户进行分组。

    您或许已具有组,但是可能还需要根据角色/项目组合(例如,指定项目的开发者)创建特定于项目的额外组。

  4. 确定逻辑相关的 CR 集,例如,根据产品、发行版或团队。

    将这些相关的 CR 集与组成员及其角色结合起来,以形成项目。

安全性模型迁移

从传统数据库安全性模型迁移到具有项目安全性的动态特权是一个手工流程。该流程由两个高级步骤组成:
  1. 定义项目安全性。
  2. 从 Rational Synergy 中除去专用于 Rational Change 的所有数据库特权。

多个服务器的意义

具有全局性质的项目安全性、角色和全局分配存储在 Rational Directory Server 中。 共享同一 Rational Directory Server 的两个 Rational Change 服务器具有相同的项目安全性和角色定义。同样,如果将现有的 Rational Change 服务器指向另一 Rational Directory Server,它将具有不同的项目安全性设置。

注: 项目安全性和角色定义遵从 Rational Directory Server 的设置,而非 Rational Change 服务器,即使它们通过 Rational Change 服务器定义,也是如此。

分阶段部署

请勿在活动的生产环境中更改项目安全性,而应在隔离的登台环境中进行更改。您可以将结果部署到生产环境中。然后您可以先对系统进行试验和验证,再激活系统。

仅当登台环境和生产环境使用不同的 Rational Directory Server 时,才需要进行此类部署。 如果不是这样,由于项目安全性定义在 Rational Directory Server 中持久保存,而且对于任何 Rational Change 服务器都是公共的,因此数据已得到共享。

针对此目的提供了两种 Perl API:
  • ExportProjectSecurityData
  • ImportProjectSecurityData

缺省情况下,导入是非破坏性的。也就是说,对数据进行扩充,而不是覆盖现有的数据。请参阅 Perl API 帮助以了解详细信息。


反馈