次の方法で共有

開発と継続的デリバリーに関するよく寄せられる質問

注

コミュニティの関心グループが Yammer から Microsoft Viva Engage に移行されました。 Viva Engage コミュニティに参加し、最新のディスカッションに参加するには、「 Finance and Operations Viva Engage Community へのアクセスを要求する 」フォームに入力し、参加するコミュニティを選択します。

この記事では、独立系ソフトウェア ベンダー (ISV) やパートナーがよく寄せられる質問 (特に開発、テスト、配信、ライフサイクル管理に関するガイドライン) に対する回答をまとめます。

カスタマイズ

カスタマイズ (オーバーレイ) するか、または拡張子を使用するか。

拡張性は、Finance、Supply Chain、およびコマースにおける唯一のカスタマイズ フレームワークです。 オーバーレイはサポートされません。

パートナー、付加価値リセラー (VAR)、一部のお客様も Dynamics 365 Finance、Supply Chain、Commerce を広範にカスタマイズしています。 製品をカスタマイズする機能は、アプリケーション コードのオーバーレイによって従来サポートされていた強みです。 クラウドへの移行を、柔軟なサービスの提供や頻繁な更新と合わせて行う場合、更新がカスタム ソリューションに及ぼす影響を小さくとどめるため、侵入性の低いカスタマイズが必要となります。 この新しいモデルは 拡張性 と呼ばれ、オーバーレイによってカスタマイズを置き換えます。

詳細については、 拡張機能のホーム ページ および 開発とカスタマイズのホーム ページ を参照してください。

顧客や他のパートナーがモデルをカスタマイズできないようにするにはどうすればよいですか?

モデルのカスタマイズをブロックするには、「モデルの カスタマイズを無効にして機能を非推奨にする」を参照してください。 モデル ファイルを配布する代わりに、展開可能なパッケージを顧客に配布することもできます。 詳細については、この記事の後半の「アプリケーションを顧客に配布する方法」というタイトルのセクションを参照してください。

モデルのスコープをどのように定義できますか。 モデルまたはパッケージをいくつ作成する必要がありますか。

モデルとモデル要素を設計することは、他のタイプのソフトウェア ライブラリを設計することと変わりありません。 SOLID (オブジェクト指向設計) 設計原則を適用します。 さらに、プラットフォームに固有の次のヒントを検討してください。

  • ソリューションに、他のコンポーネントよりも頻繁に出荷およびサービスを提供するコンポーネントがある場合は、それらを別のモデルとパッケージに配置します。
  • 実装の初期段階では、2 つのパッケージ (それぞれ 1 つのモデル) から始めるのが一般的です。1 つは、Microsoft プラットフォーム パッケージの拡張機能を含む基本パッケージと、Microsoft アプリケーション パッケージの拡張機能を含む 1 つのアプリケーション パッケージです。 必要に応じて、より多くのモデルを導入します。
  • 必要に応じて、既存のパッケージをより小さなパッケージに分割します。 いずれかのパッケージを使用して実装が既に稼働している場合は、ライフサイクル管理を簡素化するためにパッケージの名前を変更しないでください。

継続的な配信

環境を構築する必要があるか。

はい。ビルド環境で提供されているビルドとテストの自動化ツールを利用してください。 Lifecycle Services (LCS) プロジェクトからビルド環境を展開することができます。 毎日のビルドと毎日の回帰テストを作成することは、継続的デリバリーを可能にし、アプリケーションの品質を維持するための重要なツールです。 詳細については、継続的なビルドとテストの自動化をサポートする環境を配置して使用する を参照してください。

開発環境にはビルド環境を使用しないでください。 これらのビルド VM にテスト データベースのバックアップを保持しないでください。 ビルド VM は、すべてのビルドと、LCS の Microsoft バイナリまたはプラットフォームの更新プログラムで更新されるたびに、既知の状態にリセットするように設計されています。 たとえば、バイナリの修正プログラムやプラットフォームの更新をビルド VM に適用する場合、VM は更新の一部として次のビルドのために準備します。 このプロセスにより、カスタマイズが削除され、データベース同期もトリガーされます。

テストの自動化にどのような戦略を使用しますか ?

テストの自動化については、独立したデータまたは独自のデータを作成する単体テスト (SysTest フレームワークを使用) に焦点を合わせます。 テスト データに依存して実行する少数の機能シナリオ テスト (タスク レコーダーに基づく) を使用します。 シナリオ テストは、維持にコストがかかります。 あらゆる開発環境で簡単かつ迅速に単体テストを実行できます。 テスト自動化のピラミッド に関するブログ記事を確認し、 自動化されたテストのガイダンス を参照してください。

テスト自動化ピラミッドのスクリーンショット。

次の重要な概念に留意してください。

  • 独立して実行され、どのような種類の順序も想定しないテストを記述します。
  • タスク レコーダー テストを機能シナリオに制限します。
  • シナリオが完了した後のシナリオ テストおよび単体テスト完了後のシナリオ テストを記述します。
  • 可能な限りテスト ヘルパー クラスを作成し、チームの他のユーザーがそれらを活用できるようにします。
  • SysTest フレームワークではロールベースのテストがサポートされているため、この機能を利用します。

開発に関してどのようにより機敏になれますか。

各スプリント（推奨2週間）または各サイクル（1か月）で増分機能を提供します。 各スプリントの終わりでアプリケーションの出荷可能な品質を管理します。 作業項目の進捗管理には Azure DevOps を使用し、常に新しい機能よりもバグに優先度を高くします。 大規模なバグ バックログは、新機能の効率的な配信とアプリケーションの品質にすぐに負担になります。

テスト データをどのように管理しますか。

次のようにテスト データベースを作成および管理します。

  • クリーンな環境で開始します。
  • 必要に応じてすべての基本データを作成します。 基本データは、すべてのテストの開始点として機能します。
  • AxDB データベースのバックアップ (.bak) を取得します。
  • このバックアップを開発者と共有します。

ビルド環境で、このバックアップを I:\DynamicsBackupDatabases ドライブにコピーします (一部の環境では、 I:とは異なるドライブである可能性があります)。 すべてのビルドの開始時に、このデータベースを復元します。 この手順は、ビルド定義の最初の手順であるビルド の準備の一部です。

ビルド定義の [ビルドの準備] ステップのスクリーンショット。

顧客にアプリケーションをどのように配布しますか。

2 つの成果物を使用して、アプリケーションを顧客またはパートナーに配布します。モデル ファイルまたはデプロイ可能なパッケージです。 モデル ファイルは、ソース コードが含まれるデザイン タイム コンポーネントです。 顧客がアプリケーションを他のサード パーティのモデルと統合する場合、またはモデルのカスタマイズを許可する場合は、モデル ファイルを使用します。 詳細については、 モデルのエクスポートとインポート を参照してください。 モデル ファイルは、ISV にとってソリューションを配布するための最も一般的な方法です。 配置可能パッケージは最後のアプリケーションです。 デプロイ可能なパッケージは、アプリケーションをカスタマイズしたり、他のサード パーティ製モデルと統合したりしない顧客と共に使用します。 配置可能なパッケージを使用する場合、顧客はアプリケーションの使用または拡張のみが可能です。 ソースコードを見ることも、アクセスすることもできません。 配置可能なパッケージを作成するには、Visual Studio ツール (Dynamics 365>Deploy>Create Deployment パッケージ) を使用するか、ビルド環境を使用します。 ビルド環境は、すべての成功したビルドで配置可能パッケージを生成します。

開発トポロジ

オンプレミスまたはクラウドで開発する必要がありますか?

クラウド VM と、ダウンロード可能な VHD を介して利用できるオンプレミス VM の 2 つの開発モードを利用できます。 開発には、オンプレミスの VM とクラウド VM の組み合わせを使用します。

  • オンプレミスの開発用 VM は、それらをサポートするハードウェア、IT インフラストラクチャ、および Windows Server ライセンスが既にある場合、コスト効率が高くなります。
  • クラウド VM を使用して、限られた期間にわたってプロジェクトに追加のリソースが必要な場合にスケールアウトします。 オンプレミスで最悪のケースの容量を計画するよりも、コスト効率が高くなります。
  • バージョン管理のために、すべての VM (オンプレミスとクラウドの VM) を Azure DevOps に接続します。

ビルド、機能テスト、デモには、クラウド VM を使用します。 独自の Microsoft Azure サブスクリプションで実行している場合は、使用していないときにオフにします。

顧客の開発環境を使用する必要がありますか。

パートナーの場合は、独自の VM を使用して独自の知的財産 (IP) を開発します。 このコードと構成データ パッケージは、さまざまなお客様の実装で再利用できます。 顧客固有の実装については、顧客の開発 VM を使用することができます。 すべての顧客サブスクリプションには、少なくとも 1 つの開発 VM が含まれています。 顧客は、アドオン開発用 VM の支払いや、ローカル開発用 VM の実行が可能です。

開発に関して MSDN サブスクリプションの利点とは

次の一覧は、Visual Studio (VS) と MSDN サブスクリプションの利点をまとめたものです。

  • Visual Studio Professional with MSDN の場合は月額 $50 で、VS Enterprise with MSDN の場合は $150 で Microsoft Azure サブスクリプションが含まれます。
  • サブスクリプションには、より低い開発/テスト レートが付属しています。 Windows 料金の代わりに Linux 料金を支払います。
  • 詳細については、 https://azure.microsoft.com/pricing/member-offers/msdn-benefits-details/を参照してください。

マイクロソフト パートナーは、Microsoft コア コンピテンシーを取得して MSDN サブスクリプションで無料の VS Enterprise を獲得できます。 たとえば、ゴールド パートナーのアプリケーション開発コンピテンシーは、コア特典に付属する 10 個のライセンスに加えて、25 個の無料の MSDN Enterprise ライセンスを獲得します。 詳細については、Visual Studio サブスクライバの月額 Azure クレジット にアクセスしてください。 これらの利点は、クラウド開発を非常に経済的にします。 例えば次が挙げられます。

  • D12v2 VM 表示価格は = $470/月 (4コア、28ギガ)
  • D12v2 MSDN Azure またはその他の dev/test サブスクリプションで実行している場合の VM 価格 = $276/月
  • 1 日あたり 12 時間停止: 276/2 => $138/月
  • 月額クレジット (VS Professional with MSDN) => 138 - 50 = $88/月
  • 月額 (VS Enterprise with MSDN) => 138 – 150 = 無料

別の例を次に示します。

  • D13v2 マシン 表示価格は = $843/月 (8コア、56ギガ)
  • MSDN Azure のサブスクリプションで稼働している場合、D13v2 マシン価格 = $551/月
  • 1 日あたり 12 時間停止: 551/2 = $275.5/月
  • 月額クレジット (VS Professional with MSDN): 275.5 - 50 = $225.5/月
  • 毎月のクレジット (VS Enterprise with MSDN) = > 275.5 – 150 = 125.5ドル/月

VM ごとに毎月平均 15 USD のストレージ (非プレミアム) を追加します。

複数の開発者が同じ VM 上で同時に開発できますか。

このシナリオはサポートされていません。 ただし、同じ VM に複数の開発者アカウントをプロビジョニングすることはできますが、開発者は同時に作業することはできません。 詳細については、 開発マシンでの新しいユーザーの作成 を参照してください。

Microsoft パートナーが複数の顧客のコードを開発している場合は、顧客ごとに少なくとも 1 つの開発 VM を使用します。 顧客プロジェクトに取り組む追加の開発者ごとに、1 つの追加 VM が必要です。 ソース コードがバージョン管理 (Azure DevOps) にチェックインされ、テスト データベースのバックアップを保持している限り、開発 VM は破棄可能な資産と考えてください。

顧客実装 LCS プロジェクト

LCS 顧客実装プロジェクト内でいくつのサンド ボックス環境が必要ですか。

顧客サブスクリプションは、既定では、2 層サンド ボックス環境、および運用環境の 2 つの環境があります。 アプリケーションが生産の稼働に移行する前に、構成と UAT 環境として 2 層のサンド ボックス環境を使用できます。 公開する必要があるコードとデータ ( ゴールド構成とも呼ばれます) を使用してサンドボックスを構成した後、同じ環境で検証を実行できます。 検証に合格したとき、サンド ボックス データベースをそのゴールド構成の時点まで復元します。 コードを生産に展開して、サンドボックス データベースを運用環境にコピーすることができます。 また、特にアプリケーションが稼働後に、階層 2 またはそれ以上にある複数のサンドボックス環境を持つように選択することができます。 1 つのサンドボックスは実稼働前の UAT 環境として使用でき、もう 1 つのサンドボックスは構成、アップグレード、またはその他のシナリオに使用できます。 階層 2 またはそれより高階層のサンドボックスをさらに購入することができます。

LCS では、次のサービス要求とツールがサポートされています。これは、実装に 1 つの階層 2 サンドボックスで十分かどうかを判断するのに役立ちます。

  1. サンドボックス データベースを特定の時点に復元します。
  2. 運用環境にサンドボックス データベースをコピーします (アプリケーションが運用に公開される前にのみ許可されます)。
  3. サンドボックス環境にコンフィギュレーション データ パッケージを適用します。
  4. 運用環境にコンフィギュレーション データ パッケージを適用します。
  5. 運用環境からサンドボックス データベースを更新します。 運用環境のデータベースを階層 2 のサンドボックス環境にコピーします。 このプロセスは通常、アプリケーションの稼働後に発生し、問題をデバッグするか、今後の更新プログラムを検証する必要があります。
  6. 運用環境に適用する前に、検証のためにサンドボックス環境に更新プログラム (修正プログラム、カスタマイズ) を適用します。

環境の計画に関する詳細については、環境計画 を参照してください。

  • Last updated on