我们之前是开发维护，后来领导说他之前公司就是测试自己维护，让我们也自己整。
目前的工作就是 Jenkins 构建，可我们 Jenkins 里有一堆项目，如果版本更新了，开发要不忙就告诉我们构建哪些，
开发要忙就得我们自己去找。
怎么找呢，每个项目里面都有个 TAG 号，如果这个号有新增，比如之前是 001，现在多了一个 002，
那就构建。
可这些序号不是所有项目同步增加的，就比如一个项目可能到 004 了，另一个项目还在 001，
所以是否有新增只能靠测试自己记录，比较低效。
要懒的记，就得所有项目都构建一遍。
这是第一件愁事。
第二件愁事是，我咔咔构建一堆之后，还有构建失败的，于是就得联系开发再查，
他们修改完告诉我，我再试着构建，就挺麻烦。
那我们以前是啥样呢？
以前开发写完代码一合并，就会触发自动构建，所以第一件愁事没了。
开发构建完自己一看失败了自己就去解决了，这样第二件愁事也没了。
可领导要我们测试自己构建，也没啥办法，就硬整吧。
大家的测试环境是测试自己维护还是开发维护的呢？
测试环境，我们也是测试进行维护；
因为我们测试，需要第一时间测试系统，所以，通过 jenkins 进行构建，发布，测试可以第一时间知道，更新了哪些内容，进行复测，有问题的话，及时找错错误日志，联系开发解决；
如果由开发构建，测试则不知道更新了什么代码，开发还要每次通知测试？
所以，由测试进行 jenkins 构建，在某些方面来看，是合理的。
可以参考 iOS 工程的 versionCode，要在工程约定上保证是自增。
具体哪个角色承担 SCM 的工作，建议看开发，QA 人员比例，哪边有精力去做都无可厚非。
合并代码前有人把关走查审核，合并代码触发自动构建，失败邮件 + 钉钉通知，成功发送提测邮件。
成功的构建基本无感，也不影响测试。
是不是要维护有多个版本线才要这么乱呀，我们项目的做法是，研发在处理版本迭代下的任务时，处理完成后说明对应项目的 TAG 号，他关闭任务后就代表已经处理完成。这样我这边测试即知道了该合那个版本，错误直接找对应研发也快。
你这个不是测试环境维护，明明只是代码版本维护。。。我们测试环境里面的数据是测试维护，测试环境的库表之类的开发来维护。至于代码版本，测试有需要就测试自己维护，开发想自测就自己去构建一个
听起来是这个构建系统不是很完善，目前只是一个裸 jenkins 在做构建工作，其实很多上下游的事情可以稍微画点时间就能舒服很多，如：
- 【可我们 Jenkins 里有一堆项目，如果版本更新了，开发要不忙就告诉我们构建哪些】，哪个版本要更新，理应是可以通过代码合入去感知的，这其实就是配置一个 merge request 的 webhook 就差不多了。如果有更严格的条件，那应该和开发一起制定规范，比如你有个 TAG 的严格自增，那稍微搞个数据库存一下最新序号做个匹配就只能哪里应该构建
- 【我咔咔构建一堆之后，还有构建失败的，于是就得联系开发再查，他们修改完告诉我，我再试着构建，就挺麻烦】。有两个解决办法，一个办法是构建失败自动通知，不同项目配置好通知不好开发；一个办法是统计构建失败频率，选出 Top 失败的项目，推开发去做规范写文档，让大家可以自行解决常规的构建失败问题，让开发自己去关注构建成功率
其实谁去维护都一样，按照你的上下文本身没有很复杂，就是大家都懒得去做改进而已
我觉得你们领导没问题啊～只是说有个前提，开发提交给测试的分支/或 tag 要稳定可部署的（比如：编译成功 + 正常启动，）。而你说的 “以前开发写完代码一合并，就会触发自动构建。开发构建完自己一看失败了自己就去解决了。”，这个是开发在开发环境要做的事情。开发自测完毕后，给出对应的分支或 tag，让你来部署测试环境，你在稳定的测试环境中完成测试。这个应该是你们领导的初衷。
第一件事，提测单里应该有版本方面的明确信息。这部分信息不能有空就给，没空就不给的呀。
第二件事，构建出问题的确是要开发自己解决的，他们修改完后应该要他们自己自测，确认没问题再给你，而不是他们改一改，你们试一试。然后构建出问题后，立马先回滚，保障环境可用，再让开发自己改。
我们之前测试环境也是我们自己负责，刚开始确实会比较磕碰，不过运作起来，会有几个好处：
1、测试对系统拓扑结构更清晰（比如某个需求改到 abc 服务，这块一定会接触到），对测试设计、后面逐步测试左移等打下基础。
2、测试自己负责环境构建，可以起到把关人的角色。试问一下，如果你测试的代码你是无法把关，开发偷偷搞点变更 + 构建，你是完全不知情的，如果刚好这部分功能之前测过没问题，也不知道有改动，所以没有改动后再复测，那到时候线上这部分代码出问题，就会影响线上，最终还是会影响测试。
3、避免有时候开发不规范的操作，引起测试环境阻塞，测试只能干瞪眼，等开发解决，自己没啥自主权。
最后，关于测试环境是测试还是开发维护的问题，我觉得核心还是 2 个问题：
1、环境管理者是否可以保障环境保持稳定，不影响测试进度？
2、我们（特指测试）是否有办法做好版本管理，保障我们测试的代码版本和最终上线的版本一致，不出岔子？
如果这两者都可以保障好，那其实测试还是开发管理都问题不大。但如果保障不好，测试管理测试环境，能更有助于保障好这两者。
你这也不是环境问题啊， 是构建问题啊。
这种事情吧（类似可干可不干，开发测试都可以干的），本质上就是谁嗓门大（话语权），谁想不干就得别人干。
这个和嗓门以及谁用的多，以及脸皮厚度都有关系。
比如我自己，脸皮厚，嗓门也不算小，就都是蹭别人的环境，然后经常自己就测个大概，细节不想测试了，交给工程开发去测试，现在也是越来越懒了，哎。
至于构建版本这种事情，为啥一定要做？能有什么好处？就几个人开发的东西，浪费时间。
提测单让开发吧版本、涉及服务都注明，自己测试自己构建一下就行喽，失败错误原因扔给开发解决就行，这又不费时间
根据现在公司的实际过程的个人见解：
开发修复 bug 后会合并代码，但不同开发相近时间段修改了 bug，让开发维护，他们可能就会在正在测试其他功能点的时候进行更新，对测试造成影响，而且维护过程有报错可能就会较长时间把测试环境挂在那里，这段时间是没法进行测试的，严重的话会影响到测试进度；
测试自己维护，可以根据禅道的单子，看到哪些 bug 被修复了，更新环境后可以去对照验证 bug，如果环境更新过程报错，也能根据之前的包把环境先还原，让开发去解决报错，能将影响降低到较小的范围；
感觉分支管理不是特别规范，我们的分支管理类似于这篇文章：https://blog.csdn.net/qq_37974755/article/details/126304583
我们上线前的测试都只在 release 分支测，至于版本号提测的时候就应该邮件里写清楚。构建失败属于冒烟未通过，这其实耽误了你的测试时间。不符合提测标准，直接发邮件打回，cc 项目组其他人，他以后就会提测前自己提前构建确定没问题了
