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

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

问题描述

此时,当主分支发生提交时,构建管道将根据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: '}}#'

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

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

附注.假设您有开发、分期和生产.现在要开发,您在构建后部署,这是由新推送到主控触发的,在批准时分阶段发布(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 天后,您的开发团队推动掌握大量新东西,因此在开发中您拥有版本 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天全站免登陆