哈哈 好的等你哈 后面我转向先去搞搞安全。

整理下思路，也算是对过往工作的一个阶段性总结。

你提的几个点都很到位，这种架构很考验团队的分工和组织能力。尽可能抽取共性的能力放中台，让个性化的业务能力放业务部分，这里没有一个通用的公式，取决于各个公司的业务结构。只是相对来说，运维平台、基础架构、研发效能平台、安全平台、数据平台等，这些职能的属性比较独立，更适合放在中台，但也会阶段性发生演变，比如数据部门在公司变得庞大以后，偏业务的数据分析部分会逐渐脱离中台，甚至运维部门里面的应用运维部分也会逐渐分拆到业务线去，没有绝对不变的组织结构。

是的，可以自己设计表结构，汇总最后的运行结果数据入库，然后对结果和过程数据做统一展现，在此基础上上可以扩展出应用，团队，项目各个维度的质效看板。

思路没问题，统一应用管理后，可以有效建立应用和流水线的关系。但前期建议不用纠结于是否一定要有自己的平台替换掉 jenkins 的界面，而是先考虑如何在 jenkins pipeline 里把构建结果有效上报，执行结果统一管理了，是从 jenkins 执行还是自己的平台执行并没有想象的那么重要。

确实容器技术赋予了很多以前不敢想象的能力。

skytraveler 也是测试老兵了，玩微博的时候有关注过。

可以 注明出处即可。

能深刻理解你的痛苦，有时候确实需要去拓深到更大的视野，测试当然可以做到很深，但深陷其中路还是太崎岖和狭窄了。

需要先安装 user build vars plugin 这个插件，然后使用 wrap 调用插件中的方法，为了获取到 BUILD_USER_EMAIL 参数
If so, you should be able to run node {
wrap([$class: 'BuildUser']) {
def user = env.BUILD_USER_ID
}
}

容器管理，pipeline 流水线管理,统一配置中心，统一用户授权，gitlab 代码管理平台,链路监控，代码检查平台，自动化测试平台，全链路压测平台.....各种研发环节的基础设施都做了整合，似乎很难说哪个是核心了，业务测试和测试开发编码能力要求上会有些区别，不过基础代码能力都是需要的。

换张卡试试看吧 银行端返回的错误 截图中注意个人隐私。

三四个月吧 基于原有的一些基础设施。

谢谢反馈 用的第三方银行接口 不太稳定。

可以直接发邮箱，有时候消息太多没时间看

简历直达：jianggy@guahao.com。接口测试，性能测试，测试开发，java 开发均有岗位。

容器的申请有配额，配额范围内不需审核；应用的上线和下线这种关键节点让直接技术主管审核下还是比较有必要的，但外围的操作都可以自动化，比如一旦主管同意下线，所有资源监控点之类都会自动回收掉。

谢谢，暂时没有类似意向。阿里的云效和 Aone 很棒，向你们学习。

根据容器环境类型做服务自动隔离。

经历过才知道的痛：）

单从 web 开发来说常规的 springboot+mybatis+freemarker 足矣，主要涉及到与 Jenkins 体系,Sonar 体系,K8S 体系,gitlab，用户管理中心，分布式配置中心，统一发布平台，各监控平台等等的对接与集成。

欢迎交流，我从不否认手动环节的价值，很多时候都难以替代。原文是 “要实现持续交付，核心在于 Pipeline,要实现 Pipeline，重点在于自动化测试”。pipeline 是包括编译，代码检查，部署，测试，发布等等一系列环节的自动化实现，也包括你说的研发效能提升，这里最困难的是自动化测试，也是 pipeline 效果好坏的关键，所以我说是重点。

嗯 内部开发，底层基于各开源工具链。提供给想做持续交付平台的朋友一些思路和方向吧。