持续交付 - 微服务发布/版本控制-Java 学习之路

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

服务A - >构建 - >包 - > QA - >暂存 - > 生产环境
服务B - >构建 - >包 - >质量保证 - >分期 - > 生产环境
服务C - >构建 - >包 - > QA - >分期 - > 生产环境

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

我们想要做的是使用如下所示的伞形Helm图表对发布进行分组（Parent A）：

Parent A - > Build - > Package - > QA - > Staging - > Production
服务A.
服务B.
服务C.

我正在努力想办法这样做而不必手动释放每个服务，然后更新父图表中的版本 . 有人这样做是以自动方式吗？

2 回答

0
如果我理解你的问题，你可以使用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
回复于 2024-04-18T20:49:22+08:00
0
我可以分享关于我们如何发送代码的简化视图Codefresh：
- 每个微服务都有它自己的git repo和helm chart .
- 每个服务代码库都是版本化的（无论图表如何），例如在 package.json 中 .
- 每个舵图也都有版本 .
- 当devs更新服务时，他们必须在代码中碰撞版本 .
- 我们还有一个Helm超级图表，列出了所有的微服务图表chart requirements .
  代码库上的
- CI管道构建了一个docker镜像（用代码版本标记）和一个helm图表（用代码版本标记） . 这还没有部署任何东西 .
- 如果开发人员想要部署，他们会编辑超级图表中的需求文件，需要新版本 .
- 超级图表上的CD管道进行了掌舵升级 .
这是一个非常简化的描述 . 实际上，管道也做了类似的事情：
- 自动处理npm和github版本
- gate基于semver更新范围
- 在PR /分支上自动配置ad-hoc环境（启动新环境以测试/共享您的更改）
- 秘密管理
说实话，这不是一个简单的管道，但是，嘿，我们是CI / CD公司所以这是我们的面包和黄油 .
客户经常要求我们分享更多关于我们已经完成的工作，甚至为客户复制它，我们很乐意这样做 . 随意ping我 .
回复于 2024-04-18T20:49:22+08:00

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

2 回答

相关问题