在 CI/CD 中如何管理前端和后端之间的依赖关系？

Question

我将描述我的设置以使问题不那么抽象，但它们似乎并不特定于我的情况。

语境

我们有 Python-Django 后端和 VueJS 前端，每个都在一个存储库中，使用 Portainer（使用堆栈）配置和部署 Gitlab-CI。每个存储库的生产分支中的提交遵循以下路径：

1. 犯罪
2. gitlab-ci 管道：
   1. 构建 docker 镜像
   2. 测试图像（前端针对部署的后端进行测试）
   3. 将图像标记为生产：最新
   4. 将图像推回 gitlab 注册表
   5. webhook portainer中对应的service（frontend/backend）来更新部署的镜像
3. 搬运工：
   1. 拉图
   2. 部署

问题

部署同步

想象一下，我们在前端和后端都进行了重大更改，并且两者都将与以前的版本不兼容。因此必须同时部署新版本。

在我们当前的设置中，我们必须首先部署后端（什么会破坏已部署的前端），然后部署新的前端，修复生产，但有一个“停机”期。

测试的分支依赖

有时，当我们在前端开发分支 feature-1 时，必须针对后端的分支 feature-1 对其进行测试。

在我们当前的设置中，前端中的所有提交都针对部署的后端进行了测试（为了避免在 CI 中复制后端，仅使用生产 API 地址），在这种情况下会导致错误的测试结果。

后端集成测试

当提交到后端时，它可能会破坏前端。

目前后端没有针对前端进行测试（只有另一种方式）。

可能的解决方案

对于部署同步问题，我考虑创建另一个存储库，该存储库只有一个文件，指定应部署的前端和后端的版本。此存储库中的提交将导致 Portanier 的两个服务 webhooks 被“卷曲”以进行更新（后端和前端）。这并不能保证同步更新（在 Portainer 中可能会失败并且不会有回滚），但它会比当前设置更好。

我不确定这里应该用什么来指定版本：commit hash、git tag、branch、docker image version...最后一个可能避免了重建和测试图像，但我认为图像名称和版本是固定的Portainer 的堆栈定义，并且不容易自动更新。

对于分支依赖性测试，我考虑在每个存储库（前端和后端）中都有一个文件，指定要测试的后端/前端的哪个分支。但是每个存储库的 CI 必须复制整个部署环境（例如，运行一个新的后端和前端来测试每个前端提交）。这也将允许后端集成测试。由于我们使用的是 Docker，这并不是很复杂，但是每个 CI 管道都会花费额外的时间......此外，当第一个存储库（前端或后端）提交时，它会引用另一个中仍然不存在的分支存储库，并失败...

这些解决方案对我来说似乎很尴尬，特别是如果这些是 Docker 的 CI/CD 常见问题。当我们向组合中添加更多存储库时，它会变得更加丑陋。

备择方案？

感谢关注！

（编辑：出于好奇，我当前的设置基于本文）

Answer 1

\n

部署同步

\n

想象一下，我们正在前端和后端进行重大更改，并且两者都将与以前的版本不兼容。因此新版本必须同时部署。

\n

在我们当前的设置中，我们必须首先部署后端（这将破坏已部署的前端），然后部署新的前端，修复生产，但有一个“停机”期。

\n

\n

我不是 portainer 用户，但也许你可以依赖一些docker-compose.yml文件左右，收集后端和前端的版本？在这种情况下，它们可以同时更新\xe2\x80\xa6

\n

事实上，根据portainer/portainer#1963和这个文档页面，portainer 似乎支持 docker-compose 和 swarm 堆栈。

\n

另外，docker swarm 提供了一些无需停机即可执行服务升级的功能，如本博客中所述，但我不知道在 portainer 中可以配置到什么程度。

\n

\n

可能的解决方案

\n

我不确定应该使用什么来指定版本：提交哈希、git 标签、分支、docker 映像版本...最后一个可能避免重建和测试映像，但我认为映像名称和版本是固定的在Portainer的堆栈定义中，并且不容易自动更新。

\n

\n

虽然提交哈希是精确的标识符，但它们可能不足以方便地识别不兼容的版本。因此，您可能希望在 Git 后端存储库上使用标签（和/或分支）来依赖语义版本控制。

\n

然后，您可以相应地标记相应的 Docker 镜像，如果需要，可以引入一些同义标记。例如，假设后端已经发布了 versions 1.0.0, 1.0.1, 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.2.2，标准做法是像这样标记 Docker 镜像：

\n

\n
• project/backend:2.0.2= project/backend:2.0=project/backend:2
\n
• project/backend:2.0.1
\n
• project/backend:2.0.0
\n
• project/backend:1.1.1= project/backend:1.1=project/backend:1
\n
• project/backend:1.1.0
\n
• project/backend:1.0.1=project/backend:1.0
\n
• project/backend:1.0.0
\n

\n

（如果需要，删除旧图像）

\n

\n

后端集成测试

\n

目前，后端尚未针对前端进行测试（仅以另一种方式进行测试）。

\n

\n

好的，但我想你的方法是相当标准的（前端取决于后端，而不是相反）。

\n

无论如何，我记得即使被测系统是前端，也可能值得实施单元测试（开发和运行成本低于集成测试），以便管道中的第一阶段快速运行这些测试在触发必要的集成测试之前进行单元测试。

\n

\n

测试的分支依赖性

\n

在我们当前的设置中，前端中的所有提交都会针对已部署的后端进行测试（为了避免在 CI 中复制后端，仅使用生产 API 地址），在这种情况下会导致错误的测试结果。

\n

\n

这可能不够灵活：一般来说，CI/CD 假设集成测试是使用专用后端实例（“dev”服务器或“pre-prod”服务器）运行的，如果所有集成测试和系统测试都通过，则镜像部署到“prod”服务器（并进行监控等）

\n

我从你的帖子中看到你正在使用 GitLab CI，它有一些原生的 Docker 支持，所以也许这可以很容易地实现。

\n

一些提示：

\n

\n

• 假设后端已被修改为非向后兼容版本，并且相应的 Docker 镜像在注册表中可用（例如 GitLab CI 的镜像）。然后，您可以在前端配置中更改该图像的规范（例如，在 GitLab CI 配置文件中替换project/backend:1为或 so）。project/backend:2

  \n
\n

• 您的后端可能是作为 REST Web 服务实现的，在这种情况下，您可能还想在 URL 中添加版本前缀，以便当您从 切换到 时project/backend:1（project/backend:2具有不兼容的更改），如果满足以下条件，则可以同时部署两个版本：需要，到 URLhttps://example.com/api/v1/\xe2\x80\xa6和https://example.com/api/v2/\xe2\x80\xa6

  \n
\n

\n

此外，除了只有两个带有 CI/CD 的存储库（后端单独测试，前端针对后端的相关版本进行测试）的解决方案之外，还可以考虑您首先建议的解决方案：

\n

\n

对于部署同步问题，我考虑创建另一个存储库，该存储库只有一个文件指定应部署的前端和后端的版本。此存储库中的提交将导致 Portanier 的服务 Webhook 被“卷曲”以进行更新（后端和前端）。这并不能保证同步更新（Portainer 中可能会失败并且不会回滚），但它会比当前设置更好。

\n

\n

您可以稍微修改此方法以避免此类部署失败：您可以将一些 CI 设置添加到第三个存储库，该存储库仅包含一个文件左右docker-compose.yml，并将集成测试从前端 CI 移动到“撰写”CI\xe2 \x80\xa6

\n

（仅供参考，这种方法类似于DigitalOcean 教程中建议的方法，其中集成测试是通过某些docker-compose.test.yml文件实现的。）

\n