好文，几次实践下来，其他还好，让开发做单元测试并达到一定覆盖率，目前还是最困难的。

有些观点不敢苟同，对大多数技术管理者来说，任何时候都要有追求技术，用技术搞定问题的心（至于是自己搞定还是培养其他人搞定另论）。见过太多优秀的工程师因为进入管理岗位，就开始正儿八经把多数精力放到管理学那些套路里，慢慢沦落为眼高手低的普通管理者。个人观点。

多搞搞户外活动

谷歌以前还是维持一个数千人的大 EP 团队，前两年大老板好像离职创业了，不知道现在的组织结构是什么样的。

什么公司啊 测试技术团队也要背收入指标？

zipkin 和 pinpoint 之间的选择是我们也纠结了很久。

哈哈 重点是数据准备的方法 里面的 case 不重要。

梁大师是我入行以后就一直敬仰的测试技术行家，有意向的同学不要错过。

最近主要精力在做研发协同平台的开发，好久没有关注 pipeline 的情况了，去看看 git 插件的更新情况，declarative 需要插件支持才行。

看来全球软件测试碰到的问题都是共性的，自动化测试的收益没有想象中那么理想，但也没有想象中那么难。

琐碎。

几位组织者忙前忙后的最辛苦了，这个圈子里需要这样的热心布道者。

有几个人找我要上海测试沙龙的 PPT，我还是统一发这里吧，有几篇文章一直拖着没写，年底了你懂的，关注的同学可以先 PPT 里了解下。

期待你更多的挖掘啊，DevSecOps 在安全圈里火热，其实核心都是一样的，开发也好，测试也好，安全也好，运维也好都需要一起参与到流水线式的交付过程中来，并尽可能的自动化，持续交付和自动化是软件快速稳定交付的答案。

使用 archiveArtifacts 存档吧，建议先认真学下语法。

估计这个论坛没几个人搞过这个，纯支持。

确认下 pipeline 里的 agent 是不是指定到 slave 了。

很赞，有时间实践下

越来越靠谱了

信息安全等级保护测评，公安部网监部门针对机构和企业会有安全等保测评的要求，满足政府合规要求，同时通过测评可以发现企业整体安全体系的问题。目前现状来说，合规诉求多于检测诉求，真正要做好信息安全还是要靠自己。

如果进工作空间要看源代码我一般直接 git 看，可能是出于安全性的考虑 pipeline 对工作空间做了隐藏，应该可以拼接 url 访问，或者到服务器进对应目录查看，实在不爽自己写个插件把它显示出来。

其实除了部署和管理的便利性，docker 还有一个大的好处是开箱即用。以前我们往线上发布的是 war 包，服务器测试运维各管各的，用了 docker 以后发布的就是一个完整的容器，使用统一的镜像就可保证所有环境参数测试环境和线上是一致的，所以说容器的特性天生就符合持续交付的要求，当然前提你线上也已经开始用 docker。如果只是两三台服务器，线上也没有用 docker,我觉得用 shell 也差别不大，但对 docker 的技术必须保持关注，毕竟这个是大势。

这个@tmp目录的作用还真没深入研究过，猜测可能和 pipeline 使用了 sandbox 模式或者会定期保存 job 状态的特性相关吧，只是猜测，你可以再深入研究下。另外如果只是要进入工作空间可以使用 Jenkins {workspace}的变量参数。

这是 declative pipeline 不灵活的地方，需要等插件语法支持，不过也可以在 pipeline job 的配置里和以前一样进行配置。

大会一大堆合作伙伴中，也看到 teserhome 的合作冠名 logo 了