ビルド、テスト、および品質テストの各プロセスの計画
このユニットでは、ビルド、テスト、品質テストプロセスを管理するのに使用できる開発プロセスについて説明します。 さらに、これらのプロセスを管理するための計画方法についても説明します。
ビルドのプロジェクト計画の作成
選択した方法に応じて、ビルドの時間と場所を選択する必要があります。 また、どの順序でビルドを実行するかを決定する必要があります。 たとえば、最初にテスト環境を実行せずに、開発環境から実稼働環境にコードをビルドすることは望ましくありません。
また、開発をロールバックする必要があるためにテストを通過しなかった開発をどう処理するかについても検討する必要があります。 このアプローチにより、エラーの発生を防ぐことができます。 Microsoft Dynamics 365 Lifecycle Services を使用すると、環境から環境へのビルドの管理に役立てることができます。
たとえば、ビルドでは、エラーが発生したコードをテスト環境から開発環境にロールバックし、テストを通過したコードをテストから実稼働環境に昇格させた後、最終的に完了したコードを開発環境からテストに昇格させることができます。
必要な環境を決定する
環境の選択は、実装の開始時に計画する必要があります。 環境を計画する際、次を行う必要があります。
- 環境の目的を決定する。 環境を開発、システム テスト、ユーザー受け入れテスト (UAT)、または操作のいずれで使用する予定かを検討する。
- 開発、ビルドおよびテストなどの環境トポロジを考慮する。
- 環境階層 (第 1 層または第 2 層) を考慮する。
第 1 層環境とは、すべてのコンポーネントが同じサーバーにインストールされた単一ボックス環境のことです。 第 1 層環境は Microsoft SQL Server を使用しており、開発の効率を高めるために構造化されています。 この層は、UAT またはパフォーマンス テストには適切ではありません。
第 2 層またはそれ以上の環境は、複数のサーバーにコンポーネントがインストールされた複数ボックス環境です。 第 2 層では、Microsoft SQL Server の代わりに Microsoft Azure SQL Database を使用します。 この環境では運用環境と同じアーキテクチャが使用されますが、ディザスター リカバリーは使用されません。 この環境は、UAT およびパフォーマンス テストに使用する必要があります。
環境向けの標準クラウド オファーには、開発とテストのための第 1 層環境、UAT のための第 2 層環境、および運用環境が含まれます。 システムでは、これらの環境がそれぞれ異なるタイミングで提供されます。
- 第 2 層環境 - インストール プロセス中。
- 第 1 層開発およびテスト環境 - 設計フェーズが開始され、Microsoft Azure DevOps を構成した後。
- 運用環境 - Microsoft との運用システムの準備状況チェック中。 この環境は Lifecycle Services から要求する必要があります。
必要に応じて、第 1 層および第 2 層の環境に対して別のアドオン環境を追加することもできます。 加えて、第 1 層環境は、クラウド ホスト環境または環境イメージとして展開できます。 クラウド ホスト環境は、顧客またはパートナーが管理します。 環境イメージは、仮想ハード ディスクを使用するオンプレミスの環境です。
必要な環境および必要なタイミングを選択できます。 必要な環境の一覧を Microsoft のマトリックスにまとめる必要があります。
環境計画を使用すると、すべての環境でコードをビルドするためのフローを選択したり、ALM を構成したりすることができます。
どの程度のテストが必要かについての計画
財務と運用アプリを実装する際は、開発を承認のためにテストする方法、テスト担当者、承認に使用する基準、テストの追跡方法を決定する必要があります。 システムのテストには、単体テスト、回帰テスト、パフォーマンス テストを使用できます。
単体テストは、機能の特定の一部が機能しているかどうかをテストするのに役立ちます。 単体テストでは、新しいコードがシステムの既存の機能に影響するかどうかはチェックされません。
回帰テストでは、プロセス全体に対してテストを実行し、既存の機能を新しい開発環境でも確実に機能させられることを確認します。 たとえば、顧客に関連する機能を追加する変更が行われた場合、新しい機能が販売注文などの既存機能に干渉しないように、回帰テストを実行する必要があります。
さらに、システムが安定していることを確認するため、システムのパフォーマンス テストを検討することもできます。 これを行うには、複数のユーザーがシステムに入り、大量の課税プロセスを実行する必要があります。 このアプローチにより、パフォーマンスを向上させる機会を特定できます。
財務と運用アプリには、ユーザーが行うプロセスのステップを文書化するためのタスク レコーダー ツールが含まれています。 Microsoft Azure DevOps では、開発プロジェクト ソリューションにタスクをリンクすることができます。 その後、そのタスクを使用して、更新プログラム、ドキュメントのテスト、およびその他のメモを追跡することができます。
開発者向けのソース管理と品質テスト
場合によっては、複数の開発者が同時に財務と運用アプリで作業することがあります。 開発者が互いの作業に干渉しないように、Azure DevOps プロジェクトでソース管理を設定することができます。
Azure DevOps プロジェクトは、モデルのソースコードをホストし、これにより、ユーザーは、オブジェクトをチェックインまたはチェックアウトすることができます。オブジェクトをチェックアウトすると、変更を行っていることがシステムに対して通知されます。 オブジェクトをチェックインすると、そのオブジェクトの新しいバージョンが作成されます。
バージョン管理を使用すると、ユーザーが行った以前の変更を確認することができます。 保留中の変更を、最後にチェックインした変更に戻すことができます。 また、オブジェクトの 最新バージョンの取得 を選択して、オブジェクトの最新のチェックイン バージョンを取得することもできます。 開発者は、最新のコードを使用していることを確認するため、この機能を定期的に使用する必要があります。
開発の品質を確保するには、Microsoft Dynamics 365 X++ のベスト プラクティスに従ってください。 また、すべての開発を組織全体で標準化するために、名前付け規則などの独自のベスト プラクティスを開発することもお勧めします。
バージョン管理システムの選択
財務と運用アプリでは、バージョン管理システムは必須です。 Azure DevOps は、Team Foundation バージョン管理 (TFVC) と Git をサポートしています。
Azure DevOps Team Foundation バージョン管理
Azure DevOps Team Foundation バージョン管理システムは、財務と運用アプリ用バージョン管理システムの 1 つです。 開発者が 1 つのブランチで作業し、開発マシンで各ファイルの 1 つのバージョンを使用する、集中型バージョン管理システムです。 各ブランチはサーバー ワークスペースに属し、各開発者はローカル ワークスペースで作業します。 開発者はソース コードをチェックインする際に、最新バージョンをチェックインして既存の競合を解決する必要があります。
既定では、TFVC リポジトリは Azure DevOps の組織の設定領域で非アクティブ化されています。 TFVC をバージョン管理システムとして使用して新しい Azure DevOps プロジェクトを作成するには、リポジトリをアクティブ化する必要があります。
組織で Team Foundation バージョン管理 (TFVC) をアクティブかするには、次の手順に従います。
- dev.azure.com/<組織> に移動して Azure DevOps を開きます。
- ダッシュボードの左下隅にある 組織の設定 を選択します。
- Repos > リポジトリ を選択します。
- すべてのリポジトリ設定 セクションで TFVC リポジトリの作成を無効にする トグルをオフにします。
TFVC をバージョン管理システムとして使用する新しい Azure DevOps プロジェクトを作成できます。
Git
Git は、開発に推奨される Microsoft の既定のバージョン管理システムです。
TFVC は集中型バージョン管理システムですが、Git は分散型システムです。 各開発者は、ソース リポジトリ (またはライトウェイト ブランチ) の自分用のコピーを持ち、変更をそのリポジトリにコミットできます。 開発者は、新しいプライベート ブランチを作成し、別のブランチに切り替えることができます。 TFVC のほうがブランチ間の切り替えが困難で、複数の開発環境が必要になることがよくあります。
TFVC から Git への移行や、その逆ができることを知っておくことが重要です。