首先测试环境发布权限本来也不应该在开发手中，而是由项目经理把控，如果没有项目经理也应该是由测试主管把控什么时候发布

你们没有测试老大的吗，这东西不就是靠自己争取的

应该有个测试环境和开发环境啊，各用各的不香么

测试老大并不关心这...只有靠自己去跟项目组成员说

按道理说是这样的
但是如果开发掌握测试环境， 对开发来说有便利的

为什么说是 “应该”？ 目前我的问题就是想把这个 “应该” 通过文档或者示例转达给项目组成员，让他们同意， 很是头痛...

搭建一个测试环境 CD 流程，这套用顺了，开发环境的发布说不定都要交给你

由问题推动比较好

测试环境原则上是不允许开发人员碰的，应该有测试人员或者配置运维人员控制，你们测试话语权太弱了。

你需要体现当你获得发布权限会带来什么价值后续拉会对齐，例如风险把控、责任人等

测试需要有独立的测试环境，跟开发共用很明显的一个问题就是资源竞争，这是个很明显且项目经理能很容易感知到问题，测试需要测试时，开发需要占用，直接降低了双方的效率呀，这个理由还不够么

都是测试环境了，不得是测试自己管吗，测试想发布就发布；开发应该有自己的开发环境。区分开来才对

顺着楼主的思路，进度出问题，我理解应该是如果某次发布把环境搞坏了，测试只能干着急，得开发才能解决？

如果是，可以把几个这样的案例举出来，说明对测试进度有什么阻碍，然后再顺理成章说测试来负责测试环境的发布，遇到这类问题可以直接自行解决。

另外，关于信息同步，建议推进开发的 commit 规范，带上提交类型、缺陷单号这些，达到基于 commit 信息就可以看出修了哪些 bug 的程度，这样从 Jenkins 代码变更情况就可以直接看到修复了哪些 bug，少一步人工同步，解决信息同步问题。

PS：我理解从开发角度，管理环境其实好处并不多，毕竟开发除了前期联调，后续比较少用到整套环境。所以其实不大需要想着 “说服”，说不定其实开发也不想管这个。

感谢耐心回答
大概的问题就是这样子， 我感觉目前最主要的问题是，项目中没有一个站在全局角度关注开发过程的角色，后端开发经理目前可能比较符合这个角色， 但是他是在开发的角度思考问题
我也是不太明白测试环境开发为什么不给出来，本来测试环境他们也不会用
commit 规范这个问题跟开发领导谈了一下，前端负责人表示没问题， 后端负责人表示非常不愿意...

怎么感觉 你们的测试和开发用的是一套环境？尽早能有 cicd 流程搭建属于自己的测试环境，目测是可以让你摆脱尴尬的处境的。。。而且我感觉楼主应该是爱学习的人，不妨着手和同样热爱学习的同事们，探讨一下。。。

“项目中没有一个站在全局角度关注开发过程的角色”，这个一般是项目中所有开发的老大担任这个角色，你们组织里没有这样的一个人吗？

“我也是不太明白测试环境开发为什么不给出来”，你提出测试管理测试环境的时候，开发没有说出他们不想让出的理由么？
沟通方式上，建议最好是测试老大和开发老大先通气，达成共识再会上提出，比较好。要不在一些会议上贸然提出，开发没有心理准备，第一反应会偏反抗一些（人都是天然抗拒被改变的）。

“前端负责人表示没问题， 后端负责人表示非常不愿意”，那就先从前端推起呗。推动后有效果，再用这个效果去推动后端。

开发老大没有管理这些具体的事情，跟项目组长沟通后，前端组长表示可以，具体负责发布的前端同事请假，等他回来后对接一下；
后端同事我也沟通了，具体实施和为什么提出这个想法； 表示需要考虑一下，看有没有什么其他问题， 后续需要再沟通

我也是觉得冒然在会议上提出应该不太好，所以都是私下沟通，大家都认同了再到会议上同步
等前端这边弄好之后，可能后端这边就好说服一点了

我感觉可能是开发过程没有规范吧，测试环境我们介入后，可能给了开发一个不好的信号

我感觉最大的原因可能是我们测试老大不是特别支持这个事情， 觉得测试环境让开发来管我们事情会少一点， 人微言轻导致推动很缓慢

把测试环境打包权限拿过来之后， 开发分支到测试分支的合并问题可能还需要沟通一下，一步步来吧