持续交付 - 微服务发布/版本控制

Question

我们正在使用Spring Boot开发微服务，这些微服务被打包为Helm Charts并部署到Kubernetes集群上。每个服务都有一个Jenkins文件，我们在下面单独发布每个服务：

• 服务A - ＆gt;构建 - ＆gt;套餐 - ＆gt; QA - ＆gt;分期 - ＆gt;生产
• 服务B - ＆gt;构建 - ＆gt;套餐 - ＆gt; QA - ＆gt;分期 - ＆gt;生产
• 服务C - ＆gt;构建 - ＆gt;套餐 - ＆gt; QA - ＆gt;分期 - ＆gt;生产

这种方法相当简单，但它实际上并没有给你一个可交付的工件，你最终会出现不一致。

我们想要做的是使用如下所示的伞形头盔图（A组）对该版本进行分组：

• 父母A - ＆gt;构建 - ＆gt;套餐 - ＆gt; QA - ＆gt;分期 - ＆gt;生产
  • 服务A
  • 服务B
  • 服务C

我很难想到一种方法，无需手动释放每个服务，然后更新父图表中的版本。是否有人以自动方式这样做？

Answer 1

如果我理解你的问题，你可以使用Jenkins multijob插件解决它。并且不更新您当前的现有工作。

您的工作流程如下：

Parent Job
    Service A --> Build --> Package --> QA --> Staging --> Production
    Service B --> Build --> Package --> QA --> Staging --> Production
    Service C --> Build --> Package --> QA --> Staging --> Production

您父母的工作会触发您所有的子女工作。

我已经看到类似的问题以这种方式解决了。有时您的子服务必须一起发布，或者您的一项服务必须始终领先（服务器）。您可以在父作业中添加一些python / shell验证脚本，以确保您的最终产品始终可以发布。

https://wiki.jenkins.io/display/JENKINS/Multijob+Plugin

Answer 2

我可以分享关于我们如何发送代码Codefresh的简化视图：

• 每个微服务都有它自己的git repo和helm chart。
• 对每个服务代码库进行版本控制（无论图表如何），例如package.json。
• 每个舵图也都有版本。
• 当开发人员更新服务时，他们必须在代码中碰撞版本。
• 我们还有一个Helm超级图表，其中列出了所有微服务图表chart requirements。
• 代码存储库上的CI管道构建了一个docker镜像（用代码版本标记）和一个helm图表（用代码版本标记）。这还没有部署任何东西。
• 如果开发人员想要部署，他们会编辑超级图表中的需求文件，需要新版本。
• 超级图表上的CD管道进行掌舵升级。

这是一个非常简化的描述。实际上，管道也有类似的东西：

• 自动处理npm和github版本
• 根据更新范围更新
• 在PR /分支上自动配置临时环境（启动新环境以测试/分享您的更改）
• 秘密管理

说实话，这不是一个简单的管道，但是，嘿，我们是CI / CD公司所以这是我们的面包和黄油。
客户经常要求我们分享更多关于我们已经完成的工作，甚至为客户复制它，我们很乐意这样做。随意打电话给我。