Rational ALM 工具使持续部署变得切实可行

发表于:2013-03-05来源:IBM作者:Steve Arnold点击数: 标签:rational
么是持续部署,为什么对它感兴趣,它有助于解决哪些问题? 对于许多组织来说,业务和开发团队的愿望是更快、更频繁地生产可用软件,而运营团队的责任是以规避风险的方式管理组织的基础架构,从而确保业务的连续性,在这两者之间,往往存在着分歧。

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

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

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

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

  更少停机时间和更多升级,从而带来更好的生产力和软件的增值。

  业务可以更快速获得软件变更,所以您可以提高您在软件开发上的投资回报。

  测试团队在配置环境和部署软件上花费的时间更少。

  更早发现回归缺陷,因此可以用更少的时间和更低的成本来解决它们。

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

  图 1. 持续编译、集成和部署的价值

该图比较了 3 种持续更新

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

  建立持续部署的挑战

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

  设计和沟通部署

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

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

  如何定义部署的关键要素,使它可以用来描述如何将应用程序部署到多种不同环境

  如何有效地使所有利益相关各方在部署计划上进行协作,从而最大程度地提高质量并减少所涉及的风险和时间

  自动化部署流程

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

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

  治理可部署的构件

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

  第一个方法是,您可以将每个版本放在文件系统中的指定位置。这很简单;但是,这种方法可能相当不安全,并且它几乎没有任何措施可以确保您测试过的文件与您部署到生产的文件是相同的(它们很容易就会被修改或覆盖)。所以,如果您需要证明您测试的文件就是您部署的文件,那么这种方法无法令人感到满意。

  第二种选择是使用您的源代码控制系统来管理文件。这至少可以提供您需要的治理。然而,它也需要您为部署团队提供访问每一个源代码控制库中的每一个项目的权限,而该要求在一个中型组织中可能会变得无法管理。

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

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

  部署软件需要更长的时间,因此,从部署软件中获取价值亦需要更长的时间。

  在部署新软件时,业务的风险会增加,这可能会降低生产力和销售,甚至危害您的声誉、品牌和客户忠诚度。

  如果您不能满足非功能性需求,成本可能会增加。

  回页首

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

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

  IBM® Rational® Software Architect

  一个建模工具,可以用来对部署的拓扑结构进行描述和协作,并生成部署脚本。

  IBM® Rational® Automation Framework

  一个部署自动化引擎,它还提供了常见自动化任务的库。

原文转自:http://www.ibm.com/developerworks/cn/rational/continuous-deployment-rational-alm/index.html