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