每个环境做什么
在明确发布之前，我们需要明确一下每个环境的主要职责和角色：
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，我输入进去就可以看到完整的调用链路和报错的堆栈信息，然后就可以分析报错原因并修复了
