次の方法で共有


Azure Pipelines に配置可能なパッケージの作成

カスタマイズを環境に配置する場合は、配置可能なパッケージが Microsoft Dynamics Lifecycle Services (LCS) に必要です。 このパッケージは、ビルド プロセスまたはリリース プロセス中に Azure Pipelines を使用して作成できます。

この記事は、Azure Pipelines の実用的な知識を前提としています。

メモ

  • これらのステップをパイプラインに追加する前に、Azure DevOps の Dynamics 365 Finance and Operations Tools拡張機能が有効になっていて、Azure DevOps アカウントにインストールされている必要があります。 組織に拡張機能をインストールする方法の詳細については、拡張機能のインストールを参照してください。
  • この Azure DevOps タスクを実行するには、エージェントで X++ コンパイラ ツールを使用できる必要があります。 このタスクをビルド バーチャル マシン (VM) エージェントで実行するか、コンパイラ ツール NuGetパッケージを使用してください。 NuGet パッケージとパイプラインへのインストール方法の詳細については、Microsoft がホストするエージェントと Azure Pipelines を使用したビルドの自動化を参照してください。

パイプラインへのタスクの追加

YML または Classic パイプラインのビルドにタスクを追加するには、配置可能なパッケージの作成のタスク リストを検索します。 次のテーブルに、このタスクで使用可能なオプションを示します。

入力名 必須 説明
X++ ツール パス X++ ツールの場所のパス。 この場所は、ビルド VM 上の PackagesLocalDirectory\bin フォルダーの場所か、コンパイラ ツール NuGet パッケージの抽出された NuGet ファイルの場所です。
パッケージに対する X++ バイナリの場所 配置可能パッケージに含める X++ パッケージ (モジュール) のすべてのバイナリが格納されているフォルダーのパス。 ビルド パイプラインでこのタスクを使用する場合、このフォルダーは通常、コンパイラの出力フォルダーと同じです。
パッケージ化するバイナリの検索パターン パッケージへの X++ バイナリの場所 オプションで指定されているパス内で、X++ パッケージ (モジュール) 名に一致する名前を指定します。 検索パターンの代わりに名前の一覧を指定したり、テスト パッケージが含まれていないように除外フィルターを指定したりすることもできます。 検索パターンは、フォルダーを検索し、X++ アセンブリ で bin サブフォルダーが含まれていることを検証します。 詳細については、ファイルの一致パターン リファレンスを参照してください。
配置可能なパッケージのファイル名とパス 配置可能なパッケージのパスとファイル名。 出力ファイルは zip ファイルであり、ファイル名には通常、ファイルを識別しやすいようにするためのバージョン情報が含まれています。

ノート

統合開発者エクスペリエンス の導入により、LCS と Power Platform 統合パッケージ形式の両方のパッケージを生成する能力がある、このタスクの新しいバージョンがリリースされました。 "クラウド配置可能パッケージのパス" の場所で Power Platform 統合パッケージ形式でパッケージを生成するには、Power Platform 統合パッケージの作成 チェック ボックスをオンにし、使用するプラットフォームとアプリケーションのバージョンを入力します。 検索パターンとツール パッケージ パスは、引き続き以前と同じ方法で受け入れされます。 LCS パッケージの作成オプションは既定で選択され、LCS パッケージの作成をオフにするオプションで、以前と同じ方法で生成されます。 プラットフォーム および アプリケーション バージョン のフィールドは 無視されます。

NuGet の依存関係

ビルド VM でこのタスクを実行すると、NuGet が既に使用可能になっており、アクションは必要ありません。 ただし、このタスクをホストされたエージェントまたはその他のプライベート エージェントで実行する場合は、NuGet がインストールされている必要があります。 この場合、Azure DevOps には、パッケージを作成するタスクを実行する前に実行できる NuGet ツール インストーラー タスクがあります。

メモ

NuGet バージョン 3.4 以降のセマンティック バージョニングが導入されたため、バージョン 3.3.0 またはそれ以前のバージョンをインストールする必要があります。

パッケージ化するバイナリの検索

ビルド仮想マシンのレガシー パッケージングと比較して、パッケージング タスクでは、パッケージするモジュールとその場所を指定する必要があります。 標準のパイプラインでは、コンパイル中の X ++ モジュールが Azure DevOps エージェントのバイナリ フォルダーに出力されます。 既定では、パッケージング タスクは X++ バイナリのフォルダーを検索します。 フォルダー名を検索します。 X++ アセンブリを含む /bin/ サブフォルダーがある場合は、このフォルダー内でタスクが確認されます。

メモ

ソース管理リポジトリに ISV モジュールなどのサード パーティ バイナリが含まれている場合、パッケージ ステップには特にそれらのバイナリが含まれています。 この記事の例のセクションを参照してください。

検索パターンの例

次の例では、パッケージへの X ++ バイナリの場所プロパティが既定値の $(Build.BinariesDirectory) に設定されていると想定しています。これは、X ++ コンパイラがバイナリを生成する場所です。

検索パターン 説明
* $(Build.BinariesDirectory) 内のすべての X++ バイナリを検索する。 これが既定値です。
*
!*Tests
すべての X++ バイナリを検索し、Tests で終了するモジュール名は除外します。
MyPackage $(Build.BinariesDirectory) フォルダーで MyPackage という名前のモジュールを検索します。
*
$(Build.SourcesDirectory)\Metadata\MyBinaryPackage
すべての X ++ バイナリを $(Build.BinariesDirectory) に含め、 MyBinaryPackage という名前のモジュールを Metadata フォルダー内のソース ディレクトリ (マップされたソース管理リポジトリ フォルダー) に含めます。
*
!*Tests
$(Build.SourcesDirectory)\Metadata\MyISV1
$(Build.SourcesDirectory)\Metadata\MyISV2
すべての X++ バイナリを $(Build.BinariesDirectory) に含め、名前が Tests で終わるモジュールを除外し、MyISV1MyISV2 という名前の 2 つのモジュールを Metadata フォルダー内のソース ディレクトリ (マップされたソース管理リポジトリ フォルダー) に含めます。

よくあるご質問

配置可能パッケージの作成手順では、"ディスクに容量が十分に空き" というエラーが発生した場合の機能は何でしょうか。

パイプラインを実行しているエージェントが 配置可能なパッケージの作成 ステップの間にディスク領域を使い切った場合は、このタスクの直前にパイプラインに削除ファイル タスクを導入し、$(Build.SourcesDirectory) の内容を削除します。 パイプラインの他の部分でこれらのファイルを使用している場合は、このタスクによって領域が作成されます。 配置可能パッケージの作成 手順は、ビルド ステップからのビルド出力に依存のため、モデル ソース ファイルには依存されません。