在 GAE 项目/应用程序级别与服务/模块级别实施 CI/CD 环境的优势？

Posted 2023-02-24

【中文标题】在 GAE 项目/应用程序级别与服务/模块级别实施 CI/CD 环境的优势？

【英文标题】：Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?

【发布时间】：2017-08-30 08:19:20

【问题描述】：

在Naming Developer Environments 中，Google 建议了 2 种方法来为 GAE 应用程序实现不同的 CI/CD 环境

基于同一项目/应用内的不同服务（过去称为模块）：

如果您选择仅使用 多个服务，您可以为每个服务创建一个 App Engine 项目 您的环境并相应地命名它们，例如web-app-dev， web-app-qa 和 web-app-prod。

基于不同的项目/应用：

或者，如果您选择创建微服务应用程序 通过使用多个项目，您可以实现相同的分离 环境之间，但您需要使用更多项目，例如 web-app-dev、web-app-prod、user-service-dev 和 user-service-prod。您将需要使用代码模式来确保 dev 项目只调用其他 dev 项目和 prod 项目只调用其他prod 项目。

上述文档 sn-ps 中的措辞似乎表明这两种方法大致相同，但两种方法之间至少存在一个显着差异：基于项目/应用程序的方法确保数据隔离，而服务/基于模块的没有 - 数据存储和内存缓存由所有服务共享。

Comparison of service isolation and project isolation 中记录了从隔离角度对这两种方法进行更详细的比较：

下表提供了使用多个 微服务架构中的服务和多个项目：

我的问题是：除了上述差异之外，使用基于项目的方法与基于服务的方法相比还有其他优势吗？或者任何可能被视为不利因素的东西？

【问题讨论】：

某种程度上相关：使用服务版本控制来实现环境（或者更确切地说，为什么这不是一个好主意）：***.com/questions/40192557/…

这个旧线程中的一些优点：***.com/questions/3793860/…

【参考方案1】：

基于项目的方法还允许您将计费问题和 IAM 角色分开。

您可以使用不同的信用卡收费，或者只是单独设置计费限额（谁希望 prod 因开发错误超出您的计费限额而下降？）。您还将获得单独的计费报告，以便我们更轻松地确定产品与开发的成本。

基于服务的方法可能会最大限度地减少额外的管理工作。例如，如果由于某种原因您需要设置 *** 或其他网络方面，则单个项目意味着您只需配置一次，而不是每个项目一次。