问题描述
希望使用Gitlab和K8S来部署由多个应用程序组成的解决方案。他们的SaaS应用程序由以下组成：
– 后端应用程序，主要是API（django）
– 用户应用程序（React）
– 管理员应用程序（React）
两个前端应用程序都连接到API。
目前，后端和用户应用程序位于同一个Gitlab仓库中，并使用CI/CD流水线构建应用程序、构建Docker镜像，并使用Helm Chart将其部署到K8S。Helm Chart位于同一个仓库中。
最近，用户将管理员应用程序添加到另一个Gitlab仓库中，并担心保持所有应用程序的一致性，即前端应用程序必须与API兼容。
用户考虑创建另一个仓库专门用于部署（称为Deploy Repo）。该仓库可以包含：
– 3个Git子模块，每个子应用程序一个
– Helm Chart
– 与部署相关的其他文件
用户考虑使用Git子模块来实现独立的项目。当服务准备好部署时，开发人员将在Deploy Repo中更新正确的版本。
然后，推送操作将触发CI/CD流水线，构建所有应用程序，并使用Helm Chart一起部署。
用户想知道是否可以像这样使用子模块，以及如何最佳实践地链接多个项目。
用户还关注如何仅构建已更改的子项目，而不是所有项目。
用户已经了解到可以将所有子项目的流水线链接在一起，并使用构件传递所需的文件，但不确定这是否是一个好的解决方案。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
最佳实践：使用独立的部署仓库
首先，你的想法是创建一个独立的部署仓库是很好的，这在大多数情况下被认为是最佳实践。
接下来，更合理的做法是在构建层面而不是代码层面组织事物。也就是说，你的部署仓库将记录构建产物而不是通过git子模块等方式指向代码。个人而言，我尽量避免使用git子模块，因为它们会增加很多复杂性。
具体来说，你现有的每个独立仓库将通过CI生成构建产物（Docker镜像），将这些构建产物放入某个镜像仓库，并在部署仓库中引用这些构建产物。
现在，维护部署仓库中构建产物的变化的基本方法是手动编辑构建产物标识符，可以通过引用标签来简化这个过程。例如，你可以将特定构建产物引用为myartifact:2，然后所有版本2的构建产物都会自动进入发布。比如你从2.0.0开始，然后添加2.0.1 – 它将被相应地选择。请注意，通过标签引用对于测试是可以的，但不推荐用于生产环境 – 对于生产环境，我们始终建议通过镜像的sha256摘要进行具体引用，以确保唯一性和不可变性。
为了简化上述任务，人们可以将所有构建产物镜像放入Helm values文件中，或者使用Kustomization将所有镜像标识符放在一个地方。还可以在顶部放置一些拉取请求逻辑（这并不总是需要的，因为下面的完全自动化方式可以解决这个问题）。
最后，还有一种完全自动化的方式。我们使用Reliza Hub进行自动化，将所有内容粘合在一起。简而言之，它告诉你的Helm Chart在自动化方式下使用哪些构建产物。
以下是一个展示上述概念的玩具项目：https://github.com/taleodor/mafia-deployment