背景
测试环境众多，各项目组的测试环境，预发布环境，以及各层次的系统，面向用户的运营层面的系统，针对资源的下层系统。不同环境、不同项目、不同的自动化测试，以及 N 个微服务，各种组合就有数十种，然而测试人员不是很熟悉 Jenkins，开发人员也不是很了解测试的一套流程，在此背景下有了将持续集成核心收纳到平台上的想法，而不是在 Jenkins 中做各种配置。数十种配置在 Jenkins 上维护并不容易，如果在平台上将 CICD 配置做成灵活可变的，相对而言更容易些，学习培训成本也更低。
实现流程
在做此功能的时候是分了两步做的
- 先是完成的 CICD 模块：
流程中未体现平台中的其他模块或操作，在此处声明一下，测试人员配置 CICD 策略之前需先在环境管理中把自己项目组下的环境信息填写上去，用于查找环境进行自动部署，另外在接口测试平台（另一个同事开发的）配置好测试任务。开发人员在 Jenkinsfile 中增加一处调用测试管理平台的步骤，Jenkins 只执行打包，剩下的逻辑全部交给平台处理。
- 再是对开发在 Jenkins 上的操作也集成到了平台上
这种操作也不是多此一举，主要目的是在平台上做统一记录，Jenkins 上的那些信息太分散了，另外正式转测后修 Bug 后打包的动作权限也收到测试这边了，转测后要严谨，不是随随便便就可以打包丢给测试的。
如下是做出来的不美观的界面：
正式转测后，每次修 Bug 打包在此提交
CICD 策略配置界面，配置完成后可设置策略是否生效（默认生效）
我本人测试年龄不长，才 2 年，在这儿也是想听听各位大佬们的持续集成方案，或是怎么推动持续集成的落地的。
jenkins 上并不见得会有多项配置呀，用好了 webhook，根据参数判断一下就好了。我们大概有 30 几个服务吧，通过 K8s 进行 CICD.感觉在 jenkins 上没有啥特别要配置的，jenkinsfile 写个公用库
我有一个问题 ，你们多少测试人员可以接受这种 cicd 的集成方式，
韩将
回复
完全用 Jenkins 也可行，不过上文也说了，公司目前没有对 Jenkins 特别精通的人，也没有人专门负责，对于 Jenkins 的操作权限也完全在开发那边，Jenkins 对于运维，公司还没有走到一步
。Jenkinsfile 也是开发的那边管控的，放在项目代码目录里，基本上配置好后就极少去动了，为了项目并行，可能一个项目组测试环境就有多套，总不能让开发经常去改 Jenkinsfile。另外一个初衷就是统一记录，后续方便测试分析。
YangPower海盐
回复
功能刚做出来没多久，第一部分 CICD 模块做完后也推过，没什么效果，主要是测试还是以业务测试为主，自动化率不高，我也是在业务不忙的时候去搞一下平台，只能一步一步来。整体流程也是在摸索中前进。不过平台上验收测试这个模块倒是使用率 100% 了，毕竟是平台最开始的功能。
这个很有必要做，游戏产业这边打包时间太久了，打错一批包就是干等。
互联网这个做得比较超前。
看完贡献需求：
建议还可以拉取版本后，打包之前检查版本配置对不对，对了才打包，打完包在自动投递。
往上做就是做一套围绕打包和自检的流水作业线。
