IBM Rational ClearQuest虽然本身不是一个软件部署工具，但是通过协助记录日志并跟踪部署历史记录和工件，消除手工步骤，将项目协调和时间安排连接在一起，可以帮助使部署过程自动化，并治理发布的工作流。请点击文章顶部或底部的讨论，参与论坛讨论，与其他读者分享您对本文的看法。
概述
此技术文章是面向从事软件构造和发布工作的专业人员以及变更和配置治理经理的，他们可能想要创建一个更正式的自动化部署过程。假定已经对IBM? Rational? ClearQuest?、软件部署和统一变更治理过程（UCM）有了一个基本的理解。
背景知识－－部署
在软件工程，以及Rational统一过程?（RUP?）中，部署的目的是将一个系统转移到其用户或利益相关者。在部署过程中所包括的是一组可以说明系统目的工件，用户或维护/治理培训材料，安装过程，资料单，当然还有可执行软件自身。
部署过程需要是可重现的、可控的和可跟踪的。为了达到这些目标，需要考虑以下关于工件部署的步骤。
工件必须被置于配置治理控制之下，并且已经基线化
假如需要，软件工件必须按照一种可控的和可重现的方式被构造（也就是被编译，等等）
软件工件必须被“打包”，并预备好进行安装
这可以是一个“zip”文件，文件被写到一张只读光盘上，或者通过创建一个Tivoli包来进行
工件必须被部署或转移到目标环境
为了正确的执行，工件必须被安装和配置
必须有文档工件来具体说明此过程中的步骤，创建一个工件的资料清单，并描述在工件中所发生的变更。
假如部署、安装和/或配置过程要碰到问题，必须要有返回过程和程序
许多组织需要验证和确认被部署到一个产品服务器环境下的正确工件。此外，他们必须能够返回到源代码工件来跟踪这些工件，并提供具体说明所有这些变化和核准这些变化的人员的文档。为了完全满足这些需求，以上步骤必须按照一种规范的和自动化的过程来进行。这有助于减少现有项目资源上的治理费用的数量，也可以使得过程变得更为可重现。
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。
对许多顾客来说，对于软件部署的最好的解决方案是使过程脚本化。这提高了现有项目团队成员的知识，相对更加轻易设置和维护，并且可以作为与软件构造中所使用的相同过程或工具类型的一个延续。脚本的使用使得过程可以重现，并且极大地减少了在任何手工过程中所固有的人为错误的风险。
在一个顾客的案例中，他们的构造和部署过程如下：
创建构造和部署代码所需的脚本
构造软件，并基线化ClearCase中的代码
将代码复制或FTP到开发测试环境中
在成功的单元测试和一些非正式的集成测试之后，为集成测试预备好代码
发送电子邮件到集成测试组成员，说明代码预备好进行集成“I”测试，并确定何时代码应当被部署
集成测试组成员通过电子邮件响应，说明他们何时预备好
软件被部署到“I”环境
执行集成测试
当集成测试完成和成功后，电子邮件被发送到质量保证测试团队，说明代码预备好质量“Q”测试环境
质量保证团队使用电子邮件响应，说明接受和部署时机预备好
相同的过程一直持续到部署到产品，或者“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记录类型来存储部署过程中使用的不同命令。这被定义成一个分开的记录类型（与之相反的是简单地使
