プロジェクトの新しい環境、Azure DevOps、およびブランチの設定
重要
Retail SDK のサポートは 2023 年 10 月に終了します。 開発・更新の簡素化、パフォーマンスの向上などの利点がある Commerce SDK をご利用いただくか、移行してください。
Microsoft Dynamics 365 Commerce プロジェクトでは、ほとんどの環境がクラウドでホストされます。 それら環境は Microsoft サブスクリプション または、クラウド ホストの顧客サブスクリプションで 提供されています。 既定では、環境は、Microsoft によってホストされます。 クラウド ホスト環境は、開発環境またはビルド環境を詳細に制御するために使用されます。 詳細については、Lifecycle Services (LCS) ユーザー ガイドを参照してください。
第 1 層環境の開発
開発環境は、第1層環境と呼ばれます。 開発環境を提供するにあたって、次の3 つのオプションがあります。
- コマース アプリには、1 つのサンドボックス第 1 層環境が用意されています。 (詳細については、Microsoft Dynamics 365、Enterprise Edition、ライセンス ガイドを参照してください。)
- Microsoft Azure のサブスクリプションで動作するクラウドホスト環境。 このタイプの環境は Microsoft Dynamics Lifecycle Services (LCS) にて "クラウド ホスト環境" と呼ばれています。
- 任意の場所でホストする、ダウンロードされた仮想マシン (VM)。
コード拡張を含むコマースの実装については、管理権限を使用できる開発環境を使用することをお勧めします。 管理者特権のない開発環境を使用する場合は、他のプログラミング ツールおよびオペレーティング システム をインストールまたは設定できません。
選択したホスティングモデルは、財務面にも影響があります。 第1層環境をシンプルなテスト環境として使うか、高品質なテスト環境として使用することでホスティング コストの一部を削減できます。 Dynamics 365 サブスクリプションでは、1 つのレベル 1 環境が無料です。 このアプローチは理想的ではありませんが、ほとんどのプロジェクトで有効です。
チャネル コンポーネントを拡張する場合は、 Prepare the development environment を参照し、開発の準備ができるよう開発環境の設定方法を確認してください。
メモ
いつでもクラウド ホスト環境をシャットダウンできます。 この機能は、ホスティングのコストを削減するのに役立ちます。
ホスティングの代替方法は、LCS から仮想ハードディスク (VHD) をダウンロードし、サーバー上にローカルにホストすることです。 開発の観点からは、VHD イメージはホスト VM と同じ処理能力を備えています。 唯一の違いは、LCS の展開が VHD でサポートされていないことです。 ただし、コマンド ラインの配置はサポートされています。
次のテーブルでは、それぞれのホスティング モデルの長所と短所を示します。 プロジェクトに最も適したモデルを評価するために、この情報を使用します。
| ホスティング モデル | メリット | 欠点 |
|---|---|---|
| Microsoft によってホストされる環境 (LCS プロジェクトでは、既定またはアドオンに基づく) | サブスクリプションには第1層環境が含まれています。 ビルド環境としてこの環境を使用することをお勧めします。
テレメトリ データは収集され、LCS 診断のページで利用可能です。 |
ユーザーは、管理アクションを実行できません。
ツールまたは証明書のをインストールができません。 |
| クラウドでホストされている環境 (LCS プロジェクトで、プライベートのサブスクリプション) | 完全な管理者権限が与えられています。
ツールと証明書をインストールできます。 |
追加のコストがあります。 環境をシャットダウンすることでコストを軽減することができます。 |
| 自己ホストされダウンロードされた VM | 経験は、ホストに依存します。 経験は、VM がソリッド ステート ドライブ (SSD) で実行するなら、さらに速くなります。 | LCS から パッケージを配置することはできません。 |
第 2 層およびそれ以上のマシンは、複数のテストと検証の目的のためのマルチ ボックス環境です。 運用環境はハンズ オンであり、LCS でサイズ変更のプロセスによって環境の規模が決定されます。
分岐、ビルド定義、および環境
分岐は、ソフトウェア開発における重要なプラクティスです。 分岐とマージ入門の記事では、分岐の利点について説明します。
メモ
分岐と統合の戦略には、リスクと生産性のトレードオフがあります。 孤立して作業することの安全性と引き換えに、他の人と作業する生産性が向上します。 生産性の向上にはコストが伴います。追加作業量は今後ソフトウェアの資産をマージするために必要です。
ブランチを使用すると、チームや個人が並行して作業できるため、個々のソフトウェア資産の分離とコントロールが向上し、生産性が増します。 ただし、分岐を使用すると、後で分岐全体を再構成する必要があるため、マージ アクティビティの増加も必要になり、そのためリスクも増加します。
分岐を作成するうえで、唯一の最良な戦略はありません。 ストラテジーは、プロジェクト、および実装のサイズによって異なります。
次の図は、3 つのコード ブランチを示しています: Dev、Main、および ProdRel1。 数字は、セットアップの順序を示します。
設定の説明は以下の通りです。 かっこ内の数字は、前の図の番号を参照してください。
- Dev ブランチ [2] は、テストの準備ができていない、または安定していない可能性がある日常作業に使用されますが、他の開発者と共有する必要があります。 大規模なチームは、さまざまな機能または目的のために、複数の開発ブランチを持つこともできます。
- Main ブランチ [1] は、品質基準を満たし、他のユーザーによるテストの準備ができている変更のためのものです。 このテストには、ユーザー承認テスト、パフォーマンス テスト、統合テスト、および修正プログラム後のサニティ テストが含まれる場合があります。 この分岐の配置可能パッケージは、ビルド環境で作成する必要があります。 ベスト プラクティスとして、レベル 1 環境で X++ パッケージを生成し、それらのパッケージを公式テストまたは運用環境に配置するべきではありません。 それ以外の場合は、コミットされていないソースの変更が含まれる可能性があります。 適切なアプローチは、常に正式なビルド環境でビルドされたパッケージを展開します。
- ProdRel1 ブランチ [3] は、任意の時点で実稼働環境に配備される際、全てのソース コードを保留します。 ビルド環境で使用できますが、必須ではありません。 Main ブランチからのパッケージが運用環境に配置されている場合、運用配置後に (Main から ProdRel1 へ) コードをマージする必要があります。 生産用分岐を用意することで、ビルドが必要な場合に、後で公式ビルドを生成することができます。
- 3 つのすべての分岐は、 X++ コード (メタデータのフォルダー内の拡張機能および修正プログラム)、および Retail ソフトウェア開発キット (SDK) のコピーの両方を RetailSdk のフォルダー [5, 6, 7] 内に保持しています。 Retail SDKには、基準の Microsoft コードおよびコードの拡張子が含まれています。 この基本コードとコードの拡張機能は、各分岐で異なります。
- RetailSdk-mirror フォルダー [4] は、Microsoft 変更を Retail SDK に持ち込むために使用されます。 開発またはビルドの目的で使用されていません。 新しいバージョンまたは修正プログラムを使用する場合にのみ更新する必要があります。
小規模な売プロジェクトでは、分岐が 2 つしかなくても構いません (メイン = 開発分岐)。 ただし、コード送信はテスト ビルドの品質に即座に影響を与える可能性があるため、開発者は規範を守らなければなりません。
複数のブランチから配置可能なパッケージを作成することができます。 この場合、ビルド可能な各分岐に対して 1 つのビルド定義を持つ必要があります。 ビルド環境が配置される際、初期のビルド定義が自動的に作成されます (Main ブランチ)。 他のブランチのビルドのコピーを作成することができます。 コマース コードを組み込むには、小規模な追加を行う必要があります。
次の高レベルの手順を使用して、開発作業を開始できるように環境を設定します。 カッコ内の数字の詳細については、前述の図と関連情報を参照してください。
- ビルド環境と Microsoft Azure DevOps [1] の空の Main ブランチを配置します。
- 開発環境の配置をする。
- 開発ブランチとリリース ブランチ (たとえば、前の図 ProdRel1) を作成する [2, 3]。
- Retail SDK [4–7] を追加します。
- 開発環境を準備します。
- オプション: 別のリリース ブランチの 2 つ目のビルド環境を配置します。
- ビルド定義を準備します。
これらすべての手順が完了した後、分岐、環境、およびビルドが準備完了になります。
次のセクションでは、各手順の詳細について説明します。
ビルド環境と Azure DevOps の空の Main ブランチを配置する
LCS のポータルを使用して、新しいビルド環境を配置します。 管理者権限がある場合は、より多くのオプションと機能を有することができるため、クラウド ホスト環境を使用することをお勧めします。 この記事で前述した、「第 1 層環境の開発」のさまざまな環境ホスティング モデルに関するテーブルを参照してください。
未所持の場合は、新しい Azure DevOps プロジェクトを作成して開始します。 Azure DevOps アカウントで、新しいプロジェクトを選択します。
新規 Azure DevOps プロジェクトが作成した後で、Azure DevOps へのアクセスを許可する必要があります。 最初に、Azure DevOps アカウントに新しい個人用のアクセス トークンを作成します。 次に、正しい URL と個人用アクセス トークンで LCS プロジェクトをコンフィギュレーションします。
重要
Azure DevOps プロジェクトで "クラシック ビルドおよびクラシック リリース パイプライン" を無効にしないでください。
LCS プロジェクトが Azure DevOps にリンクされたら、配置の準備ができています。
新しい環境を追加、バージョンを選択、DEVTEST をトポロジとして追加、およびビルド環境を選択します。 次のページで、意味のある環境名を入力します。 次に、ビルド エージェントの類似の名前を入力します。
次に、 仮想マシン名をカスタマイズ配下で、一意の名前を入力し、VMを配置します。
以下の図に示されているように、ビルド ボックスは配置され、ビルド定義および Main ブランチが作成されます。 このプロセスには数時間かかる場合があります。
ビルド定義の一覧にビルドが表示されます。
ビルド定義は、 Agents for pool Default のグリッドに に表示されます。
開発環境の配置
実装プロジェクトの LCS ポータルを使用して、クラウド ホストの開発環境を作成します。
- 正しいユーザー アカウントにサイン インしていることを確認してください。 このユーザー アカウントは開発マシンのテナントの作成に使用されます。 たとえば、LCS に
lily@pad.comとしてサインインしている場合、環境は @pad.com テナント用に設定され、そのテナントからのユーザが必要です。 他のユーザーを追加することができますが、Point of Sale (POS) の有効化はそのテナントのユーザーが行う必要があります 場合によっては、顧客、パートナー、または他の関係者が異なるドメインの電子メール アカウントを使用する場合など、異なるドメインのユーザー アカウントが使用されることもあります。 このような場合、配置中に使用されたテナントのみがユーザーをアクティブ化できるため、POS が有効なうちに調整が必要です。 - 正しいバージョンを選択し、DEVTEST を選択し、DEV を選択します。 わかりやすい固有の名前を入力し、詳細設定でもマシン名が固有であることを確認してください。 マシン準備のプロセスは、数時間かかる場合があります。
現在、Dev 分岐は存在しないため、Azure DevOps をローカル ディレクトリにマッピングするプロセスをスキップ可能です。 ただし、後でそのプロセスを完了する必要があります。
開発およびリリースの分岐を作成する
前述のように、変更が頻繁に行われるが、あまりテストされないブランチがある必要があります。 生産のソース コードを格納するブランチも必要です。 次の図は、予期される階層を示しています。
分岐を作成するには、次の手順に従います。
- 開発環境にサインインします。
- Microsoft Visual Studio を管理者として起動します。 Azure DevOpsプロジェクトへのアクセス許可を持つアカウントを使用します。
- チーム エクスプローラーでは、この接続が存在しない場合に、Azure DevOps のプロジェクトに Visual Studio を接続します。
- トランク/メイン フォルダーをローカル フォルダーにマップします (このマッピングが既に存在しない場合)。 このマッピングは一時的なものです。
- ソース管理エクスプローラーでは、Main フォルダーを右クリックし、分岐とマージ>分岐への変換を選択します。
- Main ブランチを右クリックし、分岐とマージ>分岐を選択し、新しい分岐を開発と名付けます。
- 保留中の変更を使用し、この変更内容を Azure DevOps に送信します。
- Mainブランチを右クリックし、分岐とマージ>分岐を選択し、新しい分岐を ProdRel1 と名付けます。
- 保留中の変更を使用し、この変更内容を Azure DevOps に送信します。
この時点で、 Visual Studio の Source Depot エクスプローラーは以下の図のようになります。
Retail SDK を追加
次に、3 つのコード分岐のそれぞれに Retail SDK を追加して、コードの変更を Dev から Main に、そして最終的に ProdRel1 に反映させる必要があります。 このステップでは、X++ コードと同様に、これらの分岐間での別々の変更も可能です。 したがって、 X++ コードと共にすべての分岐に Retail SDK があります。
最初に、ミラー分岐を追加します。 Retail SDK のミラー ブランチは、Microsoft からの更新プログラムをインポートする際、コード マージのベースラインとして必要です。 更新プログラムを実行するプロセスについては、この記事の後で説明があります。
ミラー ブランチまたはフォルダーは、プロジェクトごとに 1 回のみ必要です。
開発を開始する正確なバージョンのある変更していない Retail SDK を検索します。 この Retail SDK は、サービス ドライブ上のすべての開発マシン、またはダウンロードされたすべての修正プログラムに表示されます。 Microsoft-version.txt ファイルを調べることによって、Retail SDK のバージョンを一意に識別することができます。 このファイルは、Retail SDK ミラー フォルダへの更新以外は変更しないでください。
ソース管理エクスプローラーでは、トランク フォルダーを右クリックし、フォルダーへの品目の追加を選択します。
小売 SDK でトップ フォルダーを選択し、次へを選択します。
Visual Studio は、追加されるファイルの数を示します。 RetailSdk フォルダーがトランク フォルダーの下にあることを確認してください。
項目を選択してから、項目を含むを選択して、除外されたアイテムが 0 (ゼロ) であることを確認してください。
完了 を選択します。 このプロセスには数分かかる場合があります。
処理が完了したら、フォルダーの名前を RetailSdk-mirror に変更します。
次に、各分岐に分岐する必要があります。 コードの変更と同じパスをたどります。最初は Dev、その後は Main、次に ProdRel1 に進みます。
ミラー分岐のフォルダーを選択し、右クリックして、分岐とマージ>分岐を選択します。
開発分岐に移動し、/RetailSdk を名前に追加し、それから OK を選択します。
保留中の変更を使用し、変更内容を送信します。
同様の手順に従って、開発ブランチの RetailSdk フォルダを Main ブランチに分岐します。
同様の手順に従って、Main ブランチの RetailSdk フォルダを ProdRel1 ブランチに分岐します。
この時点で、 X++ およびコマース拡張機能設定のコード ブランチとコード場所があります。 ソース管理エクスプローラーでは、ファイル構造は次の図のようになります。
コマース カスタマイズのバージョンを変更する必要もあります。 このバージョンは、Dev、Main、および ProdRel1 の分岐で異なっている必要があります。 Customization.settings ファイルを変更するか、RetailSdk\BuildTools フォルダーに新しい global.props ファイルを追加してください。 たとえば、Dev に 1.0.0.x、Main に 1.0.1.x、ProdRel1 に 1.0.2.x と番号を付けることができます。
開発環境の準備
コマース開発タスクに開発環境を準備することができます。 開発環境では、Dev ブランチの X++ と Retail SDK の両コード の場所をローカル フォルダーにマップします。 メタデータ フォルダー (X++) は、常に PackagesLocalDirectory フォルダーへ割り当てる必要があります。 RetailSdk フォルダーの場所は、次のガイドラインに従う必要があります。
- 場所は、ローカル ユーザーのフォルダーのどこかにあるはずです。
- ファイルパスは、256文字以内に制限されます。 そのため、Retail SDK のルートへの短いパスを使用します。 たとえば c:\users\<user name>\Source\RetailSdk を利用できます。
X++ および Retail SDK をマッピングするには、現在のワークスペースを編集する必要があります。 保留中の変更>操作>ワークスペースを選択し、現在のワークスペースを次の図のように更新します。 前述のように、分岐のメタデータ フォルダを PackagesLocalDirectory フォルダに、RetailSdk を選択した短縮フォルダにマッピングする必要があります。
ファイルのダウンロードには数分かかります。
コード ブランチのカスタマイズがあるかどうかに関係なく、以下の手順によって、開発ボックスにてコードの書き込みと実行ができる状態します。 計画されているカスタマイズに応じて、いくつかの手順はオプション扱いとなります。
好みの開発ツールをインストールします。 自動化されたスクリプトの詳細については、最も必要な開発ツールを Chocolatey で 5 分で自動インストールするを参照してください。
コンパイル時間を削減するには、Microsoft Windows Defender からコードのフォルダーを除外します。
Dev/Metadata フォルダー内のコードが既に存在する場合は、すべてのコマース モデルを構築してください。 すべてのモデルを選択し、データベース同期を選択します。
開発経験を速めるために、Microsoft インターネット インフォメーション サービス (IIS) に切り替えます。 手順については、 MSDyn365FO. 開発 VM を IIS Express から の IIS に切り替える方法を参照してください。 この手順は、管理者権限 (クラウド ホスト環境) を持つ第 1 層の VM でのみ実行できます。
オプション: 適切なデータが含まれている生産データベースの最新のコピーを復元します。
既存のデータベース AxDB_Orig の名前を変更します。
Microsoft SQL Server Management Studio では、.bak ファイルを復元します。 (.bacpac ファイルが存在する場合、Azure SQL データベースから SQL Server 環境にデータベースをコピーに記載されている手順に従います。)
Visual Studio で、モデル ストアを更新します。
Visual Studio では、データベースのソースおよびコピー先の環境が異なるバージョンの場合、完全なビルドを実行します。
Visual Studio で、データベースの完全同期を実行します。
バッチ サービスが実行中であることを確認してください。
環境再プロビジョニング ツールを実行します。 (LCS 資産ライブラリで最新バージョンを見つけて、Maintain 関数を使用して展開します。)
ツールが成功したことを確認します。 次のクエリでは、更新されたすべてのローカル開発コンピューターの URL が表示されます。
select * from dbo.RETAILCHANNELPROFILEPROPERTY where ISSYSTEMRECORD = 1コマースで、コマース スケジューラの初期化ジョブを実行して、古いデータを削除します。
ユーザーアカウントを使用してコマースにサインインできることを確認してください。 運用データベースの管理者でない場合は、管理者プロビジョニング ツールを実行して所有権を取得することができます。 (このツールは PackagesLocalDirectory/bin フォルダーにあります。)
Commerce Data Exchange (CDX) データの同期が機能することを確認します。 コマースでは、ダウンロード セッションに移動します。 多くの適用済セッションが表示されます。 表示されない場合は、ジョブ 9999 を選択して実行してください。
https://www.microsoft.com/download/details.aspx?id=48593 から TypeScript バージョン 2.2.2 をインストールします。
コマンド プロンプトから Retail SDK の完全なビルドを実行します。
- 管理者として、Microsoft Visual Studio 2015 の MSbuild コマンド プロンプトを開きます。
- ローカル VM で、 Retail SDK の場所にディレクトリを変更します。
- msbuild と入力し、Enter キーを押します。 ビルドは成功するはずです。
開発/サンプル Retail Modern POS (MPOS) 証明書をローカル コンピューターの信頼されたルート証明書ストアに追加する: ...\RetailSDK\BuildTools\ModernPOSAppxSigningCert-Contoso.pfx。 パスワードを空の文字列に設定します。
...\RetailSDK \References\YourCompany|Contoso.ModernPOSSetupOffline.exe でインストーラーを実行して、MPO または MPOSOffline をインストールする ClientBroker ファイルを配置するのには、1 回でこの手順を完了する必要があります。
Visual Studio で、ModernPOS.sln (管理者として) を開き、完全なリビルドを実行します。
F5 キーを押して、MPOS をデバッガーで起動します。
コマースでは、チャネル プロファイル ページを開き、既定のチャネル プロファイルのために Commerce Scale Unit URL をコピーします。
ブラウザー ウィンドウを開き、アドレス バーに URL を貼り付けます。 ローカル Commerce Scale Unit を参照できるようになります。
コマースでは、(アクティブ化) のいずれかの作業者への外部ユーザーの資格情報を加え、パスワードを保存し、最初のサインインの際にパスワード リセットを許可しないでください。
コマースで、ジョブ 1060 (AX/Distribution schedule) を実行します。
手順 16 で追加したものと同じ Microsoft Entra ユーザーを使用して、MPOS を有効にします。 Commerce Scale Unit URL を貼り付け、ストアとレジスターを選択し、有効化を完了します。
ローカルのソースからデバッガで MPOS を実行できるようになりました。
開発環境を準備するプロセスが完了したところです。 この時点で、任意の拡張コード (X++、Commerce Runtime [CRT]、Commerce Scale Unit、チャネル SQL、POS) を Azure DevOps に書き込み、デバッグ、テスト、送信することができます。
オプション: 別のリリース ブランチの 2 つ目のビルド環境を配置
複数のリリースを同時に管理する必要がある場合は、異なるコード ブランチ (例えば、Main2 または Main3、または ProdRel1 または ProdRel2) から配置可能パッケージを作成する必要があります。
2 つ目のビルド環境を設定する手順は、最初のビルド環境の手順と同じです。 この時点で、Azure DevOps プロジェクト および LCS プロジェクトと Azure DevOps プロジェクト間のリンクが既に存在しています。
ビルド環境を分離するには、リリース ブランチの新しい Azure DevOps エージェント キューを作成することをお勧めします。 複数の分岐に対してエージェント キュー (およびそのビルド環境) を共有する方法はありますが、この方法は扱いにくいことがあります。
現時点では、ビルド環境は、配置中にターゲット環境としてバイナリ修正プログラムのバージョンと同じプラットフォームにする必要があります。 それ以外の場合は、LCS でバージョンの互換性がないため配置可能パッケージを拒否する可能性があります。
最初に新しい Azure DevOps エージェント キューを作成してください。
LCS から配置する際、PRODREL1 をエージェント プールの名前として使用してください。
次に、 仮想マシン名をカスタマイズ タブで、一意の名前を入力してから新規ビルドを配置します。 新しいビルドの展開およびエージェント キューの作成にかかるプロセスは、数時間かかります。
ビルド定義の準備
この記事で前述の手順を完了した後は、1 つのビルド定義および 2 つのエージェント キューが必要があり、各エージェント キューは 1 つのエージェントを持つ必要があります。 異なる分岐をビルドするには、ビルド定義を異なる方法でコンフィギュレーションしなければなりません。 したがって、ビルド定義を複製する必要があります。
ただし、ビルド定義を複製する前に、この手順を 2 回実行する必要がないように、Retail SDK をビルドに追加する必要があります。 Unified Operations プラットフォーム - Build Main という名前の既存のビルド定義を編集するには、Retail SDK を継続的ビルド システムと統合 (Azure DevOps) の手順に従って、Main 分岐のメタデータビルドに Retail SDK を統合します。
複数のビルド ブランチおよび環境がある場合、ビルド定義を複製し、新しいビルド定義に名前を付けるだけで、どのブランチのためであるかを明確にします。 (複製機能は Azure DevOps のポータルで使用することができます)。 作成した新しいエージェント キューを選択し、任意のビルド ステップまたはソース マッピングの次のパスを変更します。 (パスで、メインを ProdRel1 に変更します。)
- ソース マッピング
- Retail SDK ビルド ステップ
- Retail SDK のコピー バイナリ ステップ
- ソリューション ステップ (X++ ビルド) の構築
- Retail SDK のコピー パッケージ ステップ
ヒント
ビルド定義の変数セクションでこれらの変更を行うことで、公式ビルドを速めることができます。
- DeployReports を 0 に設定します。
- SkipSourcePackageGeneration を 1 に設定します。
各分岐のコマース カスタマイズのバージョンを変更します。 バージョンは、Dev、Main、および ProdRel1 の分岐で異なっている必要があります。 Customization.settings ファイルを変更するか、 RetailSdk\BuildTools フォルダーに新しい global.props ファイルを追加してください。 ファイル名には、任意の種類の番号を付けることができます。 たとえば、Dev に 1.0.0.x、Main に 1.0.1.x、ProdRel1 に 1.0.2.x と番号を付けることができます。
効率性のため、使用されていないときは、ビルドや開発環境をシャットダウンします。
クラウド ホストの階層 1 開発環境（管理者権限を持つ）を使用している場合は、IIS Express から IIS に切り替えることができます。 IIS を使用してすべての Web アプリケーションを実行すると、より堅牢になりパフォーマンスが向上し、切り替えが回避されます。 詳細については、MSDyn365FO. IIS Express から開発 VM の IIS に切り替える方法を参照してください。
プロトタイプの目的で、開発者は Azure DevOps ソースコントロールを使用せずに開発 VM で Retail SDK を変更したいと思うかもしれません。 手を加えずに常に元の Retail SDK を保持し、一時的に使用できるコピーを作成します。 このようにして、変更されていない Retail SDK を必要に応じて、後でミラー分岐に入れることができます。
現時点では、ビルド環境は、ターゲット環境としてバイナリ修正プログラムのバージョンと同じプラットフォームにする必要があります。