Rational ClearQuest 进行变更管理(2)
利用 ClearQuest MultiSite 支持一个分布式环境
由于 IBM Rational 的客户众多，IBM Rational 开发团队需要一个支持分布式环境的变更管理也是十分正常的事。IBM Rational ClearQuest MultiSite 提供了一个解决方案。针对 RATLC 我们使用了这个方案，在这个方案中我们定义了数据库镜像(database replicas)和 主控权(Mastership) 策略支持分布在世界各地的部署，支持以及测试组。
图2描述了 IBM Rational 利用 ClearQuest MultiSite 进行的 RATLC 数据库镜像的内部开发。(数据库镜像的真实名称在这个图中已经被更改。)
图2.一个 ClearQuest MultiSite 部署的样例
这篇文章的目的不是要详细阐述如何安装和支持一个分布式 ClearQuest MultiSite 环境，我将谈论一些如何处理主控权(Mastership)问题的基本思想以及乐观锁定(optimistic locking)。
ClearQuest MultiSite 主控权
ClearQuest MultiSite 主控权的功能就是确保一个 ClearQuest 记录只能够同一时间在一个数据库镜像站点更新。一个登陆到站点的用户如果没有记录的主控权，只能查看记录信息，而不能够对它进行修改。要想进行记录更新，用户必须登陆到拥有主控权的站点。
考虑这样一个场景，客户在伦敦，支持代表在班加罗尔，开发人员在罗利，测试人员在北京。如果这个变更请求的确认发生在北京，这也是一个数据库镜像的地点，这个记录所有者可能要从一个站点更换到另一个站点，比如这个记录的状况从活动变更到解决以及修正需要确认的情况。(注意：用户可以登陆到任何一个镜像中来读取信息，但是必须登陆到一个拥有主控权的镜像才能变更这个记录。)
乐观锁定
当两个人要更新同一个记录时，ClearQuest 就可以利用乐观锁定来处理这种情况。第一个保存记录更新的人——并不是第一个为了更新而打开记录的人——会成功。其它的变更就不会被保存。因此，第二个试图更新记录的人将需要重新得到这个记录并重新进行他或者她的更新。
我可以推荐一个减少这些麻烦的技术，因为 IBM Rational 内部也使用它，就是利用一个叫作 Record_Script_Alias 的 ClearQuest scripted Action 类型创建一个记录。这个 Action 在一个远程的或者同时正在进行更新的记录上执行。它可以创建一个新的记录并且在这个带有 Action 记录 ID 的新记录上更新一个新的字段。ClearQuest 然后创建一个从这个新的记录 ID 到这个 Action 记录的 反向引用(back-reference)，不管是否设置了主控权。这两个记录都是对方的相关扩展——直接在当前站点，接下来就镜像到其他站点。这个反向引用确保相连接的记录能够合适地更新。也就是说，当您创建一个记录并更新涉及的字段时，这个反向引用将会更新相关的记录，不管主控权还是乐观锁的争用。
这里还有一个更进一步的提示：当创建子记录作为创建父记录的副产品时，使用您创建的父记录的 Commit Event 来创建这个子记录。
所有权(Ownership)的角色
由于镜像的局限性，对于 ClearQuest 来说不能实时地确定记录是否在更多的站点被创建或者变更。因此，如果记录在多个站点被创建并反向引用，对于用户来说是不可能在事前知道这些情况的。您可以通过分配所有权和确定最有可能执行 Action 的人(或者唯一的人员)来进行限制。这样就缩减了与记录相关的冗余的过程，更有效地创建一个虚拟调度机制。
这个方法同时还简化了主控权和乐观锁争用问题的解决。就是说，您即可以象上面所描述的一样来创建一个记录然后用反向引用连接记录，也可以用所有者指派的隐含更新来构建记录。您不必同时使用两种方法。
基于角色的用户体验
为了设计、实现和管理变更管理系统，ClearQuest 产品支持基于角色的模型 。
为了我们的中心目的，同时也为了说明 ClearQuest 文档的目的，IBM Rational 已经确定了三个常见(实际上非常普遍)角色。大多数其它您可能确定的角色都是这三个中的具体实例：用户、管理员，以及方案开发者。
用户角色覆盖了所有 ClearQuest 客户端可用的任务，这些任务用来在用户数据库中重新恢复、创建或者修改数据。普通用户任务包括从一个用户数据库中获取信息和对这些记录进行操作，提交变更请求、处理变更请求、修改记录中的信息，以及运行查询。用户可能是提交客户请求的支持代表，也可能是一个开发人员，质量工程师，信息开发人员，或者提交，分配，处理，解决，以及为一个产品特定发布版本进行变更请求确认的管理者。
管理员的角色用来对数据库、用户，小组进行管理，同时还包括安全策略的管理。一个管理员的常见任务包括配置和维护数据库、管理用户帐号，以及设置轻量级目录访问协议(LDAP)的授权。
方案开发者的角色包括大多数 ClearQuest Designer 中用建立方案的功能，这些方案将定义用户在 ClearQuest 程序用户界面工作的数据库。一个被执行的常见任务包含所有的方案设计以及开发，包括开发状态转变模型、记录、字段和动作类型，以及每个记录类型、字段和动作的行为，包括钩子(hook) 和脚本，同时还为 ClearQuest 客户端的用户开发窗体。
在许多变更管理的实现中，可能只有少数的方案开发人员和管理员，但是却有相当多客户端程序的用户——可能有几千的用户。在 IBM Rational 内部开发小组中的确是这样的，然而只有少数方案开发人员和管理员对 RATLC 方案进行支持，并继续进行完善。事实上我们许多客户的开发团队也是这样的。
然而，这些角色之间的界限是模糊的。比如，同一个人经常会同时担任着管理员和方案开发者的双重角色。类似地，钩子的编写者或者窗体的设计者也可能是安全策略的设计者或者管理用户组和许可(也叫做用户权限)的管理员。在 IBM Rational 也有这样的情况，可能有些用户有管理员权限可以创建查询并将它们保存到公共文件夹中，另外他们能够管理一些数据库，或者副本，或者用户和团队。
内部和外部的用户
在许多CM实现中，给定的角色可能要分配给内部和/或者外部的用户。对于各种不同的用户，像这样的角色从补充用例文档中受益是非常有可能的。
IBM Rational 内部的一个用户，属于 IBM 软件小组或者 IBM 内部的任何人，这些人可能在产品开发部门工作，创建新的用户界面，对 ClearQuest 产品或者组件进行集成工作，或者依靠 ClearQuest 核心功能或者服务进行软件应用的工作。维护 IBM Rational 的 RATLC 的开发人员他们本身就是 ClearQuest 方案 开发和管理人员角色文档的内部用户，作为其它地区的开发人员他们利用 RATLC 数据副本为 ClearQuest 的功能开发新的或者增强用户界面，或者进行测试产品的工作。对于 IBM Rational 的现场代表也是这样的，他们支持一个客户变更管理解决方案并需要方案开发的信息，或者一个客户支持代表可能会在用户管理部门回答一个客户的问题或者争论。一个新的雇员需要通过用户角色文档学习如何使用 ClearQuest 并成为一个很好的内部用户。
外部用户包括拥有自己的方案开发人员、管理人员的客户，或者合作伙伴，或者能为客户创建解决方案的独立软件开发商(ISV)。方案开发人员角色文档的目的是支持那些服务提供者或者技术专家，他们为客户开发方案，在有些情况下应用于一个内部小组，比如为他们的组织运行这个变更管理系统的内部全体IT小组。在有些情况下，对于规模大且高度自定义的配置，客户会为他们的客户端应用程序的用户文档创建一个附加层，这个应用程序可以提供一些详细信息，即不但可以用通用方式使用 ClearQuest，还可以进行一些特殊的实现。比如，产品本身能够提供关于创建和运行查询的信息，但是作为一个客户可能会对工作时的特殊查询创建更详细的文档，这个查询适用于特别的记录类型、字段、状态，或者在他们特定方案中定义的行为。
使角色更加具体化
从 IBM Rational ClearQuest 7.0.0 版本中开始，文档就是基于角色的，以便用来增加用户对每一个角色的体验。文档中定义的用户、管理员，以及方案开发人员的角色对于大多数行业--如果不是所有的--的CM系统是十分有用的。
但是CM系统中的这些通用角色是与行业无关的，在一个方案中定义的记录类型，及其状态和行为(状态转变模型)与安全的定义级别一样，都是高度自定义的，并可以用于多种行业和组织中——像角色本身一样。虽然用户的角色可能通用性的描述，但是它并没有详细地阐述具体的工作，比如数据输入人员、银行出纳员、贷款人员，或者客户支持代表。
例如，在 IBM Rational 软件开发组织中，一个用户角色的定义包括所有世界各地 RATLC 数据库镜像的用户。用户包括开发人员、测试人员、技术专家、产品和项目经理、处理客户解决方案的现场代表，核查正在进行的变更并且根据客户需求提交变更请求的客户支持代表，有时还包括合作伙伴或者那些能够有限制地访问变更管理系统信息的用户。
一些 CM 系统不但可以从不同角色的“个性化”用例中获得利益，同样可以从 ClearQuest 方案中的更专业化的角色中获得利益。