ビルド、テスト、および品質管理の各プロセスの計画

完了

このユニットでは、ビルド、テスト、品質テスト プロセスの管理に使用される開発プロセスをレビューし、これらのプロセスを管理するための計画方法についての情報を提供します。

ビルドのプロジェクト計画の作成

選択した方法に応じて、ビルドの時間と場所を選択する必要があります。 また、どの順序でビルドを実行するかを決定する必要があります。 たとえば、最初にテスト環境を実行せずに、開発環境から実稼働環境にコードをビルドすることは望ましくありません。

また、開発をロールバックする必要があるためにテストを通過しなかった開発をどう処理するかについても検討する必要があります。 これにより、エラーを昇格させてしまうことがなくなります。 Lifecycle Services を使用すると、環境から環境へのビルドの管理に役立てることができます。

たとえば、ビルドでは、エラーが発生したコードをテスト環境から開発環境にロールバックし、テストを通過したコードをテストから実稼働環境に昇格させた後、最終的に完了したコードを開発環境からテストに昇格させることができます。

必要な環境を決定する

環境の選択は、実装の開始時に計画する必要があります。 環境を計画する際、次を行う必要があります。

  • 環境の目的を決定する。 環境を開発、システム テスト、ユーザー受け入れテスト (UAT)、または操作のいずれで使用するかを検討する。
  • 開発ビルドおよびテストなどの環境トポロジを考慮する。
  • 環境階層 (第 1 層または第 2 層) を考慮する。

第 1 層環境とは、すべてのコンポーネントが同じサーバーにインストールされた単一ボックス環境のことです。 第 1 層環境は Microsoft SQL Server を使用しており、開発の効率を高めるために構造化されています。 この層は、UAT またはパフォーマンス テストには適切ではありません。

第 2 層またはそれ以上の環境は、複数のサーバーにコンポーネントがインストールされたマルチボックス環境です。 第 2 層では、Microsoft SQL Server の代わりに Azure SQL Database を使用します。 この環境では運用環境と同じアーキテクチャが使用されますが、ディザスター リカバリーは使用されません。 この環境は、UAT およびパフォーマンス テストに使用する必要があります。

環境向けの標準クラウド オファーには、開発とテストのための第 1 層環境、UAT のための第 2 層環境、および運用環境が含まれます。 これらの環境は、それぞれ異なるタイミングで提供されます。 第 2 層はオンボード中に提供されます。 第 1 層の開発およびテスト環境は、設計フェーズを開始し、Microsoft Azure DevOps が構成されると提供されます。 最後に、運用環境は、Microsoft との運用システムの準備状況チェック中に提供されます。 この環境は Lifecycle Services から要求する必要があります。

必要に応じて、第 1 層および第 2 層の環境に対して別のアドオン環境を追加することもできます。 第 1 層環境は、クラウド ホスト環境または環境イメージとして展開することもできます。 クラウド ホスト環境は、顧客またはパートナーによって管理されます。 環境イメージは、仮想ハード ディスクを使用するオンプレミス環境です。

必要な環境および必要なタイミングを選択できます。 必要な環境の一覧を Microsoft のマトリックスにまとめる必要があります。

環境計画を使用すると、すべての環境でコードをビルドするためのフローを選択したり、ALM を構成したりすることができます。

どの程度のテストが必要かについての計画

財務と運用アプリを実装する際は、開発を承認のためにテストする方法、テスト担当者、承認に使用する基準、テストの追跡方法を決定する必要があります。 システムのテストには、単体テスト、回帰テスト、パフォーマンス テストを使用できます。

単体テストは、機能の特定の一部が機能しているかどうかをテストするのに役立ちます。 単体テストでは、新しいコードがシステムの既存の機能に影響するかどうかはチェックされません。

回帰テストでは、プロセス全体に対してテストを実行し、既存の機能を新しい開発環境でも確実に機能させられることを確認します。 たとえば、顧客に関連する機能を追加する変更が行われた場合、新しい機能が販売注文などの既存機能に干渉しないように、回帰テストを実行する必要があります。

また、複数のユーザーにシステムに入って高負荷なプロセスを大量に実行してもらうことによってシステムのパフォーマンス テストを行い、システムの安定性を確認することもできます。 これにより、パフォーマンスを向上させる機会を特定できます。

財務と運用アプリには、ユーザーが行うプロセスのステップを文書化するためのタスク レコーダー ツールが含まれています。 Azure DevOps では、開発プロジェクト ソリューションにタスクをリンクすることもできます。 このタスクは、更新プログラム、ドキュメントのテスト、およびその他のメモを追跡するために使用できます。

開発者向けのソース管理と品質管理

場合によっては、複数の開発者が同時に財務と運用アプリで作業することがあります。 開発者が互いの作業に干渉しないように、Azure DevOps プロジェクトでソース管理を設定することができます。

このプロジェクトは、モデルのソースコードをホストし、これにより、ユーザーは、オブジェクトをチェックインまたはチェックアウトすることができます。オブジェクトをチェックアウトすると、変更を行っていることがシステムに対して通知されます。 オブジェクトをチェックインすると、そのオブジェクトの新しいバージョンが作成されます。

バージョン管理を使用すると、以前に行われた変更を確認できます。 保留中の変更を、最後にチェックインした変更に戻すことができます。 また、オブジェクトの 最新バージョンの取得 を選択して、オブジェクトの最新のチェックイン バージョンを取得することもできます。 この機能は、最新のコードを使用していることを確認するため、開発者が定期的に使用する必要があります。

開発の品質を確保するには、Microsoft Dynamics X++ のベスト プラクティスに従ってください。 また、すべての開発を組織全体で標準化するために、名前付け規則などの独自のベスト プラクティスを開発することもおすすめします。