这是一个创建于 282 天前的主题，其中的信息可能已经有所发展或是发生改变。
我是运维，刚入职新公司不久。公司代码环境有 3 个测试环境（ test001 、test002 和 test003 ）->预发布环境（ pre ）->生产环境（ prod ）。
每个环境都是代码，数据库，中间件互相独立的。
目前一个发版流程就是：（以 test001 环境为例）
- master 分支合并到 test001 分支，开发提交代码到 test001 分支，Jenkins 发布到测试环境 test001
- 测试没有问题，将 test001 分支合并到预验收分支 release ，Jenkins 构建 release 分支到预发布环境
- 预发布环境验收没有问题，就合并 release 分支到 master 分支
- 最后，master 克隆一个 release_xxx 发版分支，Jenkins 构建使用这个 release_xxx 分支发布到生产环境
发版涉及代码，数据库表结构修改，mq topic 主题增删改等。
假如今天 test001 发版，那么对应的代码，数据库，中间件的修改，也要同步到 test002 和 test003 测试环境。
请问各位大佬这种发布流程有没有问题？或者有没有什么优化点？
真不想每次发版，我都得修改 5 个环境的配置，数据库。
 |
1
JYii 282 天前
这活原来是运维干的啊，皱眉抽烟.jpg
|
|
3
JYii 282 天前
这么复杂的流程，我司运维只有 4 ，还是 CICD 集成一次就完事的了。db 变更等需提交 OA 走流程，DBA 操作
|
 |
5
perfectlife 282 天前
让开发写变更文档，按文档操作数据库变更，就得了。也不可能每次都会涉及中间件变更，唯一恶心的就是三个测试环境吧，说是测试环境其实每个也都独立，已经算是五套环境了。数据库变更可以用 sql 审核工具 工单的形式，让开发提工单你来审批执行。非生产环境学会放权，运维主要把流程制定好就行了
|
 |
6
syushin OP @perfectlife 变更文档是有的，针对生产环境。就是生产发版完成之后要我重新按照发版文档，修改下发布文档的配置再在多个测试环境发版一次。我觉得测试环境的发版不应该运维来操作，属于开发人员维护的范畴。
|
|
7
perfectlife 282 天前
制定好流程，提交代码 测试环境 jekins 自动发布 不就行了，数据库扔给研发自己改。哪还有运维动手的地方？
@syushin |
Select Language