企业软件发布管理

图3. 软件发布记录的工作流

　软件发布记录是其它基于状态的记录类型的一个父记录，它向发布经理提供了发布的一个全局的视图，但是我确信，你正在问自己，怎样管理一个详细视图呢？

更深入一步进入过程，我们可以产生两个额外的基于状态的记录类型，事件（Incident） 和工作请求（Work Request）记录。

事件记录类型可被规类为缺陷、问题、风险、变更请求等等，由于这些不同的分类，事件记录类型有一个相当复杂的状态转换矩阵：

　图4. 事件记录
　
　事件记录类型获取描述信息、标题（一个简短描述）、所有人名称、优先级、严重度，以及相关软件发布记录、相关事件记录和相关工作请求。

当一个事件记录进入了 Slotted 状态，那么它一定跟软件发布记录是相关联的。

经常从用户那里听到的一个抱怨是，他们什么时候需要重新创建一个记录，因为把当前记录拷贝和粘贴到新的记录上是十分单调乏味的工作，虽然工作很简单但是很可能出错，比如粘贴一个值到一个错误的字段或者忘记将值从原始记录拷贝到新的记录。解决这个问题的办法是给用户一个不用拷贝和粘贴就可以克隆记录的方法。这样不仅创建了一个记录，并用来自原始记录的数据在板上进行组装，同时还在两个记录之间创建了一个链接。这个克隆记录的代码可以通过下面参考资源部分中 Shmuel Bashan 的 developerWorks 文章中得到。

developerWorks 上的代码必须分散到不同脚本中与各种事件类型一起操作。第一个脚本 clone_record.zip)是确定用户想要克隆的事件记录类型，它然后将执行适当的附加脚本来克隆这个记录。

使用 ClearCase/UCM/ClearQuest 实现集成的一个局限性就是一个记录只能分配到一个项目/流程/视图，并且一次只能一个人对它进行操作。然而，很可能有同时有好几个人操作一个变更或者他们可能在世界的不同地方，在不同的工作流程中对同一个变更进行操作。

为了克服这种局限性，你可以执行工作请求记录类型。工作请求记录类型是一个可以运用统一变更管理(UCM)包的基于状态的记录类型。

这个工作请求记录的创建必须来自于事件记录内部，因为许多数据元素是直接从事件记录拷贝到这个工作请求记录的，并且这两个记录后来是相互连接的。这个工作请求记录几乎是可任意使用的，它内部有一个非常短的生命周期，因为用户不需要输入很多数据，这个工作请求就可以很容易地被创建、分配、继续操作，然后关闭。一旦开发者完成了编码变更，通过了代码评审，单元测试变更的记录就将结束。它将提醒事件管理者，这个记录即将进入下一个状态。

这个工作请求记录的状态转换矩阵非常简单：

图5. 工作请求记录的状态转换矩阵