【问题标题】:Organize n-tier Application Branches for Azure / GitHub Publishing为 Azure / GitHub 发布组织 n 层应用程序分支
【发布时间】:2013-01-19 01:06:31
【问题描述】:

我计划开发一个多层 .NET 应用程序,在 Azure 上托管至少三个独立的层:

  • Web 前端
  • 后端/工作者角色
  • 数据库

我想将Azure Git Publishing 与 GitHub 一起使用,以分别启用每个层的持续部署。组织 git 分支以分别为每个组件启用 Azure 部署,同时在它们之间共享代码的最佳方式是什么?

我希望将所有代码放在一个 git 分支中,并在 Azure 中为每个分支设置单独的构建/发布过程。但是,我怀疑这行不通,因为:

  1. Azure 使用分支中的任何推送来触发部署。我不希望我的前端更新触发我的后端部署。
  2. 据我所知,无法配置 Azure 用来生成要发布的输出的构建命令。

如果我需要使用单独的 Git 分支,在它们之间共享代码最简单的方法是什么?

【问题讨论】:

    标签: .net git azure github n-tier-architecture


    【解决方案1】:

    尊敬的先生,

    听起来您需要为每个部署目标创建一个 git 存储库。也就是说,希望独立于任何其他层部署的每一层的存储库。再加上一个共享代码的仓库。大概共享代码编译为一些 dll,可以通过将它们捆绑为 NuGet 包与其他项目共享。例如,通过这种方式,Web 前端不会在更新共享代码时触发部署。仅当您完成 NuGet 更新时才会发生这种情况。

    也就是说,我想知道,“不希望前端更新触发我的后端部署”真的是一个要求吗?在我的工作场所,我们几乎所有的部署都是完全自动化的。没有停机时间,它只是工作。我们有时一天部署 5、10 次或更多次。我们不必关心多少次。如果你也能做到这一点,那么你就可以拥有一个大的 git 存储库。是的,偶尔不影响层的更改仍会部署该层,但是,嗯,不在乎。代码组织和共享变得非常简单。

    你的朋友, 乔什

    【讨论】:

    • 感谢您的回复。我明白你的意思是不要担心无关的部署,但我也希望部署目标的逻辑分离。同时,发布 NuGet 包或类似的东西似乎有点矫枉过正,我头 git submodules 可能是我正在寻找的答案。
    【解决方案2】:

    根据this related question,Azure git 发布仅适用于网站,不适用于云服务。

    因此,允许单独项目发布的组织问题是无关紧要的。最简单的选择是将项目保留在单个 Git 分支中并使用传统的 Azure 部署(不是自动 Git 发布)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2020-04-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-04-01
      • 1970-01-01
      • 2012-10-25
      • 1970-01-01
      相关资源
      最近更新 更多