【问题标题】:Azure Webjobs app.config Release TransformationsAzure Webjobs app.config 发布转换
【发布时间】:2018-07-18 15:13:44
【问题描述】:

我有一个 webjob 和一个 webapp(两个单独的项目),我想为所有环境构建一个工件并在发布步骤而不是构建期间进行转换,因为这样我必须为每个环境创建一个工件。所以我为每个环境创建了两个单独的工件(一个用于 webapp,一个用于 webjob)并在发布到应用服务期间应用 xml 转换,现在一切正常,除了 webjob 的转换文件放在根目录中webapp,这不是我打算做的。我希望将文件放置为app_data\jobs\continous\myjob\myjob.exe.config

我已经看到了缓慢的 cheeta 和 CTT 转换,但这些超出了这个问题的范围,因为它们只在构建时进行转换。

【问题讨论】:

    标签: azure-devops azure-web-app-service azure-webjobs azure-pipelines azure-pipelines-release-pipeline


    【解决方案1】:

    您可以使用 Kudu api 运行命令来复制或删除文件。

    更多关于build/relase时如何调用kudu api的信息,可以参考:How to access Kudu in Azure using power shell script

    【讨论】:

      【解决方案2】:

      您应该在构建期间进行转换,并且您的转换应该作为构建中的标记而不是实际目标值发生。然后在部署中,您可以将令牌值替换为实际的目标环境值。这是打包和部署任何应用程序类型的正确方法。

      步骤应该是

      1. 在构建中使用转换标记化配置(使用此extension task
      2. 将标记化配置打包为构建输出
      3. 在部署时将目标值应用于令牌(使用替换令牌任务附带marketplace extension,它通过自动映射名称将已定义配置的值替换为发布变量值。换句话说,令牌应该是参数名称)

      Here is an example done on a windows service。但它也适用于 webjobs(已经测试过),它是正确的解决方案。

      【讨论】:

      • 这种方法仅在我们将 webjob 项目添加到网站然后从该网站创建人工制品时才有效。但我们希望将网站和 webjob 保留在单独的应用服务计划中,以增加我们的应用程序弹性,这样当 webjob 需要更多资源时,它就不会成为 webapp 的瓶颈。
      猜你喜欢
      • 1970-01-01
      • 2015-06-18
      • 1970-01-01
      • 2017-11-19
      • 1970-01-01
      • 2016-04-12
      • 2014-12-12
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多