財務と運用の更新とカスタム コード ライフサイクルの管理

この記事では、財務と運用の実装でのアプリケーション ライフサイクルのユース ケースについて説明します。 次のシナリオに焦点を当てています。

• ソースコードの開発分岐の管理
• Microsoft サービス更新プログラムの次のバージョンの適用
• カスタム コードの新しいバージョンの適用

この記事は、Microsoft Dynamics 365 Finance、Dynamics 365 Supply Chain Management、Dynamics 365 Human Resources、Dynamics 365 Commerce、および Dynamics 365 Project Operations に適用されます。

主な目的は、次のタスクを完了する方法を示すことです。

• 独自のカスタマイズのライフサイクルに関係なく、段階的に財務と運用アプリ (Dynamics 365 Commerce を含む) の Microsoft サービス更新 (または品質更新プログラム) を最新の状態に保ち管理します。 この方法により、更新プロセスが簡略化され、オールインワン アップグレード プロジェクトに関連付けられているコストと回帰のリスクを軽減できます。
• カスタム コードのバージョン管理にソース コード分岐を利用します。 バージョン管理を使用することにより、新しい特徴や機能から重要な変更や修正プログラムのロールアウトを切り離すことができます。

この記事では、Azure DevOps と Microsoft Dynamics Lifecycle Services (LCS) のさまざまなツールの使用方法については説明していません。 代わりに、プロセスとベスト プラクティスに焦点を当てています。 Microsoft サービス更新プログラムの次のバージョンの適用 セクションと カスタム コードの新しいバージョンの適用 セクションには、フェーズの概要とプロセスの手順の両方が含まれています。

この記事は次のセクションを含みます:

• 環境

  • 現在のリリースを実行する環境
  • カスタム コードの次のバージョンを実行する環境

• ソース コード分岐の管理

• Microsoft サービス更新プログラムの次のバージョンを適用する

  • Microsoft アップデートの後方互換性

    • ランタイムの互換性
    • デザイン時コンパティビリティ

  • フェーズ 1: 財務と運用の実装を更新する

    • トラック 1: ランタイム環境を更新する

      • テスト 1 を更新する
      • UAT を更新する
      • プロドを更新

    • トラック 2: 開発環境を更新する

    • エラー状況

      • ケース 1
      • ケース 2
      • ケース 3

  • フェーズ 2: CSU をバージョン 10.0.11 に更新する

    • フェーズ 2 の前提条件

    • トラック 1: CSU ランタイム環境を更新する

      • テスト 1 を更新する
      • UAT を更新する
      • プロダクトをアップデートする

    • トラック 2: 開発環境を更新する

  • フェーズ 3: POS をバージョン 10.0.11 に更新する

    • フェーズ 3 の前提条件

    • Commerce 開発環境を更新する

    • オプション1: ランタイムの変更のみを含むストア コンポーネントを更新する

    • オプション2: ランタイムとカスタムの変更を含むストア コンポーネントを更新する

    • プロセスを更新する

      • テスト 1 を更新する
      • UAT を更新する
      • 製品を更新する

• カスタム コードの新しいバージョンを適用する

  • コードの修正プログラムを作成する
  • カスタム コードをリリース N からリリース N+1 に更新する

• ストア コンポーネントをアップロード、更新、および配置する

環境

このセクションでは、この記事のアプリケーション ライフサイクル管理 (ALM) シナリオが依存する財務と運用の環境のコレクションについて説明します。 この構成は、カスタム コード (拡張機能) に依存する実装がある組織では一般的です。 このカスタム コードには、独立系ソフトウェア ベンダー (ISV) が提供するカスタマイズが含まれています。

現在のリリースを実行する環境

次の環境では、現在のリリースが実行されます。

• 開発 1 – 運用環境と同じバージョンの財務と運用アプリを実行する開発環境。 開発 1 環境では、カスタム コードのバージョン管理に Azure DevOps を使用します。 これは、カスタム コードの現在のリリース分岐に接続されています。 詳細については、ソース コード分岐の管理 セクションを参照してください。

  • クラウドとオンプレミスの両方の開発環境で、多くのオプションを使用できます。 詳細については、トピック 開発環境の配置とアクセス を参照してください。
  • ビルドの自動化には、新しい Azure DevOps Hosted Agents 機能を使用します。 詳細については、Microsoft ホステッド エージェントと Azure Pipelines を使用するビルドの自動化 を参照してください。

• テスト 1 – 機能テストと構成テストに使用する Tier-1 テスト環境。 テスト 1 環境は、運用環境と同じバージョンの財務と運用アプリを実行します。 また、カスタム コード拡張機能の最新のリリースバージョンも実行します。

• UAT – ユーザー受け入れテストに使用する実稼働前環境。 UAT 環境は、レベル 2 (標準承認テスト) またはそれ以上の環境です。 運用環境と同じバージョンの財務と運用アプリを実行します。 また、カスタム コード拡張機能の最新のリリースバージョンも実行します。 通常、この環境は運用データベースのコピーに接続します。

• 生産 – 運用データベースで実行される実際の運用環境。

カスタム コードの次のバージョンを実行する環境

次の環境では、カスタム コードの次のバージョンを実行します。

• 開発 2 – カスタム コード拡張機能の次のバージョンの開発に使用する開発環境。 カスタム コードのバージョン 管理に Azure DevOps を使用します。 これは、カスタム コードの現在の開発分岐 (メイン ブランチ) に接続されています。 詳細については、ソース コード分岐の管理 セクションを参照してください。
• テスト 2 – カスタム コード拡張機能の次のバージョンのテストに使用する機能テスト環境。

ソース コード分岐の管理

カスタム コードのブランチを管理する場合は、ベスト プラクティスに従う必要があります。 これらのプラクティスに従うことで、コストを最小限に抑え、リリースと更新プログラムの品質を確保できます。

メイン分岐 (開発分岐) には、コードの次期リリースの最新の機能バージョンが含まれています。

新しい機能に取り組む場合は、 メイン ブランチから新しい機能ブランチを作成します。 次に、機能の作業を完了したら、機能ブランチを メイン ブランチに統合します。

リリース分岐には、公式リリースのコード ベースが含まれています。 前の例では、リリース分岐が 1 つしかない、リリース/2020-April であることを前提としています。 2020-April はビルドではありません。 ソース コード分岐です。 おそらくリリース用の修正プログラムを作成するため、変更を加え、このリリース ブランチからビルドを生成します。

• 新しい機能の開発するためにリリース分岐を使用しないでください。 実際の環境で必要な重要な修正や変更についてのみ使用してください。
• リリース ブランチで変更を加えた後、ブランチを メイン ブランチに統合し直します。 この方法を使用すると、次のリリースにも修正プログラムが含まれていることを確認できます。
• 前に説明した環境例の中で、Dev 1 環境は リリース/2020-April ブランチに接続します。

カスタム コードの新しいバージョンをリリースする準備ができたら、 メイン ブランチから新しいリリース ブランチを作成します。 この例では、 main から新しいリリース ブランチを作成し、 2020 年 7 月に名前を付けます。

コードの特定の分岐に基づく特定の作業項目で作業しているときに、個々の開発者が作業するプライベート分岐がある場合があります。 作業が完了したら、プライベート ブランチを親ブランチにマージし直します。 詳細については、Team Foundation バージョン管理 (TFVC) の分岐戦略と効果的な戦略の選択方法について を参照してください。

Microsoft サービス更新プログラムの次のバージョンを適用する

段階的なアプローチを使用すると、サービスの更新の効率を最大限に高めることができます。 各フェーズは、実装の 1 つのコンポーネントを更新します。

1. フェーズ 1 – 財務と運用の環境を更新します。

   現在のバージョンのコマース スケール ユニット (CSU) と POS (POS) は、新しい財務および運用の更新プログラムで正しく動作します。 たとえば、CSU のバージョン 10.0.7 は、財務と運用アプリのバージョン 10.0.11 と互換性があります。

2. フェーズ 2 – CSU を更新します。

3. フェーズ 3 – POS を更新します。

Microsoft の更新プログラムを実行するときに、カスタム コードを次のバージョンに更新する必要はありません。 カスタム コードの更新プログラムとバンドルせずに Microsoft 更新プログラムを取得することにより、更新プロセスを簡略化できます。 また、オールインワン アップグレード プロジェクトに関連付けられている回帰の費用とリスクを軽減することにもなります。

Microsoft 更新プログラムの下位互換性

この記事の次のセクションのコンテキストを使用できるように、 サービス更新プログラムの下位互換性によって Microsoft が何を意味するのかを理解しておくことが重要です。 サービスと品質に関する更新は、ランタイムの下位互換性を備えています。 ただし、デザイン時（コンパイル時）において、必ずしも下位互換性があるとは限りません。

ランタイムの互換性

すべての Microsoft 更新プログラムは、ランタイムの下位互換性を保つことを意図しています。 この互換性はバイナリ互換性と機能互換性の両方を対象にしています。 ランタイムの互換性とは、Microsoft サービスの更新プログラムがそれらの環境に展開された後も、運用環境とサンドボックス環境に存在するカスタマイズが引き続き機能することを意味します。 それらの更新プログラムは、サービス更新と品質更新を含みます。 ランタイムの互換性は、Microsoft 更新プログラムが以前のプラットフォームでコンパイルされたカスタマイズと下位互換性があることも意味します。

バイナリ互換性は、後方向のみです。 以前のアプリケーション バージョンとプラットフォーム バージョンでカスタマイズをコンパイルし、新しいバージョンを実行している環境にデプロイできます。 ただし、コンパイルしたバージョンより前のバージョンを実行している環境にコードをデプロイすることはできません。

デザイン時の互換性

デザイン時 (コンパイル時) の下位互換性とは、開発者が開発環境に更新を適用し、変更を加えることなくコードが正常にコンパイルできることを意味します。

Microsoft は、デザイン時の互換性を目指しています。 ただし、一部の更新には、デザイン時には互換性がないが、バイナリ互換性のある変更が含まれている場合があります。 そのため、更新プログラムが適用された後、コードをコンパイルするときに新しいエラーまたは警告が発生する可能性があります。 これらの変更の例を次に示します。

• Microsoft は列挙型を拡張可能にします。
• Microsoft は API を廃止または内部としてマークします。
• Microsoft は安全でないコーディング方法を回避するために新しいコンパイラ エラーを導入します。

これらすべての変更はソリューションでの作業が必要な場合があります。 バイナリ互換であるデザイン時の破壊的変更は、12 か月の廃止予定の通知を必要としません。 これらの重大な変更は、サービスの更新ごとに文書化されています。 詳細については、プラットフォーム更新プログラムの新機能と変更された機能 を参照してください。

フェーズ 1: 財務と運用の実装を更新する

このセクションでは、財務と運用の実装を最新のサービス更新プログラムに更新するために使用するプロセスについて要約します。 バージョン 10.0.7 からバージョン 10.0.11 への更新が例として使用されます。

このフェーズは次の 2 つのトラックに分かれています。 これらのトラックは並列で発生する可能性があります。

• トラック 1 – ランタイム環境を更新します。
• トラック 2 – 開発環境を更新します。

トラック 1 を完了すると、「 エラー 状況」セクションに記載されているエラー状況のいずれかが発生しない限り、バージョン 10.0.11 が有効になります。

トラック 1: ランタイム環境を更新する

トラック 1 を完了すると、運用環境はバージョン 10.0.11 で稼働しているため、基本的に財務と運用の更新をバージョン 10.0.11 に完了します。 このトラックの一部としてカスタム コードを再コンパイルする必要はありません。

更新テスト 1

Test 1 環境は、カスタム拡張機能の最新リリース バージョンと共にバージョン 10.0.7 を実行します。 テスト 1 の更新はこのフローの前提条件ではありませんが、機能検証と予測可能性の別のレベルを追加するため、それをお勧めします。 UAT 環境を更新する前に、この更新を完了してください。 テスト 1 を更新して検証する時間が早いほど、"実際の" 更新 (つまり、UAT 環境と Prod 環境の更新) が予測しやすくなります。

1. 財務と運用アプリのバージョン 10.0.11 をテスト 1 に適用します。
2. 機能シナリオを承認します。 Regression Suite Automation Tool を使用すると、テスト環境および UAT 環境でのユーザー受け入れテストを自動化できます。
3. 回帰が発生した場合は、「エラー状況」セクション を 参照してください。

UAT の更新

UAT 環境では、カスタム拡張機能のリリースバージョンと共にバージョン 10.0.7 が実行されます。 UAT 環境は Prod 環境と同じです。

1. 財務と運用アプリのバージョン 10.0.11 を UAT に適用します。

   UAT 環境を構成して、Microsoft によって自動的に更新されるようにすることもできます。 ただし、更新が使用可能になり次第、いつでもプルできます。

2. ユーザー受け入れテストを完了し、サイン オフします。

3. 回帰が発生した場合は、「エラー状況」セクション を 参照してください。

製品の更新

1. 財務と運用アプリのバージョン 10.0.11 を Prod に適用します。

   Prod 環境を構成して、Microsoft によって自動的に更新されるようにすることもできます。 更新が利用可能になったら、いつでも取得できます。

2. ログアウトします。

トラック 2: 開発環境を更新する

トラック 2 の目的は、開発 1 環境をバージョン 10.0.11 に更新することです。 開発 1 は、カスタム コードの現在のリリース ブランチに接続されているメイン開発環境です。 バージョン 10.0.7 の金融および運用アプリを実行します。 トラック 2 を完了することで、開発 1 が最新リリースと共にバージョン 10.0.11 を実行し、コードに必要な将来の修正プログラムの準備が整います。

1. 財務と運用アプリのバージョン 10.0.11 を開発 1 に適用します。

2. カスタム コードをコンパイルし、テストを実行します。

3. カスタム コードに必要な変更を加えます。

4. リリース ブランチへのコード変更を確認します。

5. 複数の開発環境がある場合は、環境ごとに次の手順を実行します。

   1. 財務と運用アプリのバージョン 10.0.11 を開発環境に適用します。
   2. ターゲット コード ブランチから、最新のカスタム コードを同期してコンパイルします。

エラー状況

ケース 1

トラック 1 では、Microsoft 品質更新プログラムが必要なバグが見つかります。 Microsoft が更新プログラムを適切なタイミングでリリースする場合、元のサービス更新プログラムの代わりに新しい Microsoft 更新プログラムを使用して、トラック 1 を完了します。

ケース 2

トラック 1 では、Microsoft サービスの更新が必要なバグが見つかります。 ただし、Microsoft は更新プログラムをタイムリーにリリースできません。

この問題の回避策として、Microsoft はカスタム コードの変更を提案します。

1. 開発 1 (リリース分岐内) のコードを変更し、更新をテストします。
2. リリース ブランチへのコード変更を確認します。
3. リリース ブランチから新しい配置可能パッケージを作成します。
4. 新しい配置可能なパッケージをテスト 1 および/または UAT に適用します。

ケース 3

トラック 1 では、カスタム コードを変更する必要があるバグが見つかります。 このバグは、コードまたは ISV コードのいずれかにある可能性があります。

1. 開発 1 (リリース分岐内) のコードを変更し、更新をテストします。
2. リリース ブランチへのコード変更を確認します。
3. リリース ブランチから新しい配置可能パッケージを作成します。
4. 新しい配置可能なパッケージをテスト 1 および/または UAT に適用します。

フェーズ 2: CSU をバージョン 10.0.11 に更新する

このセクションでは、Commerce Scale Unit を最新のサービス更新プログラムに更新するために使用するプロセスについて要約します。 リリース 10.0.7 (Commerce バージョン 9.17) からリリース 10.0.11 (Commerce バージョン 9.21) への更新が例として使用されます。

フェーズ 2 の前提条件

CU を更新する前に、コマース本社環境 (財務および運用アプリ) を同じリリース以降のリリースに更新します。 この例では、リリース 10.0.11 を使用します。

このフェーズは次の 2 つのトラックに分かれています。 これらのトラックは並列で発生する可能性があります。

• トラック 1 – CSU ランタイム環境を更新する。
• トラック 2 – 開発環境を更新します。

トラック 1 を完了すると、フェーズ 1 で説明した エラー状況 のいずれかが発生しない限り、リリース 10.0.11 (コマース バージョン 9.21) に移行します。

トラック 1: CSU ランタイム環境を更新する

トラック 1 を完了すると、CSU のバージョン 10.0.11 への更新が完了します。 運用環境はバージョン 10.0.11 で稼働しています。 このトラックの一部としてカスタム コードを再コンパイルする必要はありません。

更新テスト 1

Commerce のサービスとしてのソフトウェア (SaaS) コンポーネントは、現在、階層 1 環境 (開発環境/テスト環境) ではサポートされていません。 Retail Server のコピーは、各階層 1 環境でローカルに実行され、以前のシステムを通じて Retail Server 用の Microsoft コードとリテールカスタマイズの両方を展開します。 アプリケーション バイナリ パッケージとリテール展開可能パッケージは、サービスとしてのインフラストラクチャ (IaaS) インスタンスに適用します。

UAT の更新

UAT 環境では、リリース 10.0.7 に対応する CSU と、運用環境が実行されているのと同じバージョンのリテール拡張機能が実行されます。

1. Commerce Scale Unit を更新します。 対象バージョンとして、9.21 (10.0.11) を選択します。 詳細については、「 フェーズ 2: CSU をバージョン 10.0.11 に更新する」を参照してください。
2. ユーザー受け入れテストを完了し、サイン オフします。
3. 回帰が発生した場合は、「エラー状況」セクション を 参照してください。

製品を更新する

1. Commerce Scale Unit を更新します。 対象バージョンとして、9.21 (10.0.11) を選択します。 詳細については、「 フェーズ 2: CSU をバージョン 10.0.11 に更新する」を参照してください。
2. サイン オフします。

トラック 2: 開発環境を更新する

1. Retail ソフトウェア開発キット (SDK) の最新バージョンを入手してください。

   1. リリース 10.0.11 の財務と運用サービス更新プログラムを開発 1 に適用します。
   2. >%ServiceDrive%から Retail SDK の更新バージョンを取得。

2. メイン (開発) 分岐で、新しいバージョンの Retail SDK から Retail アーティファクトを更新します。

3. コンパイルします。 新しいバージョンは下位互換性があり、コードを変更する必要はありません。

4. Retail SDK の更新を含む変更をコミットします。

5. カスタム コードに必要な変更を加えます。

6. ターゲット分岐にコードの変更をコミットします。

7. オプション: 複数の開発環境がある場合は、手順 4 の最新の変更をマージし、最新のカスタムコードをコンパイルします。

フェーズ3: POS をバージョン 10.0.11 に更新する

このセクションでは、Modern POS (新しいバージョンの Store Commerce) や Hardware Station などの店舗のコンポーネントを最新のサービス更新プログラムに更新するために使用するプロセスを要約します。 このセクションでは、リリース 10.0.7 (コマース バージョン 9.17) からリリース 10.0.11 (コマース バージョン 9.21) までの更新プログラムを例として使用します。

(財務と運用アプリ内の) Commerce headquarters および CSU の更新とは異なり、店舗のコンポーネントの更新は同じパッケージで提供されます。 Commerce headquarters と CSU を更新すると、次のオプションがあります:

• オプション0 (操作は必要ありません) – バージョンがサポートされており、ポリシーに準拠している場合は、店舗のコンポーネントを以前のリリースままにします。
• オプション 1 – CSU と同じリリースに一致するように、店舗のコンポーネント ランタイム (Microsoft コード) を更新します。
• オプション 2 – 店舗コンポーネントのランタイム (Microsoftコード) とカスタマイズを一緒に更新します。

このセクションの残りの部分では、ストア コンポーネント (オプション 1 またはオプション 2) を更新する必要がある、または更新する必要があることを前提としています。

このフェーズを完了すると、フェーズ 1 で説明されている エラー状況 のいずれかが発生しない限り、ストア コンポーネントのリリース 10.0.11 (コマース バージョン 9.21) が有効になります。

フェーズ 3 の前提条件

フェーズ 3 には次の前提条件があります。

• CSU を更新する前に、コマース本社コンポーネント (財務および運用アプリ内) を同じリリース以降のリリースに更新しました。 この例では、バージョンは 10.0.11 です。
• CSU をストア コンポーネントと同じリリースまたはそれ以降のリリースに更新しました。 この例では、リリースは 10.0.11 です。

Commerce 開発環境を更新する

トラック 2: 開発環境の更新 セクションの手順に従ってください。

オプション 1: ランタイムの変更のみを含む店舗のコンポーネントを更新する

このオプションは、店舗のコンポーネントを含む新しい配置可能小売パッケージを生成します。 Microsoft コードからの変更のみが含まれます。

1. 運用環境で現在使用されているコードを含むリリース ブランチを、ターゲット リリースに一致する Retail SDK に更新します。 この例では、バージョンは 10.0.11 (9.21) です。 トラック 2: 開発環境の更新 セクションの手順に従ってください。
2. 小売展開用パッケージの新しいビルドを生成します。 このビルドには、運用環境に現在あるものと同じカスタマイズのセットに加えて、Microsoft コードのバージョン 10.0.11 (9.21) が含まれています。

オプション 2: ランタイムとカスタムの変更を含む店舗のコンポーネントを更新する

このオプションは、店舗のコンポーネントを含む新しい配置可能小売パッケージを生成します。 Microsoft コードとカスタマイズ両方からの変更が含まれます。

1. 運用環境で現在使用されているコードを含むリリース ブランチを、ターゲット リリースに一致する Retail SDK に更新します。 この例では、バージョンは 10.0.11 (9.21) です。 トラック 2: 開発環境の更新 セクションの手順に従ってください。
2. 変更をコミットします。
3. 店舗のコンポーネントのカスタム コードを更新するか、ISV 更新されたコンポーネントへの参照を更新します。
4. 小売用デプロイ可能パッケージの新しいビルドを生成します。 このビルドには、更新されたカスタム コードに加えて、Microsoft コードのバージョン 10.0.11 (9.21) が含まれます。

更新プロセス

更新テスト 1

Commerce の SaaS コンポーネントは現在、開発またはテストのワンボックス環境ではサポートされていません。 Retail Server のコピーは、各開発環境またはテスト ワンボックス環境でローカルに実行されます。Retail Server と Retail カスタマイズ用の Microsoft コードの両方の展開は、前のシステムを通じて行われます。このシステムでは、アプリケーション バイナリ パッケージとリテール展開可能パッケージが IaaS インスタンスに対して適用されます。

テスト 1 環境では、コマース本社のバージョン 10.0.11 と、前のフェーズのローカル バージョンの CSU が実行されます。 このフローでは、テスト 1 の更新は前提条件ではありません。 この環境には CSU がないため、この手順は主に検証用です。

1. 店舗のコンポーネントをアップロード、更新、および配置します。 詳細については、店舗のコンポーネントのアップロード、更新、および配置 を参照してください。
2. 機能シナリオを承認します。
3. 回帰が発生した場合は、「エラー状況」セクション を 参照してください。

UAT の更新

UAT 環境を指すクライアントは、リリース 10.0.7 (運用環境で現在実行されているのと同じバージョン) のアプリケーション (Modern POS など) を実行します。

1. 店舗のコンポーネントをアップロード、更新、および配置します。 詳細については、店舗のコンポーネントのアップロード、更新、および配置 を参照してください。
2. 機能シナリオを承認します。
3. 回帰が発生した場合は、「エラー状況」セクション を 参照してください。

製品の更新

1. 店舗のコンポーネントをアップロード、更新、および配置します。
2. ログアウトします。

カスタム コードの新しいバージョンを適用する

このセクションでは、カスタム拡張機能の新しいビルドで UAT と運用環境を更新する必要がある 2 つのユース ケースに推奨されるフローについて説明します。

コードの修正プログラムを作成する

UAT または運用環境で重大なバグが見つかると、リリース ブランチ ( メイン または開発ブランチではなく) でバグを修正します。 次に、標準プロセスを使用して、UAT と運用環境に展開可能なパッケージを適用します。

1. 開発 1 では、リリース分岐でコードの修正を行います。 必要な修正が ISV コードにある場合は、ソリューションの次のバージョンではなく、現在のリリースの新しいビルドを ISV に送信するよう依頼します。
2. コンパイルしてテストします。
3. リリース ブランチから新しい配置可能パッケージを作成します。
4. テスト 1 に配置し、サインオフが必要な場合はサインオフします。
5. 標準プロセスを使用して、最初に UAT にカスタム コードをデプロイし、次に運用環境にデプロイします。
6. コード修正をメイン コード分岐と統合します。

カスタム コードをリリース N からリリース N+1 に更新する

カスタム コードの次のバージョンをリリースする準備ができたら、次のプロセスを使用して新しいリリースを作成および配置します。

1. 開発 2 環境、またはメイン分岐に接続されている別の環境では、メイン分岐で開発を完了します。
2. テスト 2 に配置してテストします。
3. 新しいバージョンでサインオフするまで、手順 1 から 2 を繰り返します。
4. 新しいリリース分岐を作成します。
5. 新しい リリース ブランチから配置可能パッケージを作成します。
6. 標準プロセスを使用して、最初に UAT にカスタム コードをデプロイし、次に運用環境にデプロイします。
7. 古いリリースブランチを削除します。

店舗のコンポーネントをアップロード、更新、および配置する

1. 配置可能小売パッケージを LCS にアップロードします。

2. Application Object Server (AOS) を最新のクライアントで更新します。

3. 展開可能な小売パッケージをアセットライブラリにアップロードします。

   • 以前の配置 (バージョン 10.0.11 より前): ソフトウェア配置可能パッケージ
   • 新しい展開 (バージョン10.0.11 以降): リテールセルフサービスインストーラー

4. 店舗のコンポーネント用の新しいセルフサービス インストーラーで Commerce headquarters を更新します。

   • 以前の配置 (バージョン 10.0.11 より前): LCS を介して配置可能小売パッケージを Commerce headquarters に配置します。
   • 新しい配置 (バージョン10.0.11 以降): Commerce headquarters の Commerce パラメーター フォームのチャネル配置タブでパッケージの更新の確認を選択します。 この更新プログラムは、LCS アセット ライブラリの [リテール セルフサービス パッケージ ] タブで使用できるパッケージを取り込みます。

5. クライアント バージョンをデバイスに割り当てます。

6. 目的のクライアント タイプとデバイスのインストーラーをダウンロードします。

7. 対象のデバイスにインストールします。

8. テストして検証します。