この記事では、Microsoft Dynamics 365 Commerce 実装プロジェクトのコードと環境を更新するための推奨プラクティスについて説明します。
環境を更新するには、そのデータまたはそのコードを更新します。
データはさまざまな方法で更新できます。 環境にデータを取り込む方法を示す例については、「 財務アプリと運用アプリとパートナー サービスの統合」を参照してください。
環境を更新する場合は、データベース全体を移動することを検討してください。 このアプローチにより、データをある環境から別の環境に素早く簡単に複製できます。
他の更新プログラムは、コードの更新プログラムです。 Microsoft Dynamics Lifecycle Services (LCS) の環境ページでは、適用した更新プログラムと適用する必要がある更新プログラムが追跡されます。 次の図は、79 の未処理 X++ ファイル、14 の未処理のバイナリ更新プログラムおよび 9 の未処理プラットフォーム バイナリ 更新プロセスを持つ環境を示しています。
プラットフォーム コードは、低いレベルであり、Microsoft Dynamics 365 Commerce 機能はプラットフォームに実装されません。 したがって、スタンドアロン プラットフォームのバイナリ アップデート プログラムでは、コマース固有のコードを再テストすることは不要です。 プラットフォームが実装する機能の例としては、Data Import/Export Framework (DIXF) とバッチ フレームワークがあります。
バイナリ更新プログラムまた修正プログラムには、ダイナミック リンク ライブラリ (DLL)、スクリプト、およびチャネル SQL スキーマの変更が含まれます。 すべてのチャネル側修正プログラムは、バイナリ更新プログラムまたは修正プログラムとしてまとめてリリースされます。 バイナリ更新プログラムは DLL であるため、累積されます。 たとえば、金曜日にバイナリの更新プログラムをダウンロードする場合は、すべてのバイナリ修正プログラムを月曜日木曜日まで自動的に受信します。
コードのマージを正しく行うと、実行するバイナリ修正プログラムのバージョンが、リテール ソフトウェア開発キット (SDK) の Microsoft-version.txt ファイルのバージョンと一致します。 通常、バイナリ更新プログラムは最新のプラットフォームにもリンクされています。 したがって、バイナリ アップデートを取得する場合は、プラットフォームを最新の状態に保つ必要があります。 プラットフォームの更新はプラットフォームの安定性を向上させ、ビルド環境やテスト作業にある程度影響を及ぼします。
アプリケーションの更新プログラムまたは修正プログラムは、X++ ソース コードで配信されます。 そのため、これらはチャネルではなく、Microsoft Dynamics 365 側用です。 これらはコマース関連か、コマース関連ではありません。
一部の更新プログラムは、アプリケーションの更新プログラムとバイナリの更新プログラムの両方が必要です。 修正プログラムの推奨事項については、次のセクションを参照してください。
パートナー パッケージはアプリケーション パッケージに似ていますが、他の開発者が作成します。 独立系ソフトウェア ベンダー (ISV) パッケージの使用方法の詳細については、ランタイム パッケージの管理を参照してください。
データベースを復元してデータを更新する
一般的で便利な操作は、データベース全体をある環境から別の環境に移動することです。 たとえば、より多くの機能を開発する準備をしているときに、運用環境のデータベースを開発環境に移動できます。 また、運用プロセスの一部として、ゴールデン セットアップ データベースを運用データベースに移動することもできます。
詳細については、Azure SQL から SQL Server へのデータベースのコピー を参照してください。 移行元と移行先の環境に同じバイナリ バージョンがない場合は、ビルドとデータベースの同期 (開発環境の場合)、またはデプロイ (サンドボックスまたは運用環境の場合) も行う必要があります。
データベースを別の環境から復元するたびに、データベース内の特定のリンクを解除できます。 環境再プロビジョニング ツールは、環境の種類に関係なく、既定のデータベース グループに対してこれらの壊れたリンクをすべて修正します。 データベースが別の環境から来ている場合は、環境再プロビジョニング ツールを実行します。
多くの場合、データベースを更新した後、コマース スケジューラをリセットする必要があります。
データベースを復元した後、次の手順に従います。
ビルドとデータベースの同期を行うか、配置可能パッケージを配置します。
メモ
データを含むテーブルの拡張機能をご使用の場合は、環境内の拡張機能のためのメタデータが必要です。 それ以外の場合は、列と表が削除される可能性があるため、データを失うことがあります。
バッチ サービスが実行中であることを確認してください。
環境再プロビジョニング ツールを実行します。 (LCS のグローバル共有資産ライブラリで最新バージョンを見つけて、Maintain 関数を使用して展開します。)
ツールが成功し、コマース チャネル プロファイルが正しい URL で最新であり、既定のデータ グループのデータ同期ジョブが成功したことを確認します。
コマースでは、コマース スケジューラの初期化ジョブ (古いデータを削除するために選択) を実行します。 この手順では、すべての Commerce Data Exchange (CDX) コンフィギュレーションの変更がリソース ファイルを使用して自動化されていることを前提としています。 CDX のコンフィギュレーションの変更が自動化されていない場合、およびテーブル、サブジョブ、ジョブが手動でコマース チャネルのスキーマで作成された場合、既存のコンフィギュレーションを削除するオプションを選択しないでください。 CDX 構成の変更を自動化します。
頻繁に更新を受け取る
プロジェクトが稼働終了または最終ユーザー受け入れテスト (UAT) から数週間以上離れている場合は、すべての修正プログラム (バイナリ、X++、プラットフォーム) を定期的に実行します。 具体的には、1 か月に 1 回、すべての修正プログラムを受け取ります。 このタスクを実行する頻度が高いほど、修正プログラムのコード チャーンが小さくなるため、発生する必要がある問題が少なくなります。 このタスクを頻繁に実行する場合は、8 時間未満かかります。
エラーを引き起こす可能性が高く、おそらく時間の無駄になるため、修正プログラムを選んで適用することは避けてください。 未処理の修正プログラムが 500 個または 1,000 個ある場合は、稼働準備ができているかどうかを検討してください。 LCS の更新タイルの数が少ない (アプリケーション修正が 100 個未満、バイナリ修正が 10 個未満) 場合、製品の品質が高くなります。
新しい修正プログラムを実行した後は前回の UAT の結果はあまり意味のないものになります。 そのため、再テストが重要です。 変更されたファイルの数は、どれくらいの広さのテストが必要か決定します。 特に実装フェーズ中に修正プログラムを頻繁に実行する場合は、新しいファイルの数が多くなくなり、再テスト作業を管理できます。
別の方法は、すべての修正プログラムを頻繁に実行し、UAT の一部のみを実行することです。 次に、新しい修正プログラムを実行するときに、UAT の別の部分を実行します。 UAT の様々な部分を循環的に実行します。 稼働前に、UAT の全実行を行う必要があります。
ブランチおよび環境を介するコード変更の流れ
プロジェクト、チーム、またはその他の制約が分岐戦略を決定するのと同様に、プロジェクトには、ブランチを通じて変更がどのように反映されるかに関する柔軟性があります。 次の図は、プロセスの例を表示しています。 ただし、この例は、いくつかのプロジェクトには単純過ぎ、また他のプロジェクトには複雑過ぎるかもしれません。 重要な点は、プロジェクトが計画を用意する必要があります。 チームの担当者ごとに異なる責任 (開発、デプロイ、コードのマージ、サインアウトなど) があり、ロールの所有権を明確に定義する必要があります。
手順 1–3: 更新プログラムを取得および適用
前の図と同じ方法でブランチを設定した場合は、Dev ブランチでこの作業を行います。
手順 3.1–3.2: 開発環境を最新へ保持
開発ブランチ用のビルド環境は必要ありません。 実際、通常は Dev ブランチ用のビルド環境は必要ありません。 バージョンを正しく保つために、デプロイするパッケージを調整するだけで済みます。
バイナリ更新プログラムとプラットフォーム更新プログラムをダウンロードした後は、LCS パッケージの展開を通じて展開できます。
X ++ コードの場合、開発者はメタデータ フォルダを同期し、フル ビルドおよびデータベース同期を行うだけです。
他のチーム メンバーが主要な新しい変更 (新しいファイル、構成の変更、新しい Retail SDK など) をチェックインした場合、新しいファイルの同期とビルドでは不十分です。 開発者マシンにインストールされているいくつかの Web アプリケーションは、コンパイルによって更新されません。 これらの Web アプリケーションをデプロイする必要があります。 LCS パッケージの展開を使用して、MSBuild コマンド プロンプトで生成できるコマース パッケージをデプロイします。 コードの変更が小さい場合、増分変更がインストールの場所にドロップされた場合、開発環境の同期を維持するために新しいパッケージのデプロイは必要ありません。
手順 4: Dev ブランチから Main ブランチへの変更を移動
この例では、Dev 分岐と Main 分岐が分離され、「不要な変更を残す」機会を提供しています。このアプローチは必須ではありませんが、それは良い選択です。 Microsoft Visual Studio を使用すると、Dev から Main へコードを簡単に移動できます。 変更の範囲、すべてまたは個々の変更を選択し、それらの変更をマージすることができます。 プロセスを単純に保つために、Dev 分岐で何らかのタイプのコード凍結を行うことができます。 次に、品質に問題がなければ、すべての変更をマージできます。 X++ を Retail SDK と異なる扱いをする理由はありません。 相互に依存しているので、各分岐で隣同士に配置されています。
手順 4.1–4.2: テスト環境の更新
ビルド環境を使用して、Main ブランチのコードから正式に構築されたパッケージを作成します。
ビルドが完了したら、プロセスによってビルドされたパッケージを見つけます。 名前付け規則に従って、それらをダウンロードして名前を変更します。
LCS アセット ライブラリにパッケージをアップロードします。
最後に、テスト環境にパッケージを配置します。
手順 4.3: パッケージを運用環境に展開
必要なすべてのテストに合格したら、同じパッケージを運用環境にデプロイする準備が整います。 階層 2 以降の環境でパッケージを展開して検証したら、LCS アセット ライブラリでリリース候補としてマークする必要があります。 配置を計画し、LCS 環境ページを使用して送信する必要があります。
ダウンタイム、ダウンタイムの軽減、データの移行、ストアの更新、一括デプロイなど、運用環境を更新する際には多くの考慮事項が存在します。 Commerce プロジェクトでは、通常、配置以上のものが必要となるため、更新に必要なすべての手順を計画しておくことは重要です。 その他の考慮事項については、この記事の「ヒント」セクションを参照してください。
Go-Live の計画が早く開始されたと見なされます。 詳細については、実装ライフサイクル を参照してください。
手順 5: Main ブランチから ProdRel1 ブランチへコードをマージ
運用環境へのデプロイの直後、および Main ブランチに新機能の作業を追加する前に、スナップショットを作成して ProdRel1 ブランチに移動します。 手順は、手順 4 と同じです。 個々の変更を選択する必要はありません。 代わりに、Main ブランチに送信した最後のコード変更セットまで、すべての変更をマージするだけです。
ビルド環境の更新
LCS パッケージの展開を使用して、バイナリ更新プログラムとプラットフォーム更新プログラムを常に展開します。
Finance and Commerce カスタマイズ パッケージをビルド環境にデプロイしないでください。
LCS タイル カウントの比較
同じリリースで作業に使用する環境には、同じ LCS タイル数が必要です。 タイル数が異なるいくつかの理由は以下の通りです。
- 同じ配置可能パッケージをデプロイして適用しませんでした。 LCS 展開履歴を調べて比較することで、この問題のトラブルシューティングを行うことができます。
- 環境からバージョン情報を収集するスケジュールされたタスクがまだ実行されていません。 開発環境では、「LCSDiagnosticsCollector」スケジュール タスクを実行を強制できます。
- X++ パッケージがビルド環境に配置されていないため、ビルド環境のアプリケーション更新数は一致しません。 バイナリとプラットフォームの数は正しいです。
- 違いは意図的なものです。 たとえば、開発者は次のバージョンで作業しますが、チームの残りの部分は引き続き別のリリースで作業しています。 または、運用環境の修正プログラムを開発する必要があり、運用環境が現在の開発環境よりも古いバージョンを使用する場合に備え、1 つの開発環境が古いバージョンに保持されます。
環境の更新が完了すると、使用可能な更新プログラムのタイル数は、開始時よりも少なくなります。
新しいバージョンへの移動
新しいバージョン (7.2 から 7.3、7.3 から 8.0 など) にアップグレードするには、新しい環境を配置する必要があります。 これらのアップグレードが適用可能な場合は、コードのアップグレードとデータベースのアップグレードも実行する必要があります。 詳細については、Code の移行ホーム ページ を参照してください。
ヒント
LCS アセット ライブラリの名前と、ダウンロードする zip パッケージの名前に適したパッケージの名前付け規則を決定します。 このようにして、配置したパッケージと送信元を簡単に確認できます。 パッケージ名にスペースを避けてください。 名前付け規則の例を次に示します。
- プラットフォームの更新プログラム: PUXX_MMDDYY の XX はプラットフォームの更新プログラムの番号です。
- バイナリ更新プログラムパッケージ: BIN_MMDDYY
- X++ 更新プログラム パッケージ: APP_MMDDYY
- 構築された X++ 配置可能パッケージ: AX_BRANCH_VERSION の BRANCH には適切な分岐の名前、VERSION は Microsoft Azure DevOps のバージョンの文字列になります。
- 組み込まれた Retail 統合パッケージ: RET_BRANCH_VERSION、この中でBRANCHは適切なブランチ名、VERSIONはAzure DevOpsバージョン文字列です。
新しい作業項目を開始するたびに、Visual Studio のソース コード エクスプローラーで最新を取得オプションを使用してください。
コード提出の変更セットを説明する正しい詳細なコメントを使用します。
本番稼働手順は重要です。 Go-Live チェックリストに次の項目を含むことを検討してください。 モックの運用開始環境またはUAT環境で、運用開始チェックリストを確認します。 このリストは、包括的ではありません。
- 展開後、LCS は正しいパッケージ名とともに予想される展開の履歴を表示しますか？
- 配置後、LCS 環境ページとコマースは、正しいバージョン番号と予測されるバージョン番号を表示しますか。
- Store Commerce アプリのオフライン モードは、コマースのダウンタイム中に使用できますか。 パッケージ配置には、ダウンタイムが発生します。 Store Commerce アプリのオフライン モードを使用できる場合、手順をテストしましたか? 手順をテストするには、オフラインにして展開し、オンラインにして、オフライン トランザクションを同期して、Store Commerce アプリを更新します。
- データベースが移動された場合、環境の再プロビジョニング ツールを実行する必要がありますか?
- CDX 同期のバッチ ジョブは、 待機中に設定して再度有効にする必要があります。
- 「コマース スケジューラを初期化」ジョブを実行する必要があります。
- 配置可能パッケージ (例: 画面、ボタン、レシートのレイアウト、Microsoft Entra ID セットアップ、コマース共有パラメーター、税コンフィギュレーション、その他のバッチ処理、DIXF の定期ジョブ) に加えて他のデータを設定する必要がありますか。
- CDX データ ジョブの同期は必須ですか。
- CDX データ ジョブの完全な同期は必須ですか。
- 配置には店舗のコンポーネントの更新も必要ですか。
- 店舗のコンポーネント更新が必要な場合、新しいバージョン番号を表示しますか？
- (たとえば、パートナー、ISV、および顧客) 配置中に正しいエキスパートが使用可能ですか？