この時点で、マスターブランチにコミットが発生すると、ビルドパイプラインが「ng build --prod」に基づいてアーティファクトを生成するため、このアーティファクトはプロジェクトの本番環境構成を使用します。その後、アーティファクトはテスト環境と本番環境にデプロイされます。
テスト環境では、コードで「environment.dev.ts」を使用し、本番環境では「environment.prod.ts」を使用します。どうすればそれを達成できますか?
多くの方法があります。私は「トークン」を使用してそれをやっています私の実稼働環境は次のようになります
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: '}}#'
このタスクは、FLYMARK_MAIN_DOMAIN、STRIPE_KEYなどのリリース変数を見つけて、jsファイルで置き換えます。
主な利点は、一度構築すると、トークンを置き換えるだけでどこにでもデプロイできることです。
PS。開発、ステージング、本番があるとします。今度は、新しいマスターへのプッシュによってトリガーされるビルド後に展開し、承認されたときにリリースをステージングするために開発します(Azureパイプラインがサポートします)
さて、あなたが開発バージョン100を持っているとしましょう。それをステージングにプッシュし、チームがテストを開始することにしました。 3日後、開発チームは多くの新しいものをマスターするようにプッシュしましたので、開発ではバージョン123になりますが、ステージングではまだバージョン100です。チームがステージングでテストされた後、同じバージョンを本番環境にプッシュします。本番環境にデプロイする準備ができて、マスターに新しいものがたくさんあり、本番環境にプッシュする自信がない場合は、環境用に個別のビルドを使用します。繰り返しになりますが、それぞれのケースは異なり、それを行う方法はたくさんあります。自分のプロジェクトに適しているため、この方法が好きです。
Azureリポジトリをアーティファクトとしてリリースパイプラインに追加し、ビルドパイプラインタスクをリリースパイプラインのテストステージと製品ステージに移動して、それぞれアプリをビルドおよびデプロイできます。以下の手順を確認してください。
1、リリースパイプライン編集ページに移動し、ArtifactsパーツのAddをクリックします、Azureリポジトリをアーティファクトとしてリリースパイプラインに追加するには
2、ArtifactsパーツのContinuous Deployment Triggerをクリックして、Continuous Deployment Triggerを有効にしますそしてブランチフィルターを設定します。
3、ステージテストとステージ製品を作成します。
4、ビルドパイプラインタスクをProdステージにコピーします。そして
ng build env=prod --prod
を実行してアプリをビルドします。次に、アプリを本番環境にデプロイします。
。
5、ビルドパイプラインタスクをテストステージにコピーします。そして
ng build env=test --prod
を実行してアプリをビルドします。次に、アプリをテスト環境にデプロイします。
上記が役立つことを願っています。