IBM Rational ClearQuest虽然本身不是一个软件部署工具，但是通过协助记录日志并跟踪部署历史记录和工件，消除手工步骤，将项目协调和时间安排连接在一起，可以帮助使部署过程自动化，并管理发布的工作流。

概述
此技术文章是面向从事软件构造和发布工作的专业人员以及变更和配置管理经理的，他们可能想要创建一个更正式的自动化部署过程。假定已经对IBM® Rational® ClearQuest®、软件部署和统一变更管理过程（UCM）有了一个基本的理解。

背景知识－－部署
在软件工程，以及Rational统一过程®（RUP®）中，部署的目的是将一个系统转移到其用户或利益相关者。在部署过程中所包括的是一组可以说明系统目的工件，用户或维护/管理培训材料，安装过程，资料单，当然还有可执行软件自身。

部署过程需要是可重现的、可控的和可跟踪的。为了达到这些目标，需要考虑以下关于工件部署的步骤。

1. 工件必须被置于配置管理控制之下，并且已经基线化
2. 如果需要，软件工件必须按照一种可控的和可重现的方式被构造（也就是被编译，等等）
3. 软件工件必须被“打包”，并准备好进行安装
   1. 这可以是一个“zip”文件，文件被写到一张只读光盘上，或者通过创建一个Tivoli包来进行
4. 工件必须被部署或转移到目标环境
5. 为了正确的执行，工件必须被安装和配置
6. 必须有文档工件来详细说明此过程中的步骤，创建一个工件的资料清单，并描述在工件中所发生的变更。
7. 如果部署、安装和/或配置过程要碰到问题，必须要有返回过程和程序

许多组织需要验证和确认被部署到一个产品服务器环境下的正确工件。此外，他们必须能够返回到源代码工件来跟踪这些工件，并提供详细说明所有这些变化和核准这些变化的人员的文档。为了完全满足这些需求，以上步骤必须按照一种规范的和自动化的过程来进行。这有助于减少现有项目资源上的管理费用的数量，也可以使得过程变得更为可重现。

ClearCase UCM和基线
请参见Jim Tykal的技术文章“ 在UCM中使用复合基线的最佳实践 可以得到UCM（统一变更管理）以及基线和复合基线概念的更多详细内容。在那篇文档中详细列出的这些术语和概念将会在本文的整个文档中被使用。

使用ClearCase创建和执行软件部署
在此案例研究中，IBM® Rational® ClearCase®正在被顾客用来进行UCM方式的软件配置管理。所有源代码工件按照ClearQuest活动进行checked out和checked in。Java代码使用ANT来进行构造和打包。在构造过程期间，创建UCM基线。

配置管理团队已经努力工作来自动化构造和部署过程，以增强质量，增加工作效率，并为其他项目构建一个可使用的框架。为了增加通告和信息，构造和部署脚本与一个Web入口集成在一起，确定部署的特定状态（红色－－失败的部署，黄色－－进行中的部署，绿色－－成功的部署）和相关联的ClearCase基线标签。批准过程以及记录和跟踪所有必需的部署历史和批准工件的要求，对于脚本化来说太多了，如果不创建一个定制的软件工具很难进行处理。即使对于最热心的工具人员，这项任务也会成为一个挑战。然而，顾客非常幸运，配置管理团队成员充分理解到有更好的方式管理此工作流程和必需的工件。

使用ClearQuest管理软件部署
首先，让我们直接设置一下记录。ClearQuest不是一个软件部署工具。软件部署可以手动执行（例如，使用FTP命令），可以被脚本化，或者可以通过企业级工具来实施，例如 IBM Tivoli Configuration Manager。

对许多顾客来说，对于软件部署的最好的解决方案是使过程脚本化。这提高了现有项目团队成员的知识，相对更加容易设置和维护，并且可以作为与软件构造中所使用的相同过程或工具类型的一个延续。脚本的使用使得过程可以重现，并且极大地减少了在任何手工过程中所固有的人为错误的风险。

在一个顾客的案例中，他们的构造和部署过程如下：

1. 创建构造和部署代码所需的脚本
2. 构造软件，并基线化ClearCase中的代码
3. 将代码复制或FTP到开发测试环境中
4. 在成功的单元测试和一些非正式的集成测试之后，为集成测试准备好代码
5. 发送电子邮件到集成测试组成员，说明代码准备好进行集成“I”测试，并确定何时代码应当被部署
6. 集成测试组成员通过电子邮件响应，说明他们何时准备好
7. 软件被部署到“I”环境
8. 执行集成测试
9. 当集成测试完成和成功后，电子邮件被发送到质量保证测试团队，说明代码准备好质量“Q”测试环境
10. 质量保证团队使用电子邮件响应，说明接受和部署时机准备好
11. 相同的过程一直持续到部署到产品，或者“P”环境。

在上面的工作流中，有几个步骤将需要手工工作和协调。例如，尽管被发送给测试团队的电子邮件可以使用脚本进行自动化，但是监测来自测试团队的电子邮件的响应现在还是一项手工工作。阅读电子邮件响应，确定团队是否准备好新软件的过程，以及软件何时应当被部署到目标环境中，要花费时间和大量的通信。在此过程中，至少对于某些顾客，此通信过程可以被打断－－或者整个中止。随着部署工件接近产品准备就绪阶段，更多的正式批准是必不可少的，并且对更好的计划和沟通部署的需要也是必要的。

进入ClearQuest
顾客将ClearQuest用在Microsoft Windows工作站上的所有软件开发上已经大约一年了。所有软件变更请求和问题都存储在ClearQuest中。

对于部署跟踪的ClearQuest实施相对比较简单。创建用于跟踪部署的记录，一个记录类型为批准记录，一个记录类型为应用程序，还有一个记录类型为角色－－这样就准备好了解决方案的基础。有一些其它记录类型，可以使用户界面、选择和跟踪过程变得更容易一些，这些记录类型将在稍后论述。

图1显示了不同的记录类型之间的关系。UCM_Project记录是一种被使用的记录类型，是由ClearQuest框产生的。其它记录类型是为此实施特定创建的。

图1：不同记录类型之间的关系

为描述整个环境，我们将以分块开始，逐步建立部署记录。

TIQP_Environment记录用于存储有关不同服务器设备的信息。在此特殊的顾客测试环境中，每个环境包括一个用于一个特殊应用程序的服务器（至少在本方案开发期间的初始阶段中）。一个服务器可能作为多个应用程序的宿主，但是一个应用程序只能位于一个服务器。TIQP_Environment记录确定服务器的名字、IP地址、部署环境的类型（T：开发者测试；I：集成测试；Q：质量保证和性能测试；或P：产品），以及几个其它字段。

role记录类型用于为每个应用程序确定一个特殊的用户“角色”。每个应用程序定义的角色至少包括一个应用程序或程序经理和一个被分配到每个测试环境的测试员。role记录类型包括的字段要确定“角色”名，该角色所应用到的应用程序，一个简要描述信息和一个被分配到应用程序角色上的用户的参照列表。用户可能被分配到一个应用程序中的多个角色，并且一个用户也可以被分配到相同或不同角色的多个应用程序。

application记录用于确定应用程序名，与应用程序相关联的环境，此应用程序的批准人和可以被执行以完成源代码构造或编译和代码迁移的（多个）命令。可以是多个命令的原因是由于代码可能需要使用调试参数进行重新构造，或者可能需要在迁移之前进行卸载，执行安装或简单地更新一些文件。不同的应用程序有不同的安装、配置和卸载需求，因此就需要有多个脚本的能力。application记录要求确定ClearCase UCM项目。当一个部署被完成时，执行部署的人员要选择一个必须与application中确定的UCM_Project相关联的ClearCase基线。application记录需要在“Approvals_for_I”、“Approvals_for_Q”和“Approvals_for_P”字段中确定角色。这些字段是参照列表，因此批准过程可以要求多个角色。deployment记录的实际批准过程将会在本文中后面进一步详细描述。

Application记录也包括定义Issue和ChangeRequest记录参照的字段。这些关联用来确定一个特定的Issue或ChangeRequest被关联到哪一个application。对于小的ClearQuest部署－－每个项目或应用程序有其自己的数据库，这不是真正必需的。然而，如下一段落所讨论的，为了达到集成和报告的目的，时常会在一个单独的数据库中包括多个项目。

此顾客的初始ClearQuest构架是要对每个项目有一个ClearQuest用户数据库。在产品环境中，多个项目会集合在一起形成可交付产品。此构架对每个团队都运行得非常好，因为问题和变更请求被隔离起来并且容易进行管理。然而，这种实施对于不同的系统测试团队进行得不太好。如果一个测试团队的成员在测试中发现一个问题，测试团队成员将必须判断出此变更请求应当归于哪个项目，然后到特定的ClearQuest用户数据库去，并且如果测试团队成员在错误的数据库中输入了变更请求，那么一旦找到了正确的数据库，就要必须手动将数据复制到正确的ClearQuest用户数据库中。最后的抱怨是测试人员不能跨多个不同的ClearQuest用户数据库创建报告来确定哪些变更请求已经被完成了，而这样可以使测试团队执行回归测试。要下决心开始计划将不同的ClearQuest用户数据库迁移到一个更大的数据库，这样可以满足测试团队利益相关者的需要。在计划此迁移中，application字段被用在Change Request和Issue记录类型上。

创建Deploy_Cmd记录类型来存储部署过程中使用的不同命令。这被定义成一个分开的记录类型（与之相反的是简单地使用application记录中的字段），这样就可以使用适当的权限控制来限制修改和增加。Deploy_Cmd记录类型有四个字段，一个name字段，一个description字段，一个用于脚本命令的multi-line字段和一个active字段。在部署命令不再被使用或有效的情况下，一个有合适权限的人可以将此命令标记为inactive，此命令就将不再在ClearQuest中被执行了。

图1显示了一个UCM_Baseline记录类型。此记录类型的存在受到了争议。为了此部署实施的目的，执行部署的人必须选择一个适用于被部署应用程序的UCM基线。在此实施中，我们要么可以在创建一个UCM基线时，或者是在一个UCM基线达到一个特定晋升级别时创建一个UCM基线记录。作为替代，可以从一个动态创建的选择列表中选择UCM基线。此解决方案的初始原型利用了UCM baseline记录类型，但随后的迭代规定了此信息除了ClearCase中可用数据的一个复制外没有其它内容。创建此记录类型的一个原因是考虑到了哪些可能没有在工作机上安装ClearCase或使用ClearQuest Web的用户。然而，在复审工作流中，一个使用部署的用户为了访问工件被要求安装ClearCase，这样用户就有权使用基线信息。唯一其它的想法是，当一个UCM Baseline达到一个特定晋升级别时，通过创建一个UCM_Baseline记录，将会减少可以被选择的可用基线的数量，并增加基线创建和选择权限的另一个可能的级别。

在讨论Approval记录类型之前，需要描述deployment记录类型，并说明一下过程。然后approval记录就不用加以说明了。

Deployment记录类型包括以下字段：

• ID
• App_Deploy_Cmd    > REFERENCE                 >Deploy_Cmd
• Application_ID                > REFERENCE                >Application
• Approvals_For_I          > REFERENCE_LIST > Approval_Record
• Approvals_For_Q      > REFERENCE_LIST > Approval_Record
• Approvals_For_P        > REFERENCE_LIST > Approval_Record
• Baseline_or_Stream
• Baseline
• Deploy_I_Log
• Deploy_Q_Log
• Deploy_P_Log
• Deploy_To                            > REFERENCE                     > TIQP_Environment
• UCM_Project
• UCM_Stream

Deployment记录窗体按照如下建立（ 注意：在这里没有显示所有的页签。History、Notes和Attachments页签包括了标准的ClearQuest字段，不保证任何额外的讨论。）

图2：Main页签

图3：T And I Deployment Log页签

图4：Documentation页签

图5：Approval Process页签

Deployment记录的状态图如下：

图6：Deployment记录的状态图

当一个应用程序准备好部署时，将会使用应用程序信息创建一个新记录，并且deployment记录进入Ready_for_T状态。

当deployment记录转换到一个要求批准的状态时，创建approval记录。在此转换期间，application记录－－包含被确定为必需的批准人的角色－－被读取，指示要发生部署的授权需求。对于每个被确定用于批准的角色，创建一个相关联的approval记录。作为一个例子，假定application记录确定来自项目负责人和集成测试经理的批准需要优先于到“I”的部署。当deployment记录进入Ready_for_I状态时，将会创建两个approval记录，一个用于团队负责人，另一个用于集成测试经理。这些approval记录在“Submitter”状态中创建。一直到这两个approval记录都处于“Approved”状态，deployment记录才能转换到Approved_for_I状态。这样这种实施提供了对批准过程的“who”和“when”的可追溯性。通过使用e-mail规则，用户可以在需要他们的批准时得到通知。

ClearQuest中的一个限制是不能自动地将记录转换到一个状态。关于Deployment记录，一个希望的特性是在所有的批准者将他们的批准记录转换到“Approved”状态后，将记录转换到“Approved_for_I”状态。为了提供此功能，Rational e-mail reader可以通过对approval记录的hook来进行配置和应用，这样当最后的approval记录被移到“Approved”状态时，一封电子邮件就被发送到e-mail reader账号。电子邮件提供了执行到“Approved_for_I”状态的转换的必要信息。如果不使用e-mail reader，一个用户将被要求手动执行此转换。

一旦部署到一个特定环境的部署记录被批准，授权用户就可以执行此部署。在执行期间，要选择和执行环境和命令。然后，命令执行的结果被记录到一个multi-line string字段中。除了脚本的输出之外，执行部署的用户的ClearQuest用户名被放在字段中，还有执行的时间和日期，环境信息和命令记录信息。这提供了部署事件的完全审计跟踪。为了对所有部署命令和脚本提供一致的结果，应当建立标准以使得对所有部署命令可得到相似的输出。

对于进行频繁部署的团队，此实施的第一印象是这会要许多管理费用。如果需要部署三个应用程序，就需要创建三个记录，approval等等。如果其中一个部署失败了并且需要一个新基线，就需要一个新的deployment记录。关于此顾客，许多团队表示了相同的情况。一个团队每天部署相同的应用程序3-5次并不是罕有的。此实施的另一个方面是，可以产生报告显示由一个团队或对于一个应用程序所进行部署的数量。从一个测试团队成员的观点来看，他们正在期待此实施。测试团队厌烦了一个团队将代码仍上去只是忘了几个文件，然后又重新去做一遍。很多次没有告诉测试团队新的代码何时准备好，或者已部署的代码还不可运行。ClearQuest部署过程考虑一些部署成功的说明性和验证。测试团队相信通过跟踪部署和成功标准，开发人员被要求要花更多的时间来确保代码和部署在部署之前将是成功的，而不是期望测试团队来告诉开发人员部署是成功了还是不成功。

作为最后的注释，要小心这不是一个完全安全的解决方案。此解决方案利用了ClearQuest的特性和功能来增加授权和安全级别。然而，因为此实施要让ClearQuest执行命令行脚本，脚本的手动执行就可能让ClearQuest环境中的强制授权无效。

总结
通过工具中的已有投资的使用，使用知识和专业技术已经建立在工具和过程中，此顾客能够显示出部署过程的批准和可追溯性的需求可以在一个较短的时段内和以一种相对便宜的方式来实施。下面的工作流现在可以用于跟踪一个软件系统的部署：

1. 创建需要构造和部署代码的脚本
2. 构造软件并在ClearCase中建立代码基线
3. 使用ClearCase中的基线信息创建一个deployment记录
4. 确定“T”环境，并执行代码部署
5. 在成功的单元测试之后，将deployment记录的状态改为“Ready_for_I”
   1. 自动产生电子邮件
   2. 自动产生approval记录
6. 批准人登录进入ClearQuest，并批准deployment记录
   1. 当所有批准都完成时，记录就可以自动地转换到“Approved_for_I”状态
7. 配置管理团队执行到“I”环境的部署脚本，并且输出被记录到ClearQuest中
8. 对于“Q”和“P”环境继续此过程

通过ClearQuest，由协调和记录日志的手工任务所需要的管理费用的数量大大地减少了。配置管理团队可以集中在构造和发布任务，以及改进要开发并与其他团队共享的ANT框架上。

此实施满足或超过了审计需求，不同角色的批准、历史记录的跟踪和日志和部署的救国。此实施的成本是比较低的，环境容易维护和更新，要求非常少的额外培训，并且节省了手工任务所要求资源的时间和工作量。

对于此特定的顾客－－有一个非常特定的工作流，一个良好定义的部署过程，以及特定的跟踪需求－－ClearQuest提供了可以满足许多相关利益者需求的一个解决方案。