使用 Rational Build Forge 自动化 IBM Cloud 上的构建和发布过程

IBM Rational Build Forge 是一种自适应的过程执行框架，可自动化、管理和跟踪软件开发中所涉及的每个组件之间的过程，换言之，它是自动化软件工厂的第一步。它支持主要的开发语言、 脚本、工具和平台，并可轻松地集成至包括 IBM SmartCloud Enterprise 在内的许多环境中。

实际上，将 Build Forge 的自动化的开发特性与 IBM Cloud 的广泛延伸和应用程序部署特性结合起来可帮助您创建一个功能强大而又高度自动化的软件流水线。

本文介绍了过程自动化的全过程，细述了 Build Forge 技术，给出了为何 Build Forge 和 IBM Cloud 的结合对开发人员极其重要的原因，并且谈论了如何集成这二者。本文还提供了一个详细的用例作为例子，并介绍了有关替代用例的一些想法。

过程自动化背后的过程

过程自动化可以让企业对异构应用程序、人和系统过程进行精心编排以消除低效、优化成本、确保兼容性和提升生产力。Rational Build Forge 可自动化、协调、管理和跟踪产品开发流水线中的每个过程。它常被用来自动化软件构建和打包过程。

在本节中，我们旨在向您介绍基于人模型的过程并将其映射至 Build Forge 特性。过程自动化的这个模型包含如下角色：

• 要完成的工作是一组文档化的过程。每个过程由若干任务组成。
• 协调员 “运行” 工作。协调员选择要运行的过程，然后按顺序检查这些任务。对于每个任务，均由过程定义该任务应该由哪个 worker 执行。协调员将任务交给该 worker，然后等待结果。
• 该 worker 执行过程所定义的这个任务。

回页首

技术背后的技术

正如之前提到的，Build Forge 是一个自适应的过程执行框架，可自动地管理软件开发流水线中的各个过程。现在，让我们来看看 Build Forge 的一些组件。

在使用 Build Forge 时，如下这些组件很关键：

• 数据库：Build Forge 使用该数据库来存储它使用的所有对象。
• Build Forge 系统：一组可监管数据库的访问、运行 UI 代码以及执行运行作业工作的技术。
• Agent：在即将执行工作的每个主机上安装代理软件。
• Web 浏览器：用户通常会通过一个 Web 浏览器中显示的控制台来访问 Build Forge。

IBM SmartCloud Enterprise 是构建在敏捷的云基础设施之上，这种基础设施旨在为客户提供对安全性丰富的企业级虚拟服务器环境进行快速访问，非常适用于开发和测试活动。由这个解决方案 带来的灵活配置特性可在成本预知的情况下按您所需访问 IT 资源。IT 人员无需再花费宝贵的周期来部署、配置和维护开发和测试环境。

IBM Cloud 提供了一种自助的测试平台，旨在简化使用。它组合了服务请求管理、自动配置和配置管理以便按需配置物理和虚拟化测试资源，其中包括诸如操作系统、中间件、存储、网络、图像和数据等 IBM 和非 IBM 组件。

回页首

集成 Build Forge 和 IBM Cloud 的益处

图 1 所示的是 Build Forge 模型：

图 1. Build Forge 模型

之前章节中提到的基于人的模型按如下所示映射到 Build Forge 模型：

• 在 Build Forge 项目对象中定义工作过程。每个项目包含一个或多个步骤对象。项目中的步骤对应于基于人模型的过程中的任务。
• 协调员就是运行中的 Build Forge 软件。它包含一个称为过程引擎的组件。当在 Build Forge 中启动一个项目时，这个过程引擎就会作为一个作业对象来运行这个项目。一个作业就是一个运行中的项目。
• Worker 是主机。在 Build Forge 中它们由服务器对象来表示。主机上必须安装一个代理。

以上是一个非常简化的模型。

• Build Forge 包含许多其他的对象类型来支持过程自动化。支持服务器和项目的用户、授权和其他对象均存储在数据库中。Build Forge 的部件也存储在数据库中，比如 UI 小部件。要运行 Build Forge，数据库必须运行。
  
• 可将项目和步骤配置成以很多不同的方式运行来支持具有复杂依赖性和工作流的复杂过程。项目可运行其他项目，而步骤本身也可运行项目。
  
• 步骤和项目可基于条件数据（服务器定义的一部分）来动态选择服务器。比如，某个步骤可以基于它运行的是 Windows® 还是 UNIX®/Linux® 来选择在哪个服务器上运行。服务器还可以配置成一个池化了的资源，以便某个步骤可以基于其当前的可用性或负载来选择一个服务器。

IBM Cloud 上的 Build Forge

用 Build Forge 自动化 IBM Cloud 上的构建可改善构建结果、减少风险，以及节省时间。它还能省掉硬件需求和采购的项目计划，同时提高实验室资源的利用率。

通过快速组装或分拆配置，它还为企业提供了一种利用动态基础设施的方式；这种灵活性可很大程度地节省时间。

IBM Cloud 中的 Build Forge 有助于处理这样的一些情况，比如团队/组织需要即刻拥有超额容量来应对额外的工作负载，进而消除了为了短期使用而寻找额外未使用的可用硬件的需要。

与其他产品的集成

将 Build Forge 与其他 Rational 产品集成可带来许多益处。这些 Rational 产品在软件开发生命周期中非常重要：IBM Rational Team Concert (RTC)、Rational Asset Manager (RAM)、Rational Quality Manager (RQM) 和 Rational Requirements Composer (RRC)。

• 将 Build Forge 与 Rational Team Concert 集成在 IBM Cloud 上可为开发人员团体提供在多个平台上使用相同实用工具进行软件构建和执行的附加优势。这种集成避免了开发人员必须转到其他工具或脚本来进行构建和健康检查 (sanity check) 的需要。此配置优化了多个用户对软件工具和框架的使用。它还可以让用户和发布工程师使用相同的界面和工具同时构建产品，避免出现多个副本的构建环境。目前 在 IBM Cloud 中可用的是版本 3.0.1。
  
• 将 Build Forge 与 Rational Asset Manager 集成可以为想要适应云的组织提供一个理想的组合。这种集成提供了一种简单的方式可在云上配置/去配置镜像。Rational Asset Manager 有助于维护资产，而 Build Forge 可自动化特定软件的镜像配置。因此，这种集成可总体促成了云解决方案的形成。相同原则的适用范围可扩及云中的应用程序，在这里组织或企业可在 Rational Asset Manager 中维护所分配的资源/资产，而 Build Forge 则可用来按用户请求访问这些资产。开发人员也可以参考在 RAM 中维护的资产来做构建。他们可以使用 Build Forge 来创建一个基于 Rational Asset Manager 中资产的构建。所创建的这些构建可以作为新资产在 Rational Asset Manager 中重新发布。
  
• 与 Rational Quality Manager 集成，Rational Build Forge 服务器和项目就能够在 Rational Quality Manager 的 Lab Management 子系统中可见了。您可以选择在一个或多个实验室资源上执行一个自动化项目。再者，可以在 Rational Quality Manager 中构造复杂的测试场景，其中包含一个搭建阶段、一个自动化测试套件执行阶段和一个拆除阶段。测试台的搭建和拆除可以是 Rational Build Forge 中的自动化项目。Rational Quality Manager 界面只需要求 Rational Build Forge 执行一个自动化项目并等待结果，再转到下一个步骤。在 IBM Cloud 中可用 Rational Quality Manager V3.0.1。
  
• Rational Requirements Composer 可帮助团队计划其需求。更好的质量需求、有效的管理和良好的处理可减少返工、缩短上市时间、降低成本以及改善整体效果。Rational Requirements Composer V3.0.1 带来的是一个集定义、管理、可追溯性、模板、历史、审批、任务管理、规划、共享过滤器与视图、可定制仪表盘和报表为一身的强大组合。将 Rational Requirements Composer 与 Rational Team Concert 和 Rational Quality Manager 集成可以通过 viewlet 实现数据共享，并充许您使用自己所喜爱的 Web 浏览器进行数据访问。在 IBM Cloud 中可用 Rational Requirements Composer V3.0.1。

对于 IBM Cloud 中的 Rational Team Concert、Rational Quality Manager 和 Rational Requirements Composer，可以将它们看作 IBM Rational Collaborative Lifecycle Management (CLM) 2011。

回页首

将 Build Forge 集成到 IBM Cloud

本节将介绍几个 IBM SmartCloud Enterprise 的用例。在开始讨论这些用例之前，有必要先来了解如何使用 Build Forge 控制台连接到一个代理。

手动配置控制台上的 Build Forge Agent

当云中配备了两台机器（一台安装了 Build Forge，另一台安装了 Build Forge Agent），就可以同时使用这两台机器了：

1. 首先，确保可以连接到 Build Forge 管理控制台。要测试这一点，可以尝试通过浏览器访问 http://<machine-ipaddress> 或 https://<machine-ipaddress>（取决于运行控制台服务的那台机器是否启用了安全性）。如果不能访问，就需要启动 Build Forge 服务。
   • 在 Windows 中：导航至 Services 面板，选择 IBM Rational Build Forge Management Console，然后启动此服务。
   • 在 Linux 中：键入 <install-location>/rc/buildforge start 来启动 Build Forge Console。
   
   
2. 同样地，请确保 Build Forge Agent 在第二台机器上已经启动并正常运行。
   • 在 Windows 中：导航至 Services 面板，选择 IBM Rational Build Forge Agent，然后启动此服务。
   • 在 Linux 中：键入如下内容：

     telnet <machine-ip> <port on which the agent is installed> For e.g., telnet  129.35.208.53  5555 200 HELLO - BuildForge Agent v7.1.1.3-0-0034 

     
     
   
   
3. 现在，您就可以通过浏览器连接到 Build Forge Management Console。
   
4. 在系统中创建任何项目之前，您必须至少定义一个服务器。要定义一个服务器：
   1. 导航至 Servers > Server Auth > Add Server Authentication。在 Details 选项卡上，添加运行代理的这个服务器的身份验证信息。请参见图 2。
      
      图 2.
      
      
      在本例中，bfagentuser 是用来登录到运行代理的这台机器的用户名称。
   2. 导航至 Selectors 页并添加一个选择器，如图 3 所示。
      
      图 3.
      
      
      以上将 CLMMACHINE-Selector 定义为一个选择器，并将变量 BF_NAME 设置为下一步将要定义的这个服务器的名称-CLMMACHINE。 （CLM 是 Collaborative Lifecycle Management 的缩写。）
   3. 导航至 Servers > Add Server。提供运行代理的这台服务器的名称及其他细节信息。图 4 显示的这个例子使用 CLMMACHINE 作为服务器名称。
      
      图 4.
      
      
      
   4. 要验证代理是否配置正确，单击 Test Connection 并确保服务器名称左侧的 Servers 列中会显示一个绿色图标。
   
   
5. 在成功配置、验证代理正常运行且通过 Console 成功连接后，就可以在该机器上启动任何过程了。比如，可以创建任何项目并选择 CLMMACHINE-Selector 作为选择器。在此项目中，可以添加在远端代理机器上运行动作的步骤。这些动作可以是一个简单的回音测试命令，也可以是一个由代码、构建和运行自动化测试组成的项目。

在 Build Forge 云实例上自动配置一个 Build Forge Agent 云实例

成功获得 IBM Cloud 的 Build Forge 镜像之后，就可以从 IBM Cloud 网站为 Build Forge Agent 请求一个镜像了。

1. 登录 到您的 IBM Cloud 帐户。
2. 在 Control 面板选项卡上单击 Add instance。
3. 选择 IBM Rational Build Forget Agent 镜像。
   
   图 5. 为代理请求一个镜像
   
   
   
4. 单击 Next。
5. 添加有关 Build Forge Console 镜像的信息。
   
   图 6. 添加此代理镜像的更多信息
   
   
   
6. 单击 Next。
7. 遵循随后的步骤来添加所请求的实例并提交此请求。这个过程会自动将这个代理机器添加到 Build Forge Console。

回页首

一个样例用例

本小节的用例展示了如何使用 CLM (Collaborative Lifecycle Management) 镜像上的 Build Forge Agent 来从控制台驱动构建。本场景使用了如下的用户和角色：

• Bob 是开发人员。
• Tanuj 是项目主管。
• Ursula 是管理员。

这个用户场景的步骤总结如下：

1. Tanuj 审查各种需求并决定团队将要满足哪个需求。
2. Tanuj 登录到 Rational Team Concert，创建一个故事并将其分配给 Bob 在迭代开发过程 1 中完成。
3. Tanuj 接着登录到 Rational Quality Manager 并创建一个测试计划来测试在迭代开发过程 1 中所添加的特性。
4. Bob 估算完成这个故事所需时间，完成它，将它交给 Tanuj 审查，然后交付它。
5. 与此同时，Bob 还创建了一个 Rational Quality Manager 测试用例用来链接到由 Tanuj 所创建的计划。
6. 通过利用 CLM 实例上的代理开启夜间构建，定义一个 Build Forge 项目。
7. 针对每夜构建的 Build Forge 项目启用，会获得一个供测试用的 spin/build。
8. Bob 利用该构建来对他的交付进行质量检测。
9. 质量检测完毕后，Bob 在 Rational Requirements Composer 中将该需求标记为 complete。

现在，让我们来仔细分析一下这个用例。

NewIdeas 的团队刚刚赢得一个银行客户的订单。该团队的任务是设计出一个存储银行客户日常交易的金融解决方案。

NewIdeas 非常兴奋；他们已经决定采用 IBM SmartCloud Enterprise 提供的 CLM 解决方案并辅以 Build Forge Agent 提供的从 Build Forge Console 驱动客户机（在本例中为 CLM 服务器）上动作的能力。

Tanuj（项目主管）负责此项目。他与客户进行了谈话，并对此银行系统框架提出要求。他的团队需遵循敏捷的开发过程。他使用 Web 客户机登录到 Requirements Management 并创建了要满足客户机测试版的迭代开发过程 1 的一个需求，如图 7 所示。

图 7. 对迭代开发过程 1 的要求

他接着会登录到 Rational Team Concert 并创建了一个任务交给 Bob（开发人员）来处理，如图 8 所示。

图 8. Bob（开发人员）处理这个任务

与此同时，Tanuj 会登录到 Rational Quality Manager 并创建一个测试迭代开发过程 1 中特性的测试计划。此计划归 Tanuj 所有，如图 9 所示。

图 9. 针对迭代开发过程 1 特性的测试计划

Bob 然后登录到 Rational Team Concert 并开始处理分配给他的任务。他会对这个任务进行评估并随后实现/完成它。之后，再将任务交给 Tanuj 审查并签入代码。

代码签入后，Ursula（管理员）拥有一个夜间构建，每次项目区发生变化就会触发该构建。该构建启动，并且会有一个构建可用于质量检测。

如图 10 所示，Bob 签入后，Build Forge 作业就开始运行于 CLM 服务器上。Build Forge 项目中的所有步骤都完成后，就可以对该构建进行测试了。

图 10. 可以测试的构建

需要指出的重要一点是 Ursula 在 CLM 服务器上配置了 Build Forge Agent。Build Forge Console 会配置好一个服务器来利用代理在 CLM 实例上运行构建。因此，通过使用 Build Forge Agent 和 Build Forge 的自动功能，Ursula 就能生成一个构建。

Bob 接手这个构建并开始从事于附加到 Tanuj 创建的计划中的 Rational Quality Manager 测试用例。如果存在任何 bug，就会记录到 Rational Team Concert 中。之后，他会着手处理这些漏洞，对其进行检查，然后完成交付。修复的构建可用后，Bob 就可以利用它来进行功能的交叉检查。当构建通过所有的条件后，每个 Rational Quality Manager 测试用例都会被标记为完成；Rational Team Concert Story 和对应需求也是如此。

回页首

其他的用例

除了构建自动化之外，Build Forge 和 Build Forge Agent 还可用于其他的自动化任务，其中包括：

• 测试自动化。
• 修订包应用程序。

对于测试自动化，通常只要生成一个构建，就可能会有一些测试用来测试此构建的健康性。这些测试就是所谓的 Build Verification Test 或 BVT。这些 BVT 在很多组织中通常都是通过手工完成的；但是，BVT 测试可很容易地自动完成。

要自动化 BVT，构建需要存储在已经安装了 Build Forge Agent 的一台机器上。生成构建的 Build Forge Console 就可用来连接到具有这个构建的代理机；而这些 BVT 也就可以运行来检查构建的健康性了。

除了 BVT，很多团队还会使用 Build Forge/Build Forge Agent 技术运行它们的 Functional Verification Test (FVT)。

对于修复包的应用，很多企业都在多个机器、多个平台上安装了像 WebSphere® Application Server 这样的服务器，这意味着这些服务器的修复包可能会每两三个月发布一次。 如果企业具有数百个这样的服务器，手动运行所有这些机器上的升级是一件烦人的差事。

在这些情况下，可将 Build Forge Agent 安装到这些机器上，修复包应用程序的整个过程都可使用 Build Forge 项目自动完成。这节省了用户时间以及单调的手工操作。

回页首

结束语

本文展示了 IBM Rational Build Forge Agent 在后台的工作方式，以便帮助客户在 IBM Cloud 上和普通云环境中实现构建、测试和修复包应用程序 (pack-application) 的自动化。能够对应用程序开发和部署的构建、测试和维护阶段进行自动化是一种 明智的省时又省力的工具，应该成为您云环境工具箱中的一部分。