|
一、前言
在深入探讨持续交付之前，我们先来看一个典型的场景：
A 公司最近很苦恼。
A 是一个传统行业的公司，物流运输为主营业务，IT部门作为支撑部门辅助业务发展。但是随着业务的快速发展，IT
部门开始感觉到有点力不从心了：
频繁的业务版本迭代(扩容、缩容、迁移、升级、回滚等等)，全靠人工变更操作，操作单调重复，却又风险很高；
研发同学只关注代码编写，很少考虑线上部署的规范和设计，全靠运维同学自己把关，结果各个系统的维护自成一套；
新旧系统越来越多，系统调用和接口关联复杂，一个看似简单的问题都要捣弄半天，甚至还查不出原因，更别提性能优化；
……
长久以往，业务部门对IT部门的印象直线下降，认为IT部门是一个成本部门的同时表现还让人失望，而 IT
部门则哑巴吃黄连，有苦吐不出。
A 公司遇到的问题，相信很多传统企业都会有同样的困扰。其实，知道问题在哪里，就是最好的开始，我把帮助类似A公司解决这些问题的方案整理出来，希望对大家有所帮助。
二、无规则，不成方圆，标准化一切！
2.1 什么是标准化？
在讨论标准化是什么之前，我们先来思考这些问题：
业务维护：手工模式可以维护一套系统的开发、测试和部署，如果是十套，一百套，甚至更多呢？
业务交接：业务交接代价太高了，能不能让新来的人几分钟就能理解整套系统的维护逻辑？
服务部署：手工部署很麻烦，搭建环境很痛苦。我可以一键部署，剩下的时间去喝咖啡吗？
标准化可以帮助我们解决以上的这些问题，我对标准化的定义就是：
针对企业内部的业务系统技术栈进行梳理，规划出一套开发和部署规范，并且在各个环境(Dev/Test/Prod)严格执行。
标准化对可变部署模式最为有效，通过标准化，企业内部的每一套系统，每一个环境，都保持一致，然后把规范化后的部署方案整理好，落实到自动化平台，就可以实现自动化部署而无需过多的人工干预。
试想一下，如果是一百套不同的系统，自动化平台根本做不起来，业务维护、交接和部署的成本简直不可想象。
那么问题就来了，如何做标准化？
PS：什么是部署模式？
实际环境中，部署模式分为2种，一种是可变部署模式，一种是不可变部署模式。
可变部署模式:
是指任何的版本变更操作，都会在原来的版本上进行，例如升级、回滚、卸载、安装，这些变更操作会直接影响到原来的版本的服务，技术术语中把使用了可变部署模式的服务器称之为：Mutable
Monster Server（随之时间推移逐渐变成不可控的怪物服务器）。
例如：ver1.0 发布之后，更新至ver2.0时，需要把服务器上的ver1.0的服务停止，删除版本文件，然后把
ver2.0的版本文件安装上去，再启动服务；
因此，如果版本回滚的时候，也是同样的操作，把 ver1.0 的安装回去。
不可变部署模式:
不可变部署模式，和可变部署模式相反，一旦当前的版本发布后，就不能再对该版本做任何的操作，如果要进行版本变更操作，就需要重新发布一个新的不可变版本，这些变更操作不会影响原来的版本的服务，不可变部署模式的目前代表是
Docker 镜像发布模式。
例如：ver1.0 的镜像发布后，更新至 ver2.0时，只需要把 ver2.0 的镜像发布出去，运行起来，然后把流量切换到
ver2.0 的容器实例上即可；
因此，如果版本回滚的时候，就把流量切换回去 ver1.0 的容器实例上；
2.2 如何做标准化？
我把标准化的实践思想总结为XY轴对象模型，从开发、测试、运维3个角度着手。
例如，以运维的角度来梳理：
梳理Y轴(实体)
所谓的 Y 轴，是指企业IT系统所遵循的技术栈，从企业的技术栈入手，从宏观上把需要标准化的实体梳理清楚。
以A公司为例，A公司他们使用了JBOSS作为开发平台，我梳理的Y轴的实体如下：
基础层
基础层一般指技术栈最为底层依赖的环境，例如：
A 公司使用了 JBOSS-EAP，因此底层依赖的环境是 OS + JDK：
Java 项目，基础层：OS + JDK；
Python 项目，基础层：OS + Python；
Rails 项目，基础层：OS + Ruby；
……
框架层
框架层一般指技术栈所使用的项目开发框架，可以是开源方案，也可以是自研发框架，例如：
A 公司使用了 JBOSS-EAP 作为开发框架：
Java 项目，框架层：JBOSS-EAP、Play Framework、Struts 2、Spring等；
Python 项目，框架层：Django、Flask、Falcon、Tornado 等；
自研发框架；
….
公共组件层(不一定有)
公共组件层一般存放多个组件共享的代码、配置、驱动等，需要按照实际场景进行分析，因此不一定需要。
业务组件层
业务组件层，就是研发同学开发的业务组件，业务组件一般会有：
代码包；
配置包；
运行时数据；
运行时日志；
梳理X轴(属性)
所谓的 X 轴，是指企业IT系统每一层技术栈应该遵循的标准，对每一层的技术栈进行深度分析，构建出实体应该具有的属性，例如：部署目录、运行属主、目录/文件属主、目录/文件权限、日志、数据等等。
结合 X 轴，可以得到以下需要标准化的实体/属性表：
例如，A公司针对部署目录这个属性，定制的标准化如下：
可以看看业务组件层的设计细节：
部署标准化执行准则
结合个人经验，在构建标准化对象模型时，以下的准则是应该遵守的：
启动脚本：应该构建统一的启动脚本，通过传入参数来匹配不同的业务组件；
实体隔离：梳理出来的实体，在部署上必须隔离；
代码包：代码包无状态，一次打包，多环境流转；
配置包：配置包环境相关，和代码包分离，甚至可以实现配置中心来实现统一存取；
数据隔离：数据需要写到数据目录或者数据卷上；
日志实践：日志写到数据或者日志卷上，规范的输出级别、内容格式、日志种类、轮替周期和定期清理。
综上所述，通过不同的角度来梳理XY的执行规范即可，例如研发也可以根据以下的规则来梳理：
同样，在测试方面也可以提供业务测试的定制化规范，比如功能测试用例的编写、规划的测试流程(黑盒测试、白盒测试、回归测试以及性能测试)等等，不知道大家是否理解了:-D？ |
