金融行业 DevOps 解决方案，第 5 部分 DevOps 实施之企业级的统一发布平台

概述

在前面的几篇文章里，我们介绍了 DevOps 实施概述、基于 RTC 及 Build Forge 进行统一配置管理和构建，以及基于 Sonar 进行持续集成质量改进。本文将在此基础上，对软件发布和部署进行介绍，同时对发布和部署过程中所存在的一些问题，提出持续发布和部署解决方案。本文将对该解决方案进行介绍。

从软件需求定义，到软件开发、测试、ST、UAT 到软件投产，再到软件的运维管理，软件的发布和部署是每个 IT 组织都需要持续关注和管理的。

1. 软件发布和部署的能力高低直接关系到 IT 组织的商业价值交付能力，随着针对软件开发的众多方法论及最佳实践的出现和推广，例如：敏捷开发、精益开发等，软件开发团队的开发能力得到了很大的提升，许多企业和 IT 组织在应用发布和部署方面进行持续改进，从而确保软件开发团队交付的功能及时上线，进而提升商业价值的交付能力。
2. 软件的发布和部署直接关系到 IT 组织的风险，应用发布和部署的失败往往意味着所在组织需要承受相应的商业风险以及商业价值的损失，许多企业和 IT 组织都在为如何提升应用发布和部署的稳定性，从而降低应用发布部署过程中带来的风险及损失而持续努力。
3. 软件的发布和部署涉及到开发团队、运维团队等多个团队的协作，而传统的开发与运维是相对隔离的，这客观上给发布和部署带来了很大的挑战， DevOps 从 2009 年被提出，在过去的几年里，许多企业和 IT 组织都在通过引入 DevOps 实践，让开发团队和运维团队在发布和部署过程中更好协作，从而更好地完成应用的发布和部署。

企业级应用发布部署存在的问题

在过去的几年里，本文作者在参与的多个金融企业的发布和部署管理过程中发现，每个企业甚至每个应用都有自己的发布和部署方法，成熟度也不一而同，但不论成熟度如何，发布和部署管理都不止是一份共享的电子数据表或者发布部署文档。通过观察和总结，企业级应用发布通常有如下几个问题：

1. 应用类型多种多样，技术百花齐放。

对于一个大型的 IT 企业来说，成百上千个应用往往涉及不同的编程语言（Java、C#、PHP、Delphi 等）、不同的中间件类型（WAS、Tomcat、JBoss 等）、不同的数据库（DB2、Oracle 等）、不同的部署服务器及部署架构（Windows、Linux、AIX 等），虽然企业通常有固定的发布流程管控，但是对于具体应用的部署过程来讲，往往千差万别。

2. 开发团队和运维团队的相对隔离，增加了应用部署的难度。

一个大型的 IT 企业往往有专职的运维团队来负责对开发团队交付的软件进行上线。开发团队更了解需要上线的功能完成部署所需注意的事项以及在上线出现问题时进行及时的上线问题定位及快速修复，运维团队更了解生产环境的配置以及应用在生产环境容易面临的一些问题，开发团队的关注点往往是如何快速地将开发部门的交付物部署到生产环境，而运维部门则是更多从运维的风险考虑，确保每一次上线都是安全的，可以保证生产环境在支持新的业务功能的情况下保持足够的稳定，所以开发团队和运维团队在节奏上的差异对于上线部署存在天然的矛盾。而开发阶段和生产阶段的部署差异，也决定了应用的部署资产（操作步骤、自动化工具等）不能很好地从开发阶段流转到生产阶段供运维团队完成投产操作。

3. 自动化程度偏低，手动操作导致的发布部署风险高。

发布部署过程通常是一个复杂重复的操作过程，虽然每个企业甚至每个应用针对于发布操作，都在进行不同程度的自动化，但总的看来，自动化程度偏低。而由于生产环境的复杂性，部署步骤往往相对复杂。例如：当一个应用需要手动部署到 10 台甚至更多的服务器上，而在每台服务器上重复相同的多达十个操作步骤时，很容易出现手动操作失误引发的上线发布失败风险。

如何有效地解决如上问题也是每个企业在应用发布部署领域所需要持续探索和改进的。在下面的章节中，我们将提出一套针对于企业级应用发布的持续发布 / 部署解决方案。

持续发布 / 部署平台整体方案目标

考虑到传统企业的发布和部署管理的普遍现状，针对于发布和部署过程中存在的普遍问题，并结合发布 / 部署管理的目标，持续发布 / 部署解决方案致力于如下目标实现：

1. 针对于目前部署过程中部署操作自动化程度普遍偏低，发布和部署效率低下的问题，本方案通过自动化部署工具，将部署过程中的手工操作尽可能地进行自动化。可以自动化的手工操作包括：获取应用部署包、启停服务器器及相关服务、应用部署文件的自动分发、应用部署后的自动检测等等。部署操作自动化有效地提升了发布部署过程的效率，降低手工操作带来的潜在风险，确保在发布过程中同一应用在不同目标服务器节点的发布一致性。
2. 针对于应用发布和部署模式所存在的差异，通过对于不同类型的应用发布部署，发现应用之间所存在的固定模式，基于不同发布部署模式提供相应地支持，从而对于类似的应用发布部署提供快速的支持。本方案针对几种典型的发布部署模式提供相应支持，例如： 固定版本排期发布、单项目发布、敏捷发布等。对于固定版本排期发布，多个项目和多个产品进行统一排程，每个产品的上线版本在上线前完成合并，在发布过程中，每个产品有自己的发布窗口以及应用部署流程。
3. 针对于应用发布和部署过程中开发团队、运维团队及其他角色之间的互相协调，本方案集成已有的发布和部署相关流程管控系统（如：项目管理系统、发布管理系统等），从而在部署过程中，各团队可以方便地了解部署相关信息（如：上线项目是否可以进行发布，发布请求是否被批准，上线的版本名称等）。同时在发布部署过程中各团队可以了解发布部署过程中的发布状态，从而在发现问题时，相关团队可以更快地定位问题并快速解决，并确保各个角色遵守既定流程相互协作，完成发布和部署操作。

持续发布 / 部署交付平台方案架构及概述

在本系列文章的第一篇中介绍了基于四层架构的端到端 DevOps 方案，而基于上述应用发布和部署目标，持续发布 / 部署解决方案架构如图 1 所示：

图 1. 持续发布 / 部署交付平台架构图

• 基础架构层为软件发布和部署的目标平台，平台可以为传统的硬件平台，也可以是目前兴起的云平台：PaaS 平台或者 IaaS 平台。根据不同企业的情况，本方案可以按照企业的目标平台予以支持。
• 流水线工具平台层提供了发布和部署方案的核心工具支持，在本方案中，部署平台（开发、测试和生产）使用 IBM UrbanCode Deploy （下面简称 UCD）产品作为部署的自动化引擎。自动化引擎主要关注于应用部署操作的流程自动化，确保应用部署核心步骤的可视化及可重用性。
• 流水线引擎层对于发布和部署提供发布部署的统一视图支持，包括四个关键组件支持：
  • 应用发布自服务管理、智能发布管理、平台运维管理和发布过程深入洞察。应用发布自服务管理包括应用及组件的初始化、部署流程定制、版本配置管理等；
  • 智能发布包括发布相关信息集成（从项目管理系统、发布管理系统等同步发布部署相关信息），应用发布模式支持，应用发布部署过程支持（发布前准备、发布中的相关操作、发布后的自动检测及流程支持等），发布部署过程中各团队之间协作支持等；
  • 平台运维管理关注于应用发布目标平台管理，包括传统硬件平台和云平台；
  • 发布过程深入洞察针对于应用发布和部署过程提供审计、报表等支持。由于开发测试阶段与生产投产阶段的天然差异，本方案使用两个系统对开发测试和生产分别提供支持，对于同一产品的发布和部署，支持相关资产的跨阶段流转。
• 流程管控层对于发布和部署相关流程提供支持。由于企业的 IT 系统架构的差异，发布和部署流程管控支持除了项目管理、发布管理之外，还可能包括运维监控、日志检查、测试管理等。流程管控层提供发布和部署过程中流程相关数据和信息，供流水线引擎提供发布部署统一试图。

持续发布 / 部署交付平台方案实施思路及方案介绍

方案实施思路

本方案实施过程中包括两个阶段：应用部署操作自动化支持和应用发布部署平台支持。

注：IBM® UrbanCode Deploy 将应用、中间件配置以及数据库的变更进行编排并自动部署到开发环境、测试环境和生产环境中，从而可以帮助加速产品上市、降低成本和风险。

1. 应用部署操作自动化支持：本阶段集中于将应用部署过程中的相关步骤在 UCD 中进行自动化以及目标环境的管理，对于标准操作，例如：应用版本发现、下载发布版本、解压缩文件、启动 / 停止 WAS 服务器等，直接使用 UCD 标准插件完成，而对于应用的部署的特殊需求，则通过插件的定制化开发予以支持。
2. 应用发布部署平台支持：本阶段将在第一阶段的基础上，对于应用部署提供平台支持，包括应用发布和部署的数据和状态同步，应用发布模式支持，应用发布过程审计支持，应用发布报表支持等。

这两个阶段可以根据企业的实际情况进行实施，企业既可以先行实施第一阶段，关注于应用部署操作的自动化支持，同时也可以第一阶段和第二阶段同时实施，以对于应用的发布和部署提供平台支持。

下面的章节将对持续发布 / 部署交付平台方案进行介绍。

持续发布 / 部署交付平台方案介绍

在持续发布 / 部署交付平台方案中，基础架构层是应用部署的目标环境，包括传统硬件平台和云平台，而流程管控层则是企业已有的流程管控相关系统，如：项目管理系统、发布管理系统等，本章节将不再进行详述，我们将重点介绍流水线工具平台层和流水线引擎层。

图 2 是持续发布 / 部署交付平台方案支持的一个虚拟的应用发布工作流。我们将基于该工作流对方案进行介绍。

图 2. 应用发布工作流

1. 初始化应用

   一个应用在使用平台进行发布之前，需要进行应用的初始化，应用初始化包括两部分：

   注：对于应用、组件、环境、资源、流程等概念，以及如何在 UCD 中进行应用初始化，可参考 UCD 信息中心。

   1) 在部署平台（UCD）中进行应用的初始化：本操作通常由发布管理员在 UCD 中进行相应的初始化及配置，包括：创建应用及对应用部署的目标环境进行初始化（图 3），创建组件（独立可部署单元）及版本导入信息配置的初始化（图 4），部署流程设计，资源的初始化等。

   2) 在应用持续发布门户进行应用的初始化：本操作可以由发布管理员或者开发人员进行配置，主要针对应用发布和部署的管理信息进行初始化操作，包括：应用的发布模式、应用发布的灰度策略、应用发布的目标平台及相关信息，例如：如果应用发布到 PaaS 平台，以 CloudFoundry 为例，则需要配置应用发布的目标 Target、Org、Space 等相关信息。

   图 3. 应用及目标环境配置

   

   点击查看大图

   图 4. 组件配置及版本设置

   

   点击查看大图

2. 发布相关信息同步

   注：持续发布 / 部署交付平台方案不包含项目管理和发布管理。

   每个企业都有自己的项目管理、应用发布管理流程及工具，例如： MS Project、Oracle P6、Visual Project、Workflow Max、CA PPM、ITIL 等等。持续发布 / 部署交付平台从相关信息系统同步项目及发布相关数据，从而在应用发布 / 部署过程中支持相关角色（项目经理、开发人员、上线管理员等）完成应用的发布 / 部署操作。项目管理和发布的相关信息同步采用定时批量同步机制和实时数据获取机制，同步技术可以根据企业使用的工具而异，如使用 REST API 或者其他技术。

3. 创建投产任务

   当一个项目在开发或者测试阶段进行部署时，或者一个项目完成开发和测试进行上线投产时，上线管理员可以对相应的项目及产品创建投产任务，包括设置待部署 / 发布的应用组件、设置待部署 / 发布的组件版本、待部署 / 发布的目标环境、设置待部署 / 发布的应用的部署流程，从而在开发团队成员确认应用组件可发布的情况下，可以进行应用的发布。

   应用初始化时涉及的应用、组件、环境、部署流程均为上线管理员在 UCD 中进行应用初始化后的相关信息，而组件版本则是根据上线管理员在 UCD 中对于组件的设置，由 UCD 自动发现的，包括从 artifactory 中自动导入或者从其他版本存储库中自动发现。相关信息由应用持续发布门户通过 REST API 从 UCD 中自动获取，并供上线管理员完成设置。

4. 认领待发布组件并确认组件可发布

   对于开发和测试阶段的应用部署，本步骤为可选步骤，通常开发和测试阶段的应用部署由应用开发团队成员发起，故不需要开发人员对于所负责应用组件进行认领。而对于应用上线投产，通常需要开发团队、业务人员、项目管理团队、运维团队等通过协作完成应用的上线操作。对于一些相对复杂的上线，例如上线应用之间存在依赖关系，不同应用同时上线但存在不同的发布窗口等，则通常需要支持应用上线的开发团队成员对所负责的应用及组件进行认领，在确认所依赖的应用组件发布完成后对所负责的应用及组件进行可发布确认，运维团队可以在开发团队成员确认的情况下执行应用的自动化部署操作。

   本操作可以通过开发团队上线负责人进行人工确认，而如果企业及组织对于相关信息已经进行管理，例如：每次应用发布对应的开发团队上线负责人信息，应用发布之间的依赖信息等，则本操作可以通过自动化方式实现。

5. 应用发布

   在开发团队上线负责人确认应用组件可发布之后，上线管理员可以执行应用组件的自动化发布操作，而自动化发布操作由投产任务中设置的待上线应用组件、版本、目标环境、自动化部署流程确定，应用持续发布门户通过REST API将相关信息发送到UCD从而调用应用的自动化发布流程完成应用的自动化部署/发布操作。。

6. 应用发布验证

   应用自动化部署完成，上线管理员、开发人员可以查看 UCD 中对应的流程运行日志，应用部署成功，技术人员对进行技术验证，技术验证通过则交由业务人员完成业务验证。如果应用支持灰度发布，则业务验证通过之后，上线管理员继续发布该应用的其他环境直到所有环境发布完成。

   对于开发和测试阶段的验证，通常由开发人员或者测试人员针对部署的应用版本进行相关测试。

   图 5. 发布页面

   

   点击查看大图

7. 应用发布跟踪

   在应用发布的过程中，应用发布的相关干系人如项目负责人、流程管控人员等需要跟踪应用发布的实时状态，从而确保在应用发布过程中，应用发布状态对所有干系人可见且信息一致。在应用发布过程中出现任何问题，各干系人可以更方便地进行协作以解决问题。

此外，应用持续发布门户提供发布过程洞察功能，对于应用发布的查询、报表分析等提供支持。

方案实施收益

如本系列方案的其他方案，持续部署 / 发布平台方案已经在部分金融企业进行实施，有效解决了客户在应用部署 / 发布领域所存在的问题：

• 应用部署 / 发布效率低下：通过引入 UCD 进行应用的自动化部署支持，从而解决了应用部署 / 发布手工操作所带来的效率问题，应用的部署 / 发布效率得到了有效的提升。例如：使用方案之前，某应用发布需要手工在超过 10 台目标服务器上操作多达 16 步的部署操作，而引入方案后 UCD 自动完成所有目标环境的部署相关操作。
• 应用部署 / 发布风险居高不下：相较于手动进行应用的部署 / 发布，自动化部署在提升效率的同事，有效地降低了应用部署 / 发布过程中由于手工操作所带来的发布风险，同时发布过程相关信息的集成，也帮助应用发布相关人员有效地降低了发布过程由于流程管控缺失所引起的应用发布失败风险。
• 应用部署 / 发布协作效率低下：引入本方案之前，开发、测试、运维各自为政，应用部署 / 发布资产重用性低，存在同一应用在不同阶段发布不一致的问题，同时由于各个角色关注于自己的职责范围，沟通和协作效率低下。通过本方案的引入，应用部署 / 发布整个过程对于各个阶段及角色透明，从而有效地保证了应用部署 / 发布资产的跨阶段重用，以及在应用投产过程中，各角色之间的有效协作。