git 增量包 怎么打_应用系统增量部署通用流程实践

请点击上方“民生运维人” 添加订阅！

1

前言

应用部署是运维人员每日面对的重要问题之一。尤其是在应用交付频率越来越高的当下，运维人员经常需要花费巨大的成本和心血来完成频繁的应用部署工作。如何提高部署的准确性，提升部署效率就成了摆在运维人员面前的问题。根据不同系统自身的特点，部署方式千差万别，但大体思路分为全量部署和增量部署两种方式，本文仅针对增量部署介绍一套通用的增量部署实践机制。

增量部署流程

增量部署一般指在每次部署过程中，首先提取当前版本和即将部署版本之间的增量(包括代码、可执行文件或者配置等)，并在部署过程中仅更新增量部分。这种部署方式的常见部署流程如下：

a) 利用代码管理工具(SVN、GIT等)提取两个版本之间的增量，并结合其他方面的增量变化。

b) 按照增量部分制定具体的部署方式，编写部署脚本，并准备增量部署包。

c) 分发和部署增量部署包到已经运行上一版本的目标环境，完成系统的版本升级。

增量部署的优点

a) 减少变化量。增量部署可以减少对于整个系统的变化幅度，很多已经完成的配置工作不需要每次重复设置。从而可以避免误操作，降低部署失败率。

b) 提高安全性。增量部署每次只会涉及到增量代码部分，不会直接暴露系统的整个代码部分更新，避免系统代码泄露的风险。

c) 部署速度快。增量部署每次仅对增量部分进行更新，无论是文件分发还是配置更新的内容都会更少，部署需要的时间也就相对较短。

2

增量部署本质

抛开系统之间的差异性，每次生产系统的变更实际上就是做的就是介质更替，然后使其生效。

介质包括：

图2-1

针对每种介质我们做的操作是：

图2-2

所以我们只需要知道以下信息就可以准确地完成本次变更的介质替换

增量部署必备三点信息：

图2-3

3

增量部署实践

约定

要实现自动化一键式增量部署，我们需要对上一章中提到的三点信息进行有效传达，通过协商，我们与介质提供人员约定，每次上线按照以下要求提供三个文件。 

1.add_List—本次上线新增文件列表(含目录)

2.delete_List—本次上线删除文件列表(含目录)

3.package.tar—本次上线部署包，包括新增介质和替换介质(根据生产目录结构打包)

有了这三个文件我们就可以获得上一章提到的增量部署三点信息：

1．待新增的介质及位置—在add_List中记录新增介质的目录，在package.tar可找到新增的介质

2．待删除介质的位置—在delete_List中记录待删除文件的目录

3．待替换的介质及位置—将package.tar文件展示出来去掉add_List中的内容即得到待替换介质的目录，在package.tar可找到待替换的介质文件

增量部署步骤

下面我们以一套部署在weblogic中间件的应用系统来介绍增量部署的实践方法。

图3-1 应用系统的整体部署流程图

这里我们仅对增量介质更新环节(黄色部分)进行详细介绍，整体分为四个步骤：

图3-2增量部署四个步骤

1.更新前介质检查

四个步骤中，更新前介质检查是重点，也是增量部署成功的前提条件，可以保证介质的完整性和正确性。 主要完成的工作如下：

a) 将开发提供的add_List，delete_List文件置为UNIX格式

b) 解析开发提供的上线包package.tar,获得本次待更新的文件列表，待备份文件列表

c) 对新增，替换，删除的介质文件数量进行核对，并提示出来

d) 检查待替换，待删除的介质文件在生产环境是否存在，如不存在提示用户检查上线介质

具体的检查流程见下图:

图3-3更新前介质检查流程

2. 介质备份

在对上线介质检查无误后，我们根据上一步生成的备份文件列表对本次上线的待删除和待替换的介质文件进行备份。

具体的检查流程见下图:

图3-4介质备份流程

3. 介质更新

介质更新环节根据开发提供的删除文件列表删除文件，并将上线介质包进行解压，需要注意的是上线介质包的目录结构要与生产环境目录结构一致。

具体的检查流程见下图:

图3-5介质更新流程

4. 更新后介质复核 

经过前三步的操作可以说已经完成了本次上线介质的部署，为了确保上线介质万无一失的部署到了对应的位置，我们需要再次进行复核。

复核的内容包括三部分:

a) 检查开发提供的上线包中的介质在生产环境都存在

b) 检查生产环境中介质的大小和上线包中介质的大小一致

c) 检查生产环境中介质的最近修改时间和上线包中介质的最近修改时间一致。

具体的检查流程见下图:

图3-6更新后介质复核流程

增量部署脚本接入自动化运维平台

为了实现一键式自动化部署，我们还需要解决两个问题：

1. 顺序执行上一章中的增量部署步骤对应的脚本，并对每一步进行有效的反馈

2. 在多台服务器上同时进行部署

这两个问题在中国民生银行自动化运维系统可以有效的解决，为我们的一键式增量部署铺平了道路。自动化运维系统可操作目前投产的所有服务器，通过并发同时调用服务器中的脚本，实现多台服务器同时部署的需求。

我们在自动化运维系统需要做的就是新建一个流程，流程中将我们增量部署的四个步骤添加进去，并选择对应执行的服务器，然后进行发布即可。

4

可视化介质打包系统

为了标准化的提供3.1节中约定的三个增量部署相关文件。我们开发了一个基于浏览器的可视化介质打包系统，该工具可以生成3.1节中约定的三个文件。

1.add_List—本次上线新增文件列表(含目录)

2.delete_List—本次上线删除文件列表(含目录)

3.package.tar—本次上线部署包，包括新增介质和替换介质(根据生产目录结构打包)

通过打包系统对介质进行打包，标准统一，可提高打包的效率和安全性，操作可视化，便捷，解决了开发人员手工打包、手工编辑介质列表文件的问题。

可视化介质打包系统使用流程

使用打包系统进行打包的主体流程如下：

1. 配置待打包服务器信息

登录打包系统，点击“请添加”按钮，然后输入登录服务器需要的信息

图4-1打包系统配置服务器信息

在输入完服务器信息后点击“测试连接”按钮，测试打包系统能否正确连接服务器，测试成功后点击确定，在首页中可以看到刚刚添加的服务器按钮。

2. 进行可视化打包

根据页面提示，依次选择本次上线待新增和待替换的介质文件，所选内容返显在当前页面。

图4-2待打包文件选择

打包环节完成后会在之前配置的目录下生成一个TAR包，包含刚才可视化选择的文件。

3. 管理功能

配置的服务器信息可在服务器列表进行管理。

打包的历史详情可在打包记录中查看，支持通过日期检索当前用户打包的历史记录。

可视化打包系统技术实现介绍

用户界面使用Bootstrap作为CSS框架，页面元素比如下拉菜单、按钮组、按钮下拉菜单、导航、导航条、路径导航、分页、排版、警告对话框等均使用Bootstrap组件实现。

使用zTree生成文档树，可实现延迟加载，可实现上万节点轻松加载，可任意更换皮肤和自定义图标，支持节点附加checkbox和radio功能，且支持多种父子节点级联选择方式，具有多种事件相应回调，如节点展开事件、节点点击事件、节点选中事件等。前台页面使用静态Html和Ajax相结合，同时使用json传输数据，在后台使用Jackson整合springMVC接收和发送数据，尽可能的减少页面切换带来的数据加载。

可视化介质打包系统技术架构图如下：

图4-3打包系统技术架构

可视化打包系统思考

可视化打包系统打通了一条对服务器可视化查看，操作的道路。我们可以在不登录生产服务器命令窗口的情况下对生产服务器进行查看，并进行一系列可视化系统允许的操作。

我们可以对用户分配角色，不同的角色拥有不同的操作权限。如查看角色，对只拥有此角色的用户，仅允许查看服务器文本文件，这样及解决了运维人员随时查看生产服务器状态的需求，又避免了运维人员在生产服务器上执行高危命令的可能。

5

展望

应用系统的部署操作最为重要的考量应该是部署操作的“可重复性(repeatable)、可预测性(predictable)和可回滚性(undoable)”。根据增量部署检查和备份环节产生的成果，我们可轻松实现回退方案的制定，但目前的回滚过程还依赖于人工干预，如何利用部署过程产生的成果实现一键自动化回滚，以及针对数据库内容的一键式回滚是我们在接下来需要继续攻克的问题。

 

周涛

应用运维工程师，曾参与中国民生银行新核心系统建设、资产托管新一代系统建设，具有丰富的应用系统运维与项目开发经验，目前负责中国民生银行资产托管部与金融同业部相关系统的应用运维工作。

编辑：民生运维文化建设组