我们如何把持续部署化繁为简的｜优维

在之前的文章中｛持续发布的三种反模式及解决方案｝提到了持续部署的三种反模式及几种实现。在更早期的文章中介绍了｛可视化持续部署系统的设计与实现｝里面也详细介绍了持续部署系统的设计与实现细节。或许在之前的文章中大家看到的依然是一个复杂的持续部署系统，那接下来看看我们是如何进一步简化的？适应一切是我们这次设计持续部署的目标。

一、我们似乎都忘了什么

我们忘了什么？我们忘了别人的经验，忘了别人基于经验的总结。这个地方想说的是RPM包，打开RPM包的一个概念描述图。里面的内容如下：

A、描述部分，Description。包的名称／版本／安装的路径／权限等等。

B、动作部分，Action。里面定义了很多种动作，比如说Build，Prep（准备），编译（Configure），安装（Install）等等。

C、文件部分，Files。这是Action要操作的基本对象，比如说文件的构建转化／文件的移动。注：不建议拿源码包到现网编译。Build Once，Run Anywhere应该是我们需要秉持的持续部署核心理念。

我们把Action部分提炼成事件流，等同于程序在执行安装／升级／回滚的时候都由这一连串的Action组成，形如：

对事件流的使用，也要注意，不要有自定义RPC的调用产生，除了构建依赖库动作，不建议有其他的远程调用，比如说到监控系统中屏蔽升级告警。这样做非常不利于控制其中的异常，更多的是把它作为一个执行流能过顺序执行下去，其中的异常由后一部分的去感知，比如说构建库获取不到，则程序编译异常。

试想一下，如果把这套东西可视化出来，是不是能够达到我们的应用部署的要求呢？事实证明是必然的，但需要根据我们的现实情况来去繁就简。

我们把一个应用包拆解开来，就能看到我们的持续部署系统需要管理的对象属性是哪些，其实能看到几个关键维度信息：

A、目录规范／权限规范／日志规范／运行规范。在之前的规范中都已经有解释过了。

B、管理规范。包括应用包的版本规范／应用包关联的环境管理／应用包仓库管理／增量升级／全量升级等等。

C、监控规范。程序异常了如何处理？日志的异常如何处理？可以从源头上控制无效告警的产生。

二、以应用为中心的持续部署实现

一定要把你管理的对象和应用关联起来，否则未来数据无法有效的整合。到Host级别的管理太粗了，特别是到小的企业中，机器复用太严重，一台机器跑十几个应用都是正常。应用的命名采用多级结构，从业务集－》业务－》应用等来级别来定义。

三、持续部署系统的可视化实现

涉及到应用包管理的各个部分都需要在界面上可视化管理起来。比如说：

A、应用包的可视化启动／停止／重启／卸载等等。

B、可视化版本管理，可以在线修改任意文件。可以直接从Jenkins构建过程中Hook，然后推送构建包直接进入到版本仓库。

C、对事件流的Action提供可视化的封装，暂且只支持shell，没有支持更多的语言，比如说python，考虑对包的管理，shell的能力足够了，另外尽量减少对系统环境的依赖。提供了一些内置变量，提高编程效率。

D、可视化环境管理和配置管理。对环境的属性进行任意维度的扩充和管理，同时把配置文件的管理和环境进行关联。

从以上界面可以看出，我们把持续部署实现得非常简单，从目前多家客户的使用来看，对各种语言，各种场景，各种业务都完美支持。

但实现应用包的持续部署还远远不够，我们下个月会推出一键化运维调度平台，无缝对接各种服务和作业，用一个流程引擎服务来驱动业务级，多应用的自动化变更／调度等等。