Azure Devops Angular环境变量 [英] Azure Devops Angular Environment Variables

查看:138
本文介绍了Azure Devops Angular环境变量的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这时,当对Master分支进行提交时,构建管道将基于"ng build --prod"生成构件,因此该构件使用项目的生产配置.之后,工件将被部署到测试和生产环境.

At this point, when a commit happens to the Master branch, a build pipeline will generate an artifact based on "ng build --prod", so this artifact uses the production configuration for the project. After that, the artifact will be deployed to the test and production environments.

对于测试环境,我希望代码使用"environment.dev.ts",对于生产环境使用"environment.prod.ts".我该如何实现?

For the test environment, I want the code to use "environment.dev.ts" and for production "environment.prod.ts". How can I achieve that?

推荐答案

有很多方法.我正在使用令牌" 我的生产环境看起来像这样

There are many ways. I am doing it using "Tokens" My production environment looks like this

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

因此,当我构建版本时,因为没有变量,而是令牌,所以我的版本不可用.

So when I build my version is not usable because instead of variables i have tokens.

然后,当我发布时,我确实有替换令牌的步骤.需要在部署脚本之前运行(只需根据需要进行修改)

Then when I do release I do have step to replace tokens. this need to run before you deploy scripts (just modify to your needs)

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

此任务将找到我的发布变量,例如FLYMARK_MAIN_DOMAIN,STRIPE_KEY,并替换到我的js文件中.

This task will find my release variables like FLYMARK_MAIN_DOMAIN, STRIPE_KEY and replace in my js files.

主要优点是您只需构建一次即可部署到任何需要替换令牌的地方

Main benefit is that you build once and can deploy to anywhere just need to replace tokens

PS.假设您有开发人员,暂存人员和生产人员.现在要开发,您需要在构建之后进行部署,该构建是由新推送至master触发的,直到您的版本在批准后发布(azure管道支持)

PS. Lets say you have dev, staging, prod. Now To dev you deploy after build which is triggered by new push to master, to staging you release when its approved (azure pipeline support that)

因此,现在假设您的开发版本为100,您决定将其推送到暂存阶段,然后团队开始进行测试. 3天后,您的开发团队开始掌握许多新东西,因此在dev上您拥有123版,但在过渡中您仍然拥有100版.在经过阶段测试之后,您将把相同版本推向生产环境,因为您有信心,如果您愿意当您准备部署到生产环境时,请使用单独的环境构建版本,您在master中拥有许多新内容,也许您没有信心将其推向生产环境.同样,每种情况都是不同的,有很多方法可以做到,我喜欢这种方法,因为它适合我的项目.

So now lets say you have in dev version 100, you decided to push it into staging and your team start testing. After 3 days your development team pushed to master lots of new stuff so on dev you have version 123, but in staging you still have version 100. After team tested in staging you will push same version to production because you are confident, if you will use separate builds for environment when you are ready to deploy to production you have lots of new stuff in master and maybe you are not confident to push it to production. Again each case is different and there is many ways to do it, I just like this way of doing because it suits my projects.

这篇关于Azure Devops Angular环境变量的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆