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

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

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

この記事は、 Microsoft Dynamics 財務、 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 – 機能テストと構成テストに使用されるレベル 1 テスト環境。 テスト 1 環境は、運用環境と同じバージョンの財務と運用アプリを実行します。 また、カスタム コード拡張機能の最新のリリースバージョンも実行します。

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

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

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

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

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

ソース コード分岐の管理

カスタム コード分岐を管理する場合は、ベスト プラクティスに従うことが重要です。 これにより、原価を最小限に抑え、リリースと更新の品質を保証するのに役立ちます。

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

新しい機能で作業する場合は、メイン分岐から新しい機能分岐を作成します。 機能作業が完了したら、機能分岐をメイン分岐に統合します。

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

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

カスタム コードの新しいバージョンをリリースする準備ができたら、メイン分岐に基づく新しいリリース分岐を作成します。 この例では、メインに基づいて 2020-July という名前の新しいリリース分岐を作成します。

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

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

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

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

   現在のバージョンの Commerce Scale Unit (CSU) および Point of Sale (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

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

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

UAT の更新

UAT 環境は、カスタム拡張機能のリリース バージョンと共にバージョン 10.0.7 を実行しています。 (UAT 環境は、製品環境と同じです。)

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

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

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

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

製品の更新

1. 財務と運用アプリのバージョン 10.0.11 を 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 はカスタム コードの変更を提案します。

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 の前提条件

CSU を更新する前に、(財務と運用アプリ内の) Commerce headquarters の環境を同じリリースまたはそれ以降のリリースに更新する必要があります。 この例では、10.0.11 がリリースされています。

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

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

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

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

トラック 1 を完成すると、運用環境はバージョン 10.0.11 で有効になるため、基本的に CSU のバージョン 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%\RetailSDK\Update\<newest directory> から 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 (Commerce バージョン 9.17) からリリース 10.0.11 (Commerce バージョン 9.21) への更新が例として使用されます。

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

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

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

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

フェーズ 3 の前提条件

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

• (財務と運用アプリ内の) Commerce headquarters のコンポーネントは、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 用の Microsoft コードと小売りのカスタマイズの両方の配置は、アプリケーション バイナリ パッケージと配置可能な小売りパッケージが IaaS インスタンスに対して適用される前のシステム介して行われます。

テスト 1 環境では、Commerce 本社のバージョン 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 以降): Retail セルフサービスのインストーラー

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

   • 以前の配置 (バージョン 10.0.11 より前): LCS を介して配置可能小売パッケージを Commerce 本社に配置します。
   • 新しい配置 (バージョン10.0.11 以降): Commerce 本社の Commerce パラメーター フォームのチャネル配置タブでパッケージの更新の確認を選択します。 この更新では、LCS 資産ライブラリのRetail セルフサービス パッケージ タブで使用できるパッケージが導入されます。

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

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

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

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