我是运维，刚入职新公司不久。公司代码环境有 3 个测试环境（ test001 、test002 和 test003 ）->预发布环境（ pre ）->生产环境（ prod ）。 每个环境都是代码，数据库，中间件互相独立的。 目前一个发版流程就是：（以 test001 环境为例） [ol]master 分支合并到 test001 分支，开发提交代码到 test001 分支，Jenkins 发布到测试环境 test001测试没有问题，将 test001 分支合并到预验收分支 release ，Jenkins 构建 release 分支到预发布环境预发布环境验收没有问题，就合并 release 分支到 master 分支最后，master 克隆一个 release_xxx 发版分支，Jenkins 构建使用这个 release_xxx 分支发布到生产环境 [/ol] 发版涉及代码，数据库表结构修改，mq topic 主题增删改等。 假如今天 test001 发版，那么对应的代码，数据库，中间件的修改，也要同步到 test002 和 test003 测试环境。 请问各位大佬这种发布流程有没有问题？或者有没有什么优化点？ 真不想每次发版，我都得修改 5 个环境的配置，数据库。 test001, 分支, 环境, 代码
让开发写变更文档，按文档操作数据库变更，就得了。也不可能每次都会涉及中间件变更，唯一恶心的就是三个测试环境吧，说是测试环境其实每个也都独立，已经算是五套环境了。数据库变更可以用 sql 审核工具 工单的形式，让开发提工单你来审批执行。非生产环境学会放权，运维主要把流程制定好就行了
@perfectlife 变更文档是有的，针对生产环境。就是生产发版完成之后要我重新按照发版文档，修改下发布文档的配置再在多个测试环境发版一次。我觉得测试环境的发版不应该运维来操作，属于开发人员维护的范畴。
