ツールとプロセスを標準化するためのレコメンデーション
この Power Platform Well-Architected Operational Excellenceチェックリストの推奨事項に適用されます:
| 04 ... | 業界で実績のある Development and test のプラクティスに従って、ソフトウェア開発と品質保証のプロセスを最適化します。 あいまいでないロール指定を行うには、ツール、ソース管理、アプリケーション設計パターン、ドキュメント、スタイル ガイドなどのコンポーネント全体でプラクティスを標準化します。 |
|---|
このガイドでは、開発ツールとプロセスの標準を定義するためのレコメンデーションについて説明します。 一貫したプラクティスを定義すると、効率的なワークロード チームと質の高い作業が実現します。 パフォーマンスの高いチームは、業界で実証済みのツールとプロセスを使用して、無駄な労力と潜在的なコード エラーを最小限に抑えます。
主要な設計戦略
開発プラクティスを最適化するための最初のステップは、ツールとプロセスを標準化することです。 可能な限り、独自のソリューションを開発するのではなく、業界で実証済みのソリューションを使用してください。 すべての標準化されたツールとプロセスについて、チームが効率的に使用できるようにトレーニングを提供します。
開発プラクティスの最適化に役立つ標準を定義するには、次のレコメンデーションを考慮してください。
プラットフォームで利用可能なツールを使用する
Power Platform ツールの使用を優先し、それ以外の場合は既知の成熟した既製ツールを使用し、その使用を標準化します。 非常に効率的なエンジニアリング チームは、クラス最高のツールを採用しています。 計画、開発、テスト、コラボレーションのためのソリューションの開発は避けてください。 ワークロードの要件を満たすツールを選択します。
ツールは次の機能を提供する必要があります。
- 作業計画とバックログ管理
- バージョン管理とリポジトリ
- 展開パイプライン
- テスト中
- コード開発とレビュー
場合によっては、1 つのツールまたはツール スイートが複数の機能を提供することもあります。 ツールの機能とその制限を理解し、機能全体の要件を満たすようにしてください。
プラットフォームのプレミアム機能とツールのプレミアム バージョンのどちらに投資する必要があるかを判断します。 プレミアム ツールが提供する機能と比較して、独自のソリューションを開発する時間と労力を考慮してください。 一時的なコストと定期的なコストを考慮してください。 ほとんどの場合、既製のツールの方がチームに高い価値を提供します。 例えば、マネージド環境は、作成者のオンボード メッセージを設定したり、積極的に共有を制限したりできる既定の機能を提供します。 これらの機能を自分で構築するには、開発と継続的な メンテナンス の取り組みが必要であり、レベル上げ に投資するよりもコストがかかる可能性があります。
実用的な場合はAIツールを使用します。 AI ツールは、コードの開発、レビュー、最適化に役立ちます。
共同開発のためのガバナンスフレームワークを確立する
メーカー定義のプロジェクトと融合チームの一貫性と再現性を確保するために、効果的な共同開発ガバナンス フレームワークを確立します。
ソース管理システムとプラクティスを標準化する
Azure DevOps などのソース コード管理システムを採用します。 Azure DevOps サポート チームが作業を計画し、コード開発で協力し、アプリケーションを構築および展開するための開発者サービスを提供します。 アプリとカスタマイズを含む開発環境からソリューションをエクスポートし、ソリューションを展開して、コンポーネントをソース管理システムに保存します。
Azure BoardsでチームにScrumプラクティスを実装する に記載されているスプリントと開発者のガイドラインに従って、ソリューションのバージョン管理が正確であることを確認します。 プル リクエストからのテスト結果は、構築中の機能を示すスクリーンショットまたはビデオの形式を取ることができます。 pull request のガバナンス プロセスを自動化すると、ソリューションのバージョンなどの基本的なチェックを手動でレビューする必要がなく、コードの品質を確保できます。
効率性と一貫性を実現するためのテンプレートを作成します。 オンボーディング タスクやストーリー レビュー プレゼンテーションから、ユーザー ストーリー、機能、バグ、タスクを定義する際に時間を節約し、チームにガイダンスを提供するように設計された 作業項目テンプレート まで、チームの運用のあらゆる側面が標準化と簡素化の恩恵を受けます。
メトリックを評価して有効性を定量化する
開発チームと品質保証チームは、その有効性を定量化することでのみ改善できます。 有効性を定量化するには、開発者のベロシティを測定し、主要業績評価指標 (KPI) を定義するメトリックを特定する必要があります。
これらのメトリックの例には以下が含まれます。
- リードタイム: タスク またはユーザー ストーリーがバックログから本番環境への展開に移行するまでにかかる時間。
- 平均解決時間: コード内のバグや欠陥を修正するのにかかる平均時間。
- 変更失敗率: 失敗につながる変更の割合。
関係者とワークロード チームがベロシティを簡単に追跡できるように、ダッシュボードやその他のレポート ツールを使用して KPI を視覚化します。
ワークロード チームがコードを作成、レビュー、文書化する方法を標準化します
スタイル ガイドを使用して、ワークロード チームがコードを作成、レビュー、文書化する方法を標準化します。 標準スタイルによりコラボレーションが容易になり、新しい開発者の新人研修に役立ちます。 効率的に作業するために、新しい開発者はワークロード チームがどのように機能するかを知る必要があります。 明確に定義された基準を備えたスタイル ガイドを使用すると、トレーニング プロセスが容易になります。
スタイル ガイドには次の内容が含まれる必要があります。
- ソリューション、成果物、コントロール、アクション、環境、ブランチ、ビルドの名前付け規則
- エラー処理の基準
- 共通パターンまたはライブラリ
アーキテクチャの決定を追跡することで、チームがワークロードを常に最新の状態で把握し、新しいチーム メンバーがワークロードのライフ サイクル中に行われた設計上の決定について学習できるようになります。 アーキテクチャ決定ドキュメントには、検討されたツールとテクノロジー、決定の理由、決定の要素となった機能要件と非機能要件を含めます。 説明を繰り返したり、新しいメンバーや関係者との議論を再度行ったりすることを避けるために、決定事項を記録します。
技術的負債に対処するための基準とガイドラインを導入する
プラットフォームとテクノロジは急速に変化し、新しい機能が定期的に展開されます。 技術的負債はワークロード チームの成果物に必要であるという考え方を採用します。 この考え方により、チームは技術的負債の蓄積を避けるために定期的に技術的負債を検討し、対処するようになります。 バックログで定期的に繰り返されるタスクとして技術的負債に対処します。 プラットフォームの変更（新機能と廃止機能の両方）に常に対応するためのプロセスが確立されていることを確認し、ワークロードの変更に対処するためのアクション プランを作成します。
たとえば、製品の機能が廃止されたり、別のバージョンに置き換えられたりする場合があります。 ワークロード チームは、ワークロードに影響を与えないように、新しい機能への移行を完了することを優先する必要があります。 チームはカスタム ソリューションまたはコントロールを構築する可能性があり、時間が経つにつれてそれがプラットフォームの一部になります。 ワークロード チームはそのプラットフォーム機能に移行する必要があり、これにより技術的負債が軽減され、独自のワークロードの メンテナンス が軽減されます。
業界で実証済みのアプリケーション設計パターンを使用して、アプリケーションの信頼性、パフォーマンス、セキュリティを確保します。 アプリケーション用に独自のソリューションを開発するのではなく、これらのパターンを使用すると、時間と労力を節約できます。 ワークロードに利益をもたらすパターンを選択してください。 設計パターンを定期的にレビューして、ワークロードの進化に応じて適切なパターンを使用していることを確認します。
テストにシフトレフト アプローチを導入する
開発プロセス全体をとおして、ユニット テストを早期かつ頻繁に実行することで、テストにシフト レフト アプローチを実装します。 各開発環境で頻繁にテストを行うことで、開発者はアプリケーションに自信を持てるようになります。
シフトレフト アプローチでテスト戦略を作成するには、次の原則を考慮してください。
- 可能な限り最小レベルでテストを記述します。 外部依存関係が最も少ないテストを優先し、ビルドの一部としてテストを実行します。
- テストを一度記述すれば、本番環境を含むあらゆる場所でテストを実行できます。 暗号化されたシークレットや構成など、特定の環境に固有の要素を考慮せずに、あらゆる開発環境で実行できるテストを作成します。
- テスト用のワークロードを設計します。 アプリケーションを開発するときは、テスト容易性を要件にします。
- ワークロードの所有権に基づくテストの所有権を検討します。 ワークロード チームは独自のテストを所有しており、コードのテストを他のチームに依存すべきではありません。
- 可能な限りテストを自動化します。 自動化されたコードにより、ワークロード チームの負担が軽減され、一貫した品質が確保されます。
ワークロード チームに、開発と品質保証に関連するセキュリティ プラクティスを理解するよう要求します。 チームメンバーは例外なくこれらのプラクティスを 追従する する必要があります。 詳細については、 開発ライフサイクルのセキュリティ保護に関する推奨事項をご覧ください。
Power Platform の促進
パイプライン内のCopilotによって生成されたデプロイメント ノート は、ソリューションの概要を生成し、デプロイメント ノート フィールドを事前に入力します。これにより、デプロイメント リクエストまたはレコードを表示するすべてのユーザーが、ソリューションの機能と内容を理解するのに十分なコンテキストが得られます。
Microsoft Power Platform Build Tools for Azure DevOps を使用すると、 Power Platform で構築されたアプリに関連する一般的なビルドおよびデプロイメント タスクを自動化できます。
GitHub Actionsを使用すると、開発者は自動化されたソフトウェア開発ライフサイクル ワークフローを構築できます。 Power Platform Microsoft Power Platform の GitHub アクション を使用して、リポジトリにワークフローを作成して、アプリをビルド、テスト、パッケージ化、リリース、デプロイし、自動化を実行し、ボットやその他のコンポーネントを Power Platform 上で管理できます。
Power Apps チェッカーWeb API は、プラットフォームのカスタマイズと拡張機能に対して静的分析チェックを実行するメカニズムを提供します。 Microsoft Dataverse
Test Studio を使用すると、キャンバス アプリのエンドツーエンドのUIテストを構築できます。
Power CATコードレビュー ツール を使用すると、コードレビューを実行できます。
Power CAT Copilot Studio キット を使用すると、副操縦士とテストを構成できます。 Copilot Studio API (Direct Line) に対して個別のテストを実行することにより、副操縦士の応答が予想される結果に対して評価されます。
ALM Accelerator は、継続的インテグレーション/継続的デリバリー プロセスを自動化するために設計された一連のアプリケーション、スクリプト、パイプラインで構成されるオープン ソース ツールです。
Microsoft Power Platform CLI (PAC CLI) は、ソリューションのインポートとエクスポート、およびソリューション ソース ファイルへのパックとアンパックをサポートするコマンド ライン ツールです。 Power Platform Power Platform PAC CLIは、 スタンドアロンのコマンドライン ツール として、または コードの拡張機能 Visual Studio として利用できます。
開発手法の標準化に役立つその他のツールとサービスには、次のものがあります。
Azure DevOpsは、共同作業による効率的で一貫性のある開発手法を構築するために使用できるサービスのコレクションです。 Azure DevOps は、次のソリューションをバンドリングします。
- Azure Pipelines は、アプリケーションのCI/CDをサポートするビルドおよびリリース サービスを提供するクラウド サービスです。
- Azure Boards は、ScrumやKanbanなどのAgileプラクティスをサポートするWebベースの作業管理ツールです。
- Azure Repos は、Git分散バージョン管理システムとTeam Foundationバージョン管理システムをサポートするバージョン管理ツールです。
- Azure Test Plans は、計画された手動テスト、ユーザー受け入れテスト、探索的テスト、および関係者からのフィードバックの収集に必要な機能を提供するブラウザーベースのテスト管理ソリューションです。
GitHubプロジェクト は、カンバン ボード、レポート、ダッシュボード、その他の機能を作成するために使用できる作業管理ツールです。