简体   繁体   English

Azure Devops Angular 环境变量

[英]Azure Devops Angular Environment Variables

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.此时,当 Master 分支发生提交时,构建管道将基于“ng build --prod”生成一个工件,因此该工件使用项目的生产配置。 After that, the artifact will be deployed to the test and production environments.之后,工件将被部署到测试和生产环境。

For the test environment, I want the code to use "environment.dev.ts" and for production "environment.prod.ts".对于测试环境,我希望代码使用“environment.dev.ts”和生产“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: '}}#'

This task will find my release variables like FLYMARK_MAIN_DOMAIN, STRIPE_KEY and replace in my js files.此任务将找到我的发布变量,如 FLYMARK_MAIN_DOMAIN、STRIPE_KEY 并在我的 js 文件中替换。

在此处输入图片说明

Main benefit is that you build once and can deploy to anywhere just need to replace tokens主要好处是您构建一次,只需更换令牌即可部署到任何地方

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)现在要开发,您在构建后部署,这是由新推送到主控触发的,在批准时分阶段发布(天蓝色管道支持) 在此处输入图片说明

So now lets say you have in dev version 100, you decided to push it into staging and your team start testing.所以现在假设您在开发版本 100 中,您决定将其推入暂存阶段,并且您的团队开始测试。 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. 3 天后,您的开发团队推动掌握大量新东西,因此在开发中您拥有版本 123,但在登台时您仍然拥有版本 100。在登台中进行团队测试后,您将把相同版本推向生产,因为您有信心,如果您愿意的话当您准备好部署到生产环境时,请为环境使用单独的构建,您在 master 中有很多新东西,也许您没有信心将其推送到生产环境。 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.同样,每个案例都是不同的,有很多方法可以做到,我只是喜欢这种方法,因为它适合我的项目。

My organization does not allow installing third-party extensions on DevOps.我的组织不允许在 DevOps 上安装第三方扩展。 Therefore the top-voted answer was a no go.因此,投票最多的答案是没有 go。 So I took a different approach.所以我采取了不同的方法。 In the build pipelines, I created two build artifacts: one for QA, one for PROD.在构建管道中,我创建了两个构建工件:一个用于 QA,一个用于 PROD。 Different environment files were used in those build steps (Ex: ng build --c qa ).在这些构建步骤中使用了不同的环境文件(例如: ng build --c qa )。 Both were using production:true .两者都在使用production:true

在此处输入图像描述

Then I published both of them to be consumed from the release pipelines.然后我发布了它们以从发布管道中使用。 In the QA stage, I deployed the QA build to test servers.在 QA 阶段,我将 QA 构建部署到测试服务器。

在此处输入图像描述

Once testing has passed and signed off to be promoted to PROD, I could simply use the Azure DevOps approval workflow.一旦测试通过并签署晋升为 PROD,我可以简单地使用 Azure DevOps 批准工作流程。 When it is promoted to PROD stage, I used the PROD build for deployment.当它升级到 PROD 阶段时,我使用 PROD 构建进行部署。

在此处输入图像描述

I know, I'm not using the same build which got QA verified when deploying to PROD.我知道,我没有使用在部署到 PROD 时经过 QA 验证的相同版本。 But at least those builds were created on the same agent, almost at the same time so I guess that is an acceptable compromise.但至少这些构建是在同一个代理上创建的,几乎是同时创建的,所以我想这是一个可以接受的折衷方案。

Even if you use the tokenizer as the other answer suggests, you still end up with somewhat tampered artifact IMO.即使您按照其他答案的建议使用标记器,您仍然会得到一些被篡改的工件 IMO。 But then again that is something you have to live with, given that Angular needs to bake its config in. So when it comes to deployments, you will always be promoting a conceptually 'impure' artifact across your environments, one way or the other.但话又说回来,这是你必须忍受的事情,因为 Angular 需要烘焙它的配置。所以当涉及到部署时,你总是会在你的环境中推广一个概念上“不纯”的工件,无论哪种方式。

You can add your azure repo as the artifacts to your release pipeline and then move your build pipeline tasks to the test and prod stages in release pipeline to build and deploy your app respectively.您可以将 azure 存储库作为工件添加到发布管道,然后将构建管道任务移动到发布管道中的测试和生产阶段,以分别构建和部署您的应用程序。 Check below steps.检查以下步骤。

1, Go the release pipeline edit page and click Add in Artifacts part, TO add your azure repo to the release pipeline as artifacts 1、进入发布管道编辑页面,在Artifacts部分点击Add ,将你的azure repo作为工件添加到发布管道中

在此处输入图片说明

2, Click Continuous deployment trigger in Artifacts part to enable Continuous deployment trigger and set the branch filter. 2,点击文物部分连续部署触发器,以使持续部署触发,并设置路滤波器。

在此处输入图片说明

3, Create stage Test and stage Prod. 3、创建stage Test和stage Prod。

在此处输入图片说明

4, Copy your build pipeline tasks to Prod stage. 4、将您的构建管道任务复制到 Prod 阶段。 And run ng build env=prod --prod to build your app.并运行ng build env=prod --prod来构建您的应用程序。 And then deploy your app to prod environment.然后将您的应用程序部署到生产环境。

. .

5,Copy your build pipeline tasks to Test stage. 5,将您的构建管道任务复制到测试阶段。 And run ng build env=test --prod to build your app.并运行ng build env=test --prod来构建您的应用程序。 And then deploy your app to test environment.然后将您的应用程序部署到测试环境。

Hope above helps.以上希望有所帮助。

I did this in a similar way to @Ε Г И І И О but wanted to add the below.我以与@Ε Г И І И О 类似的方式执行此操作,但想添加以下内容。 I used parameters in my pipeline to easily create the two artifacts:我在管道中使用了参数来轻松创建两个工件:

https://gist.github.com/davewilton/ca800b406659fb7f55ba531ef433fa1e https://gist.github.com/davewilton/ca800b406659fb7f55ba531ef433fa1e

在此处输入图像描述

And then I could use the two results in my prod and staging releases.然后我可以在我的 prod 和 staging 版本中使用这两个结果。

在此处输入图像描述

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM