利用 Rational ALM 工具使持续部署变得切实可行且具成本效益

使用 Rational 软件与云可以节省时间和精力、降低风险并改善治理

持续部署意味着将软件变更部署到一个开发、测试、预生产或生产环境中。该过程类似于通过持续编译和持续集成来构建每一个变更。Steve Arnold 概述了这种方法的三个主要挑战:设计、自动化和治理。然后他还解释了如何将用于 ALM 的特定 Rational 工具与云相结合,使持续部署变得切实可行且具有成本效益,因为持续部署可以减少测试和部署工作、改善治理并降低部署到生产环境中的风险。

Steve Arnold, 高级技术顾问, IBM 

Steve ArnoldSteve 与他的妻子和小女儿一起居住在伦敦特威克南。自 2000 年起,他一直是 IBM Rational 软件的一名技术顾问。他还是一名获得认证的 Scrum 专家,专长于敏捷项目交付、建模和基于模式工程方面的工作。工作之余,他喜欢与家人呆在一起,研究、传授和练习太极拳。他曾写过几篇介绍 Rational Software Architect V7.5 和 V8 的最新特性的文章,还写过一些讨论 Rational Software Architect 的不同扩展、Rational RequisitePro 和 Rational Team Concert 的文章。



2012 年 6 月 04 日

下载 Rational® Software Architect 试用版  |  Rational® Quality Manager 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

什么是持续部署,为什么对它感兴趣,它有助于解决哪些问题?

对于许多组织来说,业务和开发团队的愿望是更快、更频繁地生产可用软件,而运营团队的责任是以规避风险的方式管理组织的基础架构,从而确保业务的连续性,在这两者之间,往往存在着分歧。不幸的是,这种分歧往往导致将开发团队所 “完成” 的功能块部署到生产中的时间大幅延迟。然而,为了确保可以安全地部署变更,并且不会导致系统可用性的损失,延迟往往是必要的。此延迟是由于必要的严谨以及降低风险所需的流程导致的,因为部署流程往往包括许多之前几乎没有做过的手动步骤。因此,许多组织的部署往往在周末进行,这被认为是非常危险的,而且常常会失败。

持续部署是将每个软件变更部署到一个环境中的流程,该环境有可能是开发、测试、预生产或生产阶段。这类似于许多人使用持续集成来构建每个变更的方式。这种做法意味着,无论何时签入变更,持续部署流程都会确保该变更可以成功地部署。所以,持续部署不仅消除了部署阶段中手动的、高风险的步骤,并且在您开始将它部署到生产时,它实际上是一项普通的日常工作(不会比编译一块源代码的风险更高),而不是第一次执行一项新工作。

这为组织提供了多种好处:

  • 更少停机时间和更多升级,从而带来更好的生产力和软件的增值。
  • 业务可以更快速获得软件变更,所以您可以提高您在软件开发上的投资回报。
  • 测试团队在配置环境和部署软件上花费的时间更少。
  • 更早发现回归缺陷,因此可以用更少的时间和更低的成本来解决它们。

如果这听起来有点牵强,持续部署的另一种考虑方法是,它是现有方法的逻辑发展。在 21 世纪初,有些实践变得很普遍:大多数 IDE 生成的持续编译(在保存文件时编译代码),以及持续集成(已经构建了代码,并且在将代码签入源代码控制时,会运行一组单元测试)。这些实践都提高了生产率。持续编译提高个人的生产力,而持续集成则提高开发团队的生产力,持续部署是通过自动化和减少发布风险来提高组织生产力的一个自然发展趋势。小型变更可能很容易部署,因此您可以从软件中更快、更频繁地获得价值。

图 1. 持续编译、集成和部署的价值
该图比较了 3 种持续更新

持续部署可以提供许多强大的好处,但在成功实现它时会遇到一些独特的挑战。本文的其余部分将更深入探讨这些挑战,并解释 IBM Rational ALM 解决方案如何克服这些困难,使持续部署变得切实可行。

建立持续部署的挑战

有几个与创建持续部署环境有关的挑战。

设计和沟通部署

沟通和设计部署往往需要让来自多个学科(软件架构师、部署工程师、运营、数据库管理员、项目经理,等等)、不同部门、不同地点的人进行相互沟通。所需的协作非常复杂,并且需要许多人提供相关意见。通常情况下,如果重要信息丢失或从未记录这些信息,都有可能导致部署失败。此外,缺乏一种一致地完整描述部署的方式,人们很难看见部署设置,很难对其进行推理分析,因此降低了及早发现非功能性问题(如性能、备份和可扩展性)的可能性。

在持续部署方法中,通过有意识的定期部署,可以在某种程度上降低这种风险。但是,在这种情况下,会出现另一种风险。如果您的持续部署环境与生产环境不同,并且您不能重用脚本,该怎么办?(这是一种很可能性出现的场景。)那么,虽然您可以通过开发获得很多好处,但您的生产脚本很有可能出现缺陷,在以专用 方式描述部署的时候尤其如此。因此,存在以下两个重大挑战:

  • 如何定义部署的关键要素,使它可以用来描述如何将应用程序部署到多种不同环境
  • 如何有效地使所有利益相关各方在部署计划上进行协作,从而最大程度地提高质量并减少所涉及的风险和时间

自动化部署流程

如今的部署比以前明显更加复杂,大多数应用程序都需要配置中间件(在应用程序服务器上创建数据源,或建立一个消息队列)。这种自动化配置可能很复杂。它往往需要专门的技能,这是许多组织在部署应用程序时自动化程度极低的原因之一。

毕竟,俗话说得好,轻松的工作每个人都会做。

治理可部署的构件

最后,一个常见的挑战是治理将要部署的构件。有两个显而易见的解决方法,但它们都存在缺陷:

  • 第一个方法是,您可以将每个版本放在文件系统中的指定位置。这很简单;但是,这种方法可能相当不安全,并且它几乎没有任何措施可以确保您测试过的文件与您部署到生产的文件是相同的(它们很容易就会被修改或覆盖)。所以,如果您需要证明您测试的文件就是您部署的文件,那么这种方法无法令人感到满意。
  • 第二种选择是使用您的源代码控制系统来管理文件。这至少可以提供您需要的治理。然而,它也需要您为部署团队提供访问每一个源代码控制库中的每一个项目的权限,而该要求在一个中型组织中可能会变得无法管理。

这两种方法都无法帮助解决关于应用程序彼此之间、应用程序与其他组件以及开源库之间的依赖关系问题。

虽然这些挑战很艰巨,但不建立持续部署将带来更多艰巨的挑战:

  • 部署软件需要更长的时间,因此,从部署软件中获取价值亦需要更长的时间。
  • 在部署新软件时,业务的风险会增加,这可能会降低生产力和销售,甚至危害您的声誉、品牌和客户忠诚度。
  • 如果您不能满足非功能性需求,成本可能会增加。

如何配合使用 IBM Rational ALM 解决方案

本节介绍如何配合使用 IBM Rational 软件的三个工具来解决上一节中所述的挑战。

IBM® Rational® Software Architect
一个建模工具,可以用来对部署的拓扑结构进行描述和协作,并生成部署脚本。
 
IBM® Rational® Automation Framework
一个部署自动化引擎,它还提供了常见自动化任务的库。
 
IBM® Rational® Asset Manager
一个托管的存储库,其中包含可部署构件和标准基础架构拓扑。
 
IBM® Rational® Quality Manager
一个基于 Web 的测试管理环境,适用于协作测试规划、流程控制、跟踪和指标报告。
 

设计和实现自动的部署

第一个挑战是建立可以在整个开发和测试中使用的自动化的部署脚本,还可以将它用于生产中。这带来了以下两个挑战:

  • 第一个挑战是就如何部署应用程序和如何应配置中间件进行沟通。
  • 第二个挑战是如何使脚本或脚本集支持所有环境,同时仍然对所有脚本都将成功部署应用程序充满有信心。

Rational Software Architect 提供了以图形化的方式来描述部署拓扑的功能。它还有助于验证所描述的拓扑结构是一致的、合理的、没有漏掉所需要的任何要素,因此,它有助于减少以后出现代价高昂的错误的机会。建立部署拓扑之后,开发人员就可以在 Web 上对这些拓扑进行协作,与利益相关者分享它们,并允许人们对其发表意见和参加正式的评审。

Rational Software Architect 提供了定义逻辑和物理部署拓扑的功能,有助于解决第二个挑战。这使得逻辑拓扑能够描述应如何将应用程序部署到不同逻辑环境的多个重要方面,然后,在将它映射到真正的基础架构时,它会强制实施逻辑模型中的所有约束。

图 2. 逻辑 Java Enterprise Edition (JEE) 部署拓扑示例
由在逻辑服务器上托管的组件所组成的拓扑

此方法可降低生产部署风险,因为会使用该模型来生成适用于所有环境的脚本,并且会在整个开发过程中非常彻底地测试该脚本。

即使适用于不同环境的脚本可能会有所不同,Rational Software Architect 可帮助确保该脚本将正确部署应用程序,因为脚本是从物理拓扑生成的,它确保物理拓扑可满足逻辑拓扑的所有要求。因此,可以很容易地生成一个适用于新环境的脚本,并且我们对它第一次就能正常工作有很大的信心。

图 3. 基础架构的逻辑拓扑
逻辑拓扑到物理计算机的映射

在您定义了如何将应用程序部署到中间件之后,就可以分析模型以实现可能的自动化,并参照已知的脚本对拓扑中的元素进行匹配,从而实现相应部分的部署。这支持部署和配置大部分 IBM 中间件和最常见的替代品。这种方法大大减少了设置一个新的自动化部署的工作,并且它可以降低部署到不同环境的风险。

拓扑成为关键的构建。部署到不同的环境是一件简单的事,只需筹划应该如何将各种应用程序组件(EAR、WAR 和 DLL 文件、队列定义等)部署到新的环境,然后生成脚本来自动化工作。因此,它需要的手动工作少得多,并且该工具通过验证是否已正确映射应用程序而降低了风险。

在持续部署的情况下,您将使用一个逻辑拓扑来描述应用程序的关键元素,并且每个明显不同的环境都对应一个拓扑,它描述了应该如何将应用程序部署到该环境中。这些拓扑都将用于生成持续部署过程中所用的部署脚本。

交付变更

在您生成部署脚本后,需要将这些脚本纳入到开发环境中,使所有的变更都能持续部署。这意味着测试团队可以节省大量时间,因为他们并不需要建立测试环境(通常估计完成该项工作的时间在测试工作中占 20-30%)。即便如此,仍然会使用和调试部署脚本,并且对生产而言,应用程序始终有可能是可以部署的。

完成此设置的最简单的方法是,修改现有的持续构建脚本,将可部署的构件存储在资产库中,然后请求利用该库中的资产进行部署。部署请求将使用先前从 Rational Software Architect 生成的脚本,并将应用程序部署到某个测试目标(或多个目标)。

图 4. 持续集成引擎请求一个持续部署
将资产发布到 RAM 并开始部署它

然后,您要配置 IBM® Rational® Quality Manager 监视持续部署版本。在一个成功的部署中,会运行您的回归测试软件,并解锁任何以前失败过并且在最新版本中提供了修复的测试。该方法意味着,每次开发人员进行一此更改,持续部署也会验证应用程序是可部署的,并能通过所有回归测试。因此,在这种环境中,一个简单的单行代码变就可以使测试版本在几分钟内准备好部署到生产环境中。

图 5. Rational Quality Manager 监视部署版本
流程图:监视部署,运行测试

在考虑这种方法时,人们常常想到的问题或疑虑是他们可能需要的硬件数量。不过,我们有一个简单且具成本效益的解决方案:云(请参阅 参考资料,以获得 IBM SmartCloud Enterprise 选项的链接)。部署脚本启动一个映像,将应用程序部署到该映像,然后运行功能测试,并关闭映像。通过这种方法,组织可以应付有许多变更的开发周期(例如,迭代结束),并且在较少变更和需要较少硬件时能够最大限度地降低成本。

团队还需要一个用来定期探索性测试和构建新自动化测试脚本的环境。可以通过建立滚动环境来实现此环境,每日构建 (daily build) 被部署在该环境中,并且会在该环境中保持数天。您也可以让测试团队根据需要请求构建,然后将这些构建部署到通过 Rational Quality Manager 的测试实验室管理特性预订的测试硬件,或部署到云,这与持续部署的工作方式相同。这种方法可以降低硬件成本,并节省开发时间,因为测试设置减少了,反馈速度更快,并且生产部署的风险更低。

图 6. Rational Automation Framework 部署到多种环境
部署到物理、虚拟或云硬件

从环境到生产对构建和提升进行治理

对于很多组织来说,可部署资产的治理(谁修改了哪些内容、何时修改、为何修改以及该修改是否是一个经过批准的变更)往往非常关键。治理可部署资产之所以重要是因为那些已部署应用程序对其业务的重要性,或者是因为需要证明其他组织规定的合规性。

那么 IBM 如何能有助于可部署资产的治理呢?

ITIL 建议使用一个 “最终介质库” 在整个开发过程中管理可部署构件,并使它们在部署到生产时可以使用。在 Rational ALM 方法中,我们主张在 Rational Asset Manager 中将可部署文件存储为资产,并在治理过程中使用资产生命周期和审查。这提供了一个中央存储库,其中包含已被发布到生产环境的所有构件,以及所有可以发布的构件。这也意味着,所有部署流程都由同一个中央存储库驱动,因此除了部署到生产的资产已通过更多审查和批准之外,所有资产都是相同的。并且它意味着,可以安全地保存资产,这样就只能通过各种审批阶段(一般与测试阶段相关联)使这些资产处于可部署状态:

  1. 已识别
  2. 在开发中
  3. 已通过单元测试
  4. 已通过系统测试
  5. 已通过用户验收测试
  6. 临时
  7. 在生产中
图 7. Rational Asset Manager 资产审查生命周期
资产状态,从 “已识别” 到 “在生产中”

Rational Asset Manager 可以提供帮助的另一项功能是开发团队所使用的标准部署拓扑的存储。通过使用该功能,运营团队可以为开发团队定义 “标准” 配置。这会带来符合标准中间件配置的部署。一致性使得部署变得更简单,并使得整个软件开发生命周期中的管理成本更低。

图 8 中的屏幕截图展示了应用程序架构师如何从 Rational Software Architect 搜索 Rational Asset Manager 中已获得批准的拓扑

图 8. 搜索已获得批准的拓扑
在导入资产后搜索拓扑

结束语

本文描述了持续部署设置的三个主要挑战:设计、自动化和治理。然后,说明了您可以如何结合使用 IBM Rational ALM 软件和云:

  • 增加部署设计中的协作,从而提高质量并改善不同利益相关者之间的沟通
  • 使用部署设计,自动创建适用于开发、测试和生产的部署脚本
  • 扩展标准的持续集成实践,提供可治理的、成熟的持续部署实践,降低对生产变更的成本和风险,并提高部署变更的速度。

本文还希望向您介绍如何将 Rational 工具与云结合使用,使持续部署变得既实用又具有成本效益。这样您就可以快速利用技术优势来减少测试和部署工作,改善治理,并降低部署到生产的风险。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=819455
ArticleTitle=利用 Rational ALM 工具使持续部署变得切实可行且具成本效益
publish-date=06042012