最近感觉 jenkins 的 pipeline 写烦了，调试起来也比较麻烦。
突然感觉，CI 过程及其配置管理依赖工具的 DSL 不太好。哪天要把 jenkins 的 CI 迁移到 github action 上，又要重写。
之前我们的部分 CI Job 的工作会有一些 python 脚本（使用 python 是因为主要开发语言是 python ）来处理，而 jenkins 或者 github action 负责调用，以及传入一些环境变量、security 配置。 像这种 job ，在不同 CI 工具间切换，会比纯 jenkins pipeline 的好迁移。
如果把这种 Job 的形式进行到底，像这样：

CI job 由团队熟练的开发语言来实现，抽离一些公共模块出来复用
CI 所需要的 security 配置加密到代码里，使用类似 sops 或 transcrypt 方案
jenkins/github action 这类工具负责解密配置，以及调用 ci 工具

不知道这样的方案如何？ 很想知道各位的 CI 方案是什么样子的？有什么想法。

不论如何, 把 sensitive 的配置加密到代码里都不是首选方案吧. 把这些 sensitive 配置 抽取为输入变量 , 并转换为 自动从环境变量取值, pipeline 中由 jenkins/github actions 等从自身的 secret 或第三方 secret manager 获取 secret 并注入到 运行时环境变量 来实现相应配置的赋值, 这样才是一般比较广泛使用的平衡了安全性与复杂度的方案吧.

在 CI 的描述语言里直接写代码就是邪路啊，既不方便管理也不方便迁移。不都是写在各种 bash / python / powershell 这种脚本里，然后 ci 只负责调用和设置环境变量么

关于: 是应用 CI 自身的模块来编写更原生化的 pipeline, 还是使 CI 基本仅负责调用,组织和粘合 shell/python script 的执行. 我个人倾向于后者, 确实是会更方便在多种 CI 工具之间迁移.

密码有个叫 sealed secret 的工具，可以以加密形式在代码中直接储存密钥，然后在 k8s 中再还原为 secret

前几天刚把 CI 从 Jenkins 迁移到 Gitlab Pipeline 上。迁移的时候做了亿点点改造，改完之后基本和你说的一样，CI 仅负责基本调用，主要逻辑都在 Python 中实现。Gitlab Pipeline 被触发后，设置一系列的环境变量，调用 Python 脚本。在 Python 脚本里做真正的工作：解析环境变量，编译，跑单测、归档啥的。这样本地开发调试脚本也方便，后续迁移 CI 平台也更容易。

我们的构建脚本全都拿 PowerShell 写的,CI 只是负责传递参数和调用，所以无论迁移到哪个平台都很简单。

原来大家都是不依赖 CI 工具的语法写 CI Job 的~~ 关于 secret ，至少我感觉 Jenkins 里的 secret 不是很好用。才萌生了把配置放入加密代码中的想法。 谢谢~ 我去了解下。

Jenkins 里的 secret 管理确实不是很好的选择, 但也胜过记录"加密"过的密码在代码里, 再在 pipeline 里"解密". 这种方式实质还是把密码保存在了 git repo 里, 是尽量要避免的. 要是用 GitHub Actions 的 CI/CD, secret 也不会在多个途径使用的话, GitHub 里的 Secret 管理也是可靠的.但一般生产环境, 一个第三方的 secret 管理工具[SaaS 或 self-host]还是需要的. HashiCorp 的 Vault 就是很好的选择, 能 SaaS, 也能公司自己 self-host, 国内国外都用得很广泛, 第三方支持也很广泛. 各种 CI/CD 工具基本都支持动态从其中获取 secret.

我的做法：jenkins pipeline + nacos为什么不上 k8s secret/config 而用 nacos：项目小，方便

makefile 或者 justfile 实现具体细节，比如文件拷贝和编译ci 主要是利用平台的权限拉取代码，和最终的上传到制品库，运行是传入参数啥的调用 makefile 之类的，这样迁移成本小

＃8 Bitnami Sealed Secret 就是为了解决如何把加密过的密码（或任何 secret ）放在 git repo 里诞生的，解决 "I can manage all my K8s config in git, except Secrets." 的问题。Sealed secret 使用证书生成加密过的 secret.yaml 便于安全存放在 git repo 中，在 apply 到 k8s 集群后通过 controller 解密为正常 base64 enc 的 secret 。

确实有这种问题，用 pipeline 迁移不好弄，我们现在基本上全是用 bash 写的脚本，然后通过 jenkins 传入环境变量

我自己的项目用的 drone,凑活能用

用 gitlab 的话当然首选 gitlab ci ，不仅方便，而且还有 gitlab 自带的 ci/cd 标签，可以放在 readme 里，这精美小标签反正我是没法拒绝

试试 teamcity ，UI 好看，前段时间从 jenkins 全部切到了 teamcity

jenkins 支持在它界面里配置密码这些 ，k-v 形式。pipeline 里面用 key 去获取。不过可能是商业版才有

shell 打倒一切

我们是自己开发的平台，调用 Jenkins 的 API 做打包发布，没有使用 Jenkins pipeline ，更适合自己公司的场景吧

自研平台，6 的丫皮， blog.ops-coffee.cn/s/YjfTypcHD03fTGLV_JsqWw

flow.aliyun.com/

物理 secret+物理 yaml+脚本 「环境变量」「配置」「物理文件」基本上都给脚本和 yaml 做文件夹管理方便物理迁移，jenkins 只执行任务流，管理一些版本号之类的自定义配置。动态配置交给 nacos

gitlab 纯跑 ci 。cd 自研中。。受够了 jenkins 那个破 ui 还有非常不自然的逻辑了

原来 teamcity 有免费的自托管版本，之前还一直必须收费呢，下次试试！我也受不了 Jenkins 那上古的 ui ，相信 jetbrain 家的产品品质应该会没问题

国内制造业，Tekton+自研 UI ，不管是原来用的 Drone 的还是现在 Tekton ，针对每个 Step 就做参数变量化的管理，目的就是可移植且更容易推进各业务 IT 的 CI 标准化

可以考虑 drone 或者其开源代替，woodpecker ，Jenkins 管理起来比较麻烦，可以作为第二选择