【问题标题】:Build and Release Ember App to Azure Service Fabric构建 Ember 应用并将其发布到 Azure Service Fabric
【发布时间】:2019-07-15 11:52:32
【问题描述】:

目前我们的流程可以运行,但由于需要将前端 Ember 应用程序构建到我们拥有的每个环境(5 个环境)中,因此需要花费太多时间。因为我们永远不知道当我们发布它时哪个环境可用。 我们打算添加更多环境,因为每个开发人员都应该有自己的工作开发环境。 (因为后端)

我们如何做到这一点,是我们创建一个前端构建和一个创建工件的后端构建。 现在每个环境的前端构建大约需要 2 分钟。 ember build --env=test 和 ember build --env=acceptance 和 ember build --env=development ...等等

创建工件后,我们会根据我们发布的环境选择正确的发布版本(这通过发布管道完成)。

我的问题是,我们能否以某种方式不依赖于环境来构建前端 ember? 我想指出,我们使用的是 azure service fabric。

【问题讨论】:

  • 如果您可以在启动时配置它 - 我没有发现问题
  • 如果是配置发生变化,我们使用github.com/blimmer/ember-cli-server-variables 允许我们的服务器生成的 index.html 文件将配置注入到它加载的 ember 应用程序中。这让我们只构建一个应用程序,但在多个地方使用它。

标签: ember.js azure-devops azure-service-fabric azure-pipelines-release-pipeline


【解决方案1】:

我不认为有多个 Ember 构建,因为每个构建都会不同(即生产与开发)。 您可以在一个 CI 构建/构建任务中对每个构建进行批处理,并生成要在发布管道中使用的工件。

在一个构建任务中按顺序为您拥有的每个环境(假设您使用 Ember-CLI)运行一次以下命令。

ember build --environment={{YOUR-ENV-HERE}} --output-path="dist/{{YOUR-ENV-HERE}}/"

然后,您可以将整个 dist/ 文件夹作为工件上传,并将发布管道中的每个环境限定到相应的工件子目录,或者您可以将 /dist 中的每个文件夹作为单独的工件上传,并将每个环境限定在您的发布管道到其相应的工件。

【讨论】:

  • 是的,这基本上就是我们正在做的事情,但是对于构建(可用于任何版本),我们需要为所有现有环境构建。这需要太多时间,而且我们可能最终只在一个环境中使用。
  • 只有配置会根据您的环境而改变吗?还是ember代码也变了?
【解决方案2】:

只有它改变的配置。基本上是 api 端点

【讨论】:

    猜你喜欢
    • 2017-04-07
    • 2016-12-05
    • 2017-04-17
    • 2019-01-17
    • 2016-03-31
    • 2016-12-06
    • 2019-11-30
    • 2015-12-24
    • 2018-07-29
    相关资源
    最近更新 更多