在明确发布之前，我们需要明确一下每个环境的主要职责和角色：
DEV：也叫开发环境
● 事项：前后端接口联调，修复代码基础缺陷
● 角色：前端-后端
TEST：也叫测试环境
● 事项：测试集成测试、压力测试，开发修复bug
● 角色：开发（前端后端）、测试
PRE：也叫灰度环境
● 事项：生产环境冒烟测试，切5个左右真实生产数据，回归流程是否有问题
● 角色：开发（前端后端）、测试
PROD：也叫生产环境
● 事项：发布代码，做真实环境验证，有问题第一时间修复(sql止血订正或代码回滚)
● 角色：开发（前端后端）、测试、运维
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，我输入进去就可以看到完整的调用链路和报错的堆栈信息，然后就可以分析报错原因并修复了
