生产环境发布管理
前言
在一个大型团队中，生产发布是一件复杂的事情，从dev（前后端联调）-->test（测试集成&压力测试）-->pre（灰度测试）-->prod（生产环境）的多环境推进，以及生产环境的热更新、回滚等问题一直在困扰着各个公司，今天我将基于公司的自动化部署平台为大家讲解下我们是如何做到多环境部署。
每个环境做什么
在明确发布之前，我们需要明确一下每个环境的主要职责和角色：
DEV：也叫开发环境
事项：前后端接口联调，修复代码基础缺陷
角色：前端-后端
TEST：也叫测试环境
事项：测试集成测试、压力测试，开发修复bug
角色：开发（前端后端）、测试
PRE：也叫灰度环境
事项：生产环境冒烟测试，切5个左右真实生产数据，回归流程是否有问题
角色：开发（前端后端）、测试
PROD：也叫生产环境
事项：发布代码，做真实环境验证，有问题第一时间修复(sql止血订正或代码回滚)
角色：开发（前端后端）、测试、运维
大型公司如何管控代码发布
随着自动化部署CI/CD（DevOPS）成熟，目前大型公司都开始搭建自动化部署平台，形如下图：
图1 (自动化部署平台应用主页)
当用户进入应用主页后，会发现有不同的发布环境，每一个环境对应一台服务器、一个访问域名、一组中间件环境（即dev、test等环境的nacos-mysql等都是分环境部署的）。
图2 (自动化部署平台多环境)
同时自动化部署平台会自动整合公司的gitlab，将分支展现在发布平台，以便用户可以界面化操作和部署
图3 (自动化部署平台分支管理)
当用户需要创建分支时，不再需要像传统的那样去git创建，或者idea创建，而是可以直接在当前发布平台创建（底层是一样的，都是创建一个新的git分支）
图4 (自动化部署平台分支创建)
当用户需要发布时，只需要进入对应的环境（这里我们以test为例），勾选所需要发布的分支，即可实现自动化部署。下图可以看到test环境同时部署分支约20个。
图5 (自动化部署平台提交发布)
需要注意的是：假设我们需要对A分支进行发布，只需要勾选A分支，底层Jenkins会自动完成jar包构建，并执行底层的Docker run指令完成容器部署，这里部署的jar包每个环境都是隔离的。
即dev的jar跟test无关，每次都是新构建自己的。即使是test，点击两次发布也是构建了两个jar，只不过第二次的会覆盖第一次。这点各位需要明晰。
当测试提出我们有bug时，对应的开发人员就需要在idea中，A分支上完成代码修复并push，然后在自动化部署平台重新勾选分支，然后提交部署，完成一次重新发布，循环此过程，直至缺陷被修复。
如何排查日志
当测试提出某个环境有bug时，如果是传统Linux直接部署，我们会登录到指定的服务器用cat、grep、vim等指令进入日志文件，然后找到错误的堆栈信息。如果有结合Arthas的（Arthas排查错误）可以启动Arthas查看错误信息。但是现在一般都是会借助于Skywalking或ELK进行日志查看
图6 (自动化部署平台日志排查)
在上图中我们就可以看到：一个GET请求，请求路径是：/dict/default/staff，然后一个远程服务调用，使用的dubbo，最后查询mysql数据库，这样就完成一个完整的日志链路追踪。
如何回答相关问题
1.你们公司如何部署发布
方案一：Linux原生部署
我们公司的部署呢，还是比较原始的，就是直接部署在原生的Linux系统，我们平时dev发布就在idea构建好一个jar包，然后用XShell上传上去，用指令：nohup java -jar tj-learning.jar启动。测试环境和生产也是一样的操作
方案二：基于Jenkins的自动化部署平台
我们公司的部署都已经非常成熟了，有一套自动部署平台，底层是Jenkins+K8S实现自动化部署发布，我们只需要在dev、test、prod等环境勾选需要发布的分支就行，它全帮我们做好了自动部署。
2.你们公司怎么排查错误
方案一：Linux原生环境
我们公司的部署呢，还是比较原始的，就是直接部署在原生的Linux系统，所以排查日志也需要自己去找到error.log，然后手动找到报错的堆栈信息，分析出原因。比如有个NPE（NullPointException-空指针异常），就会显示具体哪行报错，我们就会分析、修复。
方案二：基于Docker的原生平台
我们公司目前的部署就是原生的Docker，通过docker logs命令人肉排查
方案三：基于Skywalking的日志检索平台(CI/CD平台)
对于日志排查，我们公司是有Skywalking的，只需要测试给我对应的traceId，我输入进去就可以看到完整的调用链路和报错的堆栈信息，然后就可以分析报错原因并修复了
