更新戦略

エバーグリーンアプローチ

SCEPman の更新にはエバーグリーン方式を推奨します。これは SCEPman が production チャネルを使用してデプロイされている場合のデフォルトの方法です。SCEPman は ZIP デプロイを使用し、直接 SCEPman GitHubarrow-up-right を指して開発チームがリリースした最新バージョンを読み込みます。

production チャネルは、他の利用可能なチャネルとともに次のガイドに記載されています:

アプリケーションアーティファクトchevron-right

このアプローチでは常に最新の機能とセキュリティ更新を取得できます。

circle-info

次の点に注意してください 更新は App Service が停止して再起動されたときにのみ発生します。これは ZIP デプロイがトリガーされるイベントです。App Service が自動的に停止して再起動するわけではありませんが、特定のイベントで外部から再起動されます。そのイベントの一つが 基盤となるインフラストラクチャのメンテナンスとパッチ適用arrow-up-rightです。 それらは.

定期的に実行され、サービスを最新の状態に保ちます 本番のエンタープライズ環境で、更新プロセスをより細かく制御したい場合は、Microsoft の機能である.

デプロイメント スロット

デプロイメント スロットの構成 本番のエンタープライズ環境で、更新プロセスをより細かく制御したい場合は、Microsoft の機能である SCEPman の更新プロセスを完全に制御したい場合は、Azure App Service 内の

circle-check

以下の手順は、プリーリース管理のための推奨セットアップを示します

circle-info

各デプロイメント スロットは本番の App Service と同じ App Service プラン上で実行され、同じリソースを使用することに注意してください。

プリーリース スロット

プリーリース スロットの考え方は、本番の App Service を独自のストレージ アカウントに格納されたアーティファクトで実行し、新しいデプロイメント スロットを作成して当社の GitHub アーティファクトを指すようにすることです。カスタムアーティファクトの場所を設定する手順は次の記事に記載されています:

アプリケーションアーティファクトchevron-right

これで本番の App Service はカスタムアーティファクトの場所で実行されており、次に新しいデプロイメント スロットの構成に進みます。

circle-info

デプロイメント スロットの要件 ****(PowerShell 経由、SCEPman モジュール):

  • SCEPman 2.2 以上

  • PowerShell SCEPman-Module 1.5.1.0 以上

次の CMDlet コマンドはデプロイメント スロットを作成し、必要なすべての権限を構成します。

デプロイが正常に完了したら、SCEPman App Service -> でデプロイメント スロットを確認できます。 デプロイメント スロット

次に、デプロイメント スロットが GitHub 上の SCEPman Production チャネルを指していることを確認します:

に移動し デプロイメント スロット -> 環境変数 を探して設定を確認し、 WEBSITE_RUN_FROM_PACKAGE を探します。そして production チャネルのアーティファクト をその値に貼り付けます。

プライマリの App Service に戻り、 デプロイメント スロット yに移動すると、2 つのスロットが表示され、 トラフィック % を使用して定義した量のリクエストを新しい プリーリース スロットにルーティングできます。 このトラフィックルーティングはアプリケーションにとって完全に透過的で App Service により処理されることが重要です。私たちは トラフィック %20に設定することを推奨します。 その後、 Application Insightsで 2 つのスロットを比較できます。私たちが GitHub に更新版をリリースした場合は、単に プリーリース スロットを再起動するだけで、その後 Application Insightsで 2 つの異なるバージョンを比較できます。一週間または任意の期間の後、新しい GitHub アーティファクトをカスタムアーティファクトの場所にアップロードして SCEPman ソリューションを更新できます。

最終更新

役に立ちましたか?