Azure Devops Angular 环境变量

Question

此时，当 Master 分支发生提交时，构建管道将基于“ng build --prod”生成一个工件，因此该工件使用项目的生产配置。之后，工件将被部署到测试和生产环境。

对于测试环境，我希望代码使用“environment.dev.ts”和生产环境“environment.prod.ts”。我怎样才能做到这一点？

Answer 1

有很多方法。我正在使用“令牌” 我的生产环境是这样的

export const environment = {
  production: true,
  host: 'https://#{{FLYMARK_MAIN_DOMAIN}}#',
  stripeKey: '#{{STRIPE_KEY}}'
};

所以当我构建我的版本时，我的版本不可用，因为我有令牌而不是变量。

然后，当我发布时，我确实有替换令牌的步骤。这需要在您部署脚本之前运行（只需根据您的需要进行修改）

steps:
- task: qetza.replacetokens.replacetokens-task.replacetokens@2
  displayName: 'Replace tokens in **/Scripts/widgets/**/*.js'
  inputs:
    targetFiles: '**/Scripts/widgets/**/*.js'
    actionOnMissing: fail
    tokenPrefix: '#{{'
    tokenSuffix: '}}#'

此任务将在我的 js 文件中找到我的发布变量，如 FLYMARK_MAIN_DOMAIN、STRIPE_KEY 并替换。

主要好处是您只需构建一次就可以部署到任何需要替换令牌的地方

PS。假设你有开发、登台、产品。现在要在由新推送到 master 触发的构建之后开发您的部署，以便在其批准时暂存您发布（天蓝色管道支持）

所以现在假设您在开发版本 100 中，您决定将其推送到 staging 并且您的团队开始测试。 3 天后，您的开发团队推动掌握了许多新内容，因此在开发时您拥有版本 123，但在暂存时您仍然拥有版本 100。团队在暂存中进行测试后，您会将相同的版本推送到生产中，因为您有信心，如果您愿意的话当您准备好部署到生产环境时，为环境使用单独的构建您在 master 中有很多新东西，也许您没有信心将其推送到生产环境。同样，每种情况都是不同的，有很多方法可以做到，我只是喜欢这种方法，因为它适合我的项目。

Answer 2

我的组织不允许在 DevOps 上安装第三方扩展。因此，票数最高的答案是不行。所以我采取了不同的方法。在构建管道中，我创建了两个构建工件：一个用于 QA，一个用于 PROD。在这些构建步骤中使用了不同的环境文件（例如：ng build --c qa）。两者都使用production:true。

然后我发布了它们以从发布管道中使用。在 QA 阶段，我将 QA 构建部署到测试服务器。

一旦测试通过并签署晋升为 PROD，我就可以简单地使用 Azure DevOps 批准工作流。当它升级到 PROD 阶段时，我使用 PROD 构建进行部署。

我知道，我没有使用在部署到 PROD 时经过 QA 验证的相同版本。但至少这些构建是在同一个代理上创建的，几乎是同时创建的，所以我想这是一个可以接受的折衷方案。

即使您按照其他答案的建议使用标记器，您仍然会得到一些被篡改的工件 IMO。但话又说回来，这是你必须忍受的事情，因为 Angular 需要烘焙它的配置。所以当涉及到部署时，你总是会在你的环境中以一种或另一种方式推广概念上“不纯”的工件。

Answer 3

您可以将 azure 存储库作为工件添加到发布管道，然后将构建管道任务移动到发布管道中的测试和生产阶段，以分别构建和部署您的应用。检查以下步骤。

1、进入发布管道编辑页面并点击Artifacts部分中的Add，将您的Azure repo作为工件添加到发布管道中

2、点击Artifacts部分的Continuous deployment trigger，开启Continuous deployment trigger并设置分支过滤器。

3、创建阶段Test和阶段Prod。

4，将您的构建管道任务复制到 Prod 阶段。并运行ng build env=prod --prod 来构建您的应用程序。然后将您的应用部署到 prod 环境。

.

5，将您的构建管道任务复制到测试阶段。并运行ng build env=test --prod 来构建您的应用程序。然后将您的应用部署到测试环境。

希望以上有所帮助。