内部公共包/二方库这些，需要使用 nexus 之类的内部 maven 仓库来管理，基础模块预先发布好，业务模块才可以编译、发布

TO 楼主：不要妄图自动化一切，除非你们的 cmdb 做到了高度实时有效，即便是这样，也要花费很多精力：维护组件目录映射关系，通过变更文件清单找到所属组件，从 cmdb 查找、解析所涉组件所有的依赖组件……并且递归查找到 root，然后自上而下去发布基础组件，最后再发布你当前变更所涉及到的组件~

首先你的登录服务必须是一个独立的仓库，或者是一个大 project 里面的一个独立的 module，以 spring 为例，可以参考https://www.cnblogs.com/toutou/p/project_module.html
maven build 的时候可以这样做：https://www.cnblogs.com/wenbozhou123/p/7885905.html

都是一个百度就能解决的问题

我们抛开开发自己背不背锅的问题，只说测试工程师，归根结底这是个卷不卷自己的问题

• 如果对自己、对自己的职业有所要求，那么一切 “Bug 藏的太深”、“测试环境无法复现” 的理由都不是借口，因为如果你愿意卷一下自己和自己所从事的这个职业，你一定会想到、找到办法规避这个问题，不然那些单测、静态分析、渗透攻击、埋点、监控、生产流量导入乃至混沌工程之类的解决方案要来干吗的？—— 如果愿意承认这个世界上有至少一种手段来规避这种漏测问题，那这个锅就背的心安理得了。

• 如果说将自己和测试这个职业定义为仅仅是点一下、看一下、验一下的角色，那么遇到比较复杂难以测到的问题，出现漏测自然觉得无所谓，因为我能力有限啊，发现不了还能怎么办？要么你牛逼你来？再说你也不看看我拿几毛钱工资？凡此种种，肯定不会觉得自己应该背这个锅的。

当然，那种用户一眼就能看出来的问题，无论你对自己是什么要求，只要没测出来，那就认了锅吧，不然就真的不要脸了。

卤煮的观点高度赞同，速成也速失，或者经不起推敲、拷问，做完事情自己的能力没有得到多大提高

酒吧不好，来我们玉兰四期吧，我请客

好吧，实话说，我前面回复的时候说『预设了很多背景条件』，然后想说就像某些沙雕面试官的出题套路一样，结果觉得太那啥了，又憋回去了，不成想还真是……

信用卡额度这么明显的因素不用考虑吗
另外，也赞成拒绝这种垃圾需求，连用户场景都没交代……大约是预设了很多背景条件，但是都没说出来，觉得所有人都默认明白

你发到活动区，应该就不会有人跟你较这个芝麻真了

想当然了吧，工业 App 范围太大了，有些可能涉及自动控制的，不重视测试？
反正我不信，不然每年因为这个要死多少一线工人呢

记得：广度是深度的副产品，如果你觉得你自动化测试做得很好了，但是只会自动化测试等很容易被替代，说明你的深度根本不够，没找到解决问题的核心方法套路。
举个例子：做 GUI 的自动化测试，面临分布式、兼容性问题的时候你要解决的就会有测试实验室/云测服务的构建，市面上的现有解决方案无论多优秀，在你具体的场景落地的时候都会有这样那样的问题，你要解决下去就势必需要掌握这些周遭的技能，比如自己加特性、改 BUG，了解开源协议背后的知识，学习采购和设备管理，保不准还要掌握 docker、k8s、openstf 等等之类的技能，然后保不齐又要辐射出 dockerhub、helm 等等等等……所以你所说的广度这就已经很可观了，关键是：你真的做到了追求深度了吗？