【问题标题】:Passing adal configuration dynamically to Azure DevOps release pipelines将 adal 配置动态传递到 Azure DevOps 发布管道
【发布时间】:2019-06-08 15:45:44
【问题描述】:

我有一个使用 ADAL 库与 Azure AD 集成的 .net 核心 SPA 应用程序。我在 app.module.ts 文件中有 ADAL 配置(客户端 ID、租户 ID 等),它们当前指向本地开发环境值。

我正在使用 Azure DevOps 构建和部署应用程序。我有一个 Azure 构建管道来在 CI 周期结束时构建和发布工件,我有一个发布管道来获取工件并使用 IIS Web 部署任务将其部署到 QA 环境(Windows VM)。

发布管道成功地将应用程序部署到 VM,但它仍然使用旧的开发值进行 ADAL 配置,因此身份验证在 QA 服务器上不起作用。

我知道我可以使用 environment.ts 文件根据我要部署到的环境动态传递 ADAL 配置,但问题是构建管道的发布工件任务默认使用'-- prod' 参数来构建我用来部署到 QA 的工件 (.zip),这意味着无论我部署到什么环境,它都将始终使用 environment.prod.ts 文件。

我的想法是在 CI 阶段结束时构建一次工件,然后将相同的工件部署到任何更高的环境中。如何使用 .net Core + Angular 7 + MSAdalAngular6 + Azure DevOps 实现这一目标?

谢谢!

【问题讨论】:

    标签: angular .net-core azure-devops adal adal.js


    【解决方案1】:

    您所描述的是每个环境具有不同的配置。签入每个环境的配置并在运行时让应用确定它在哪里运行以及要加载哪个配置,这样往往不太容易出错。

    您可以通过 Azure 门户或其他机制设置特定的环境变量来做到这一点。

    【讨论】:

      【解决方案2】:

      我总是通过配置的方式是构建一次您陈述的想法。使用标记化的标准配置文件,然后在 Azure DevOps 中,您可以在发布管道中使用“替换令牌”之类的任务,该任务将使用管道变量(替换令牌时可能需要取消归档然后重新归档) .

      我的团队通常有一个默认配置,其中包含用于开发的本地条目和一个用于部署的标记化配置(在发布期间被重命名),这也允许您将秘密置于源代码控制之外。 例如appconfig.json 和 releaseconfig.json

      另一种常见的方法是将所有配置作为环境变量存储在服务器上,这有其自身的问题,并在应用程序启动时检索它们。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2021-06-24
        • 1970-01-01
        • 1970-01-01
        • 2020-05-11
        • 1970-01-01
        相关资源
        最近更新 更多