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

EN

部署同步 假设我们正在对前端和后端进行重大更改，这两者都将与以前的版本不兼容。因此，新版本必须同时部署。 在当前的设置中，我们必须首先部署后端(将破坏已部署的前端)，然后部署新的前端，修复生产，但要使用“下行”期。

我不是一个门户用户，但也许您可以依赖某个docker-compose.yml文件来收集后端和前端的版本？在这种情况下，它们可以同时更新，…

事实上，根据端口/端口#1963和这个文档页面的说法，portainer似乎同时支持坞构建和群堆栈。

此外，如这个博客中所记录的那样，坞群提供了一些特性，可以在不停机的情况下执行服务升级，但我不知道在门户程序中可以在多大程度上配置这些功能。

可能的解决办法 我不确定在这里应该使用什么来指定版本:提交散列、git标记、分支、docker映像版本.最后一种方法可能避免了重建和测试映像，但我认为图像名称和版本在维护者的堆栈定义中是固定的，并且不容易自动更新。

虽然提交散列是精确的标识符，但它们可能不方便识别不兼容的版本。因此，您可能希望使用Git后端回购上的标记(和/或分支)来依赖语义版本化。

然后，您可以相应地标记相应的Docker图像，并在需要时引入一些同义标记。例如，假设后端已经随版本1.0.0, 1.0.1, 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.2.2发布，标准实践包括标记Docker映像，如下所示：

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

(如有需要，删除旧图像)

后端集成测试 目前，后端没有针对前端进行测试(只有另一种方式)。

好的，但我想您的方法是相当标准的(前端取决于后端，而不是相反)。

无论如何，我记得，即使被测试的系统是前端，实现单元测试(与集成测试相比，开发和运行这些测试成本更低)也是值得的，以便在触发必要的集成测试之前，管道中的第一阶段能够快速运行这些单元测试。

测试的分支依赖关系 在我们当前的设置中，前端中的所有提交都是针对已部署的后端进行测试的(为了避免在CI中复制后端，只使用生产API地址)，在这种情况下会产生错误的测试结果。

这可能不够灵活:通常，CI/CD假设集成测试是使用专用后端实例("dev“服务器或"prod”服务器)运行的，如果所有集成测试和系统测试都通过，则映像被部署到“prod”服务器(和监视服务器，等等)。

我从您的文章中看到，您使用的是GitLab CI，它有一些本地码头支援，所以这可能很容易实现。

有几个提示：

• 假设后端已在非向后兼容版本中进行了修改，并且相应的Docker映像在注册表中可用(例如，GitLab CI)。然后，您可以在前端配置中更改该映像的规范(例如，在project/backend:1 CI conffile中将project/backend:2替换为project/backend:2左右)。
• 您的后端可能实现为REST，在这种情况下，您还可能希望在URL中添加一个版本前缀，以便当您从project/backend:1切换到project/backend:2 (不兼容的更改)时，如果需要，可以同时将两个版本部署到URL https://example.com/api/v1/…和https://example.com/api/v2/…

此外，除了只有两个CI/CD的repos (后端分别测试，并根据后端的相关版本进行了前端测试)之外，您建议的解决方案也可以考虑：

对于部署同步问题，我考虑创建另一个存储库，其中只有一个文件，指定应该部署的前端和后端版本。这个存储库中的提交将导致Portanier的服务and钩子被“卷曲”以进行更新(后端和前端)。这并不能保证同时进行更新(在维护者中可能会失败，也不会出现回滚)，但这将比当前的设置更好。

您可以稍微修改此方法，以避免出现这样的部署失败:您可以在第三个repo中添加一些CI设置，它将只包含一个docker-compose.yml文件，并将集成测试从前端CI移动到“组合”CI…。

(FYI这种方法类似于这个DigitalOcean教程中建议的方法，在这种方法中，集成测试是通过一些docker-compose.test.yml文件实现的。)

测试的分支依赖关系 有时，当我们在前端开发分支特性-1时，必须>根据后端的分支特性-1进行测试。 在我们当前的设置中，前端中的所有提交都是针对已部署的后端进行测试的(为了避免在CI中复制后端，只使用生产API地址)，在这种情况下会产生错误的测试结果。

和

后端集成测试 当对后端执行提交时，它可能会破坏前端。 目前，后端没有针对前端进行测试(只有另一种方式)。

在我目前的公司中，前端(FE)和后端(BE)的Django分别位于一个存储库中。我们正在跟踪基于主干的开发。我们还使用gitlab进行CI/CD。我把你在这里提到的都说出来了，一点也不觉得尴尬。

环境与这个分支模型之间的关系.

|Branches|example|environment|

硕士级硕士级

_释放-V*_

标签：

|Tag|example|environment|

|v< >.<小>.<修补程序>V1.1.10生产

一旦创建了分支/标记或提交到定义的分支，gitlab将触发自动构建/部署。

前端必须在后端进行测试。我们用特征分支来完成这个任务。

特性/<分支-摘要>

开发人员需要确保FE和BE上都存在相同的特性分支名称。

为每个前端/后端生成一个URL，用于每个部署，类似于用于前端的-fe.<域>.com，用于后端的-be.<域>.com

在FE/BE repos中都有一个特性/我的任务。FE是mytask.< domain，BE是mytask..com

您可以使用docker编写，但在我的示例中，我们的应用程序是使用helm部署到kubernetes的。进一步说，我的FE和BE有一个由traefik管理的k8s入口。DNS记录(对于每个URL)是在(由k8s DNS控制器创建)中自动创建的，后端使用的是每次创建或更改特性分支时创建的DB和Redis。按照特征分支命名的惯例，FE知道如何连接到BE，而BE知道如何使用自己的DB和Redis。

头盔升级-安装${RELEASE_NAME} .

RELEASE_NAME是从特性/<分支摘要>(不超过63个字符)中提取的。

另外，您可以考虑初始化用于特性分支部署的数据。在我的情况下

*)开发人员将设法填充数据(可能在k8s中以init容器的形式运行脚本)。如果开发人员将提交到同一个特性分支，这将触发重新部署，所有DB / Redis的数据都将被重新输入。开发人员可能需要重新填充数据，QC可能需要从这个特性开始重新启动他们的测试。

*)避免在k8s和gitlab存储库中创建过多的资源。我在gitlab中设置了一个删除函数，以便删除BE/FE存储库中的一个特性分支，这将分别触发k8s中的部署删除。