如何处理微服务（或应用程序）（尤其是Jenkinsfile）中的CI管道重复？

Question

我想知道人们如何处理CI管道中的微服务（或应用程序）之间的重复（尤其是Jenkinsfile）。这是一个应该解决的问题（如果有的话，有什么建议吗？）。我喜欢拥有更独立的服务，但是我可以看到它们如何被视为重复代码。

问题：

• 这是需要解决的问题吗？
  • 如果是这样，其他人如何解决呢？
  • 如果是的话，您会走多远？您会做什么（灵活性与重复性）？

想法：

想法1-詹金斯图书馆：

一种方法可能是常见的Jenkins库存储库，但是感觉上它会在服务之间造成严重的耦合（因此很难更新和前进）。

我可以看到两种解决方法：

1. 几行代码（导入库，然后运行一个共享函数，例如mvnSharedPipeline（））-建议这样做，但对我来说太不灵活了。

2. 每个阶段重用共享功能（或部分阶段），例如阶段“构建”将调用共享的mvnBuild函数或其他内容-基本上：https://medium.com/@jackrwstevenson/the-reusable-microservice-pipeline-pattern-41742b2e640a

想法2-Docker文件：

我能想到的另一种方法是使用Docker容器。

我可以看到两种方式：

1. 基于OpenJdk＃容器构建的工具容器，并添加了自定义脚本，例如“名称/ OpenJdk8ToolsContainer”

2. 一般的CI工具Docker容器，但为特定任务（例如docker run --rm ..pwd volume mount.. mvn build和docker run Name/CustomToolsContainer --rm ...pwd volume mount... lintJsonFiles.sh）调用特定容器

我的想法：

我关心的一个问题是项目对CI环境的依赖程度，例如他们在CI本身中安装了什么版本的Java / PHP / etc。我已经看到公司因为长时间测试/更新所有内容而不得不使用较旧的语言，所以我本人倾向于Docker方法（2）。就个人而言，我更喜欢在容器中运行所有内容，尤其是使用CI。不幸的是，我花了很多时间去调试为什么在CI（而不是Jenkins）中只能工作/不工作的原因，所以我对CI和开发环境之间的可复制性/可重用性非常着迷。

我也怀着这样的心态，即CI管道永远不会完美或完成，总会有一些东西可以添加/更新，例如以提高质量或更新版本。因此，我可以看到CI管道出现分歧，然后将其标准化为常见动作-但我愿意得到纠正！