时间戳

首页 > 解决方案 > 用于多层应用程序的 Azure CICD 流程

git - 用于多层应用程序的 Azure CICD 流程

问题描述

我们有 Web 应用程序：前端应用程序 + 由多个逻辑层组成的后端。这是简化的架构：

建筑学

客户端应用程序通过 web api 到达聚合器，该聚合器调用 sdk，然后更新和增强数据。Sdk 具有其他 DAL 或 Web api 的包装器。服务直接与聚合器对话。

我们使用 Visual Studio 进行开发，最初 vs 解决方案将所有层包含在一个地方：

我们使用 microsoft stack 和 azure devops 来部署 Web api 和其他应用程序，例如 Web 作业和服务。为此，我们使用 CICD 流程（我们定义了构建和发布定义 + 触发器）。

将新代码推送到 git 时开始构建。发布发生在创建新版本时。

问题是如果我们需要发布 web api，那么所有项目都已构建并执行相应的发布。所以我们决定解耦所有的东西。现在我们有几个解决方案而不是一个，我们将它们按层分解，如上图所示：

解决方案1：

解决方案2：

解决方案3：

解决方案4：

解决方案 5：

解决方案 N...

为了连接层，我们决定使用 Nuget 包，以便 sdk 在一个 nuget 中，sdk.models 在另一个中，等等......

现在的问题是，假设我想在 sdk.models 中进行更改，这里是更新所有内容的手动步骤（没有 CICD）：

  1. 添加对 sdk.models 的更改
  2. 将 sdk.models 包推送到 nuget
  3. 更新 sdk 项目中的 nugets
  4. 将 sdk 包推送到 nuget
  5. 更新聚合器项目中的 nuget
  6. 将聚合器包推送到 nuget
  7. 更新所有客户端应用程序以具有最新的聚合器 nuget 包

纯粹的疯狂...

...但它允许人们在每一层上独立工作。这可以被认为是一个优势。

现在我们回到 CICD。触发器链接到 git push 事件，如果提交了新代码，则创建构建，然后发布定义发布内容。因此，例如在 sdk 的情况下，解决方案包含两个项目：sdk 和 sdk.models，所以如果我将新代码添加到 sdk.models 并推送到 git，然后触发器会为 sdk 和 sdk.models 激活构建，并且一旦构建准备好然后发布将两个 nuget 包推送到 nuget 提要。但这是不正确的，因为 sdk 应该更新对 sdk.models 包的较新版本的引用，然后再发布。我看到如何解决它的唯一方法是将 sdk.models 移动到不同的解决方案/存储库。没关系，只是我们将有更多的解决方案和存储库需要管理，并且调试和开发将变得更加困难......

问：你觉得我说的都说得通吗？如何改进/改变它？拥有更高效的环境。请有任何建议、批评或建议。

感谢您的阅读。

标签： gitazurearchitecturecontinuous-integrationnuget

解决方案

推荐阅读