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

longpan

　　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 和 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。
回页首
　　一个样例用例
　　本小节的用例展示了如何使用 CLM (Collaborative Lifecycle Management) 镜像上的 Build Forge Agent 来从控制台驱动构建。本场景使用了如下的用户和角色：

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

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

• Tanuj 审查各种需求并决定团队将要满足哪个需求。
  
• Tanuj 登录到 Rational Team Concert，创建一个故事并将其分配给 Bob 在迭代开发过程 1 中完成。
  
• Tanuj 接着登录到 Rational Quality Manager 并创建一个测试计划来测试在迭代开发过程 1 中所添加的特性。
  
• Bob 估算完成这个故事所需时间，完成它，将它交给 Tanuj 审查，然后交付它。
  
• 与此同时，Bob 还创建了一个 Rational Quality Manager 测试用例用来链接到由 Tanuj 所创建的计划。
  
• 通过利用 CLM 实例上的代理开启夜间构建，定义一个 Build Forge 项目。
  
• 针对每夜构建的 Build Forge 项目启用，会获得一个供测试用的 spin/build。
  
• Bob 利用该构建来对他的交付进行质量检测。
  
• 质量检测完毕后，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 和对应需求也是如此。
回页首
　　结束语
　　本文展示了 IBM Rational Build Forge Agent 在后台的工作方式，以便帮助客户在 IBM Cloud  上和普通云环境中实现构建、测试和修复包应用程序 (pack-application)  的自动化。能够对应用程序开发和部署的构建、测试和维护阶段进行自动化是一种 明智的省时又省力的工具，应该成为您云环境工具箱中的一部分。