ソース、バグ、品質の追跡可能性を設計して実装する
DevOps のコンテキストでは、追跡可能性とは、ソフトウェア開発ライフサイクル全体の変更とアクションを追跡する機能を指します。 この概念は、ソース コードの変更、バグ解決、品質管理の維持など、そのライフサイクルのさまざまな側面に適用されます。 これを実装することは、製品の信頼性、保守容易性、および顧客満足度を確保するために不可欠です。
ソースの追跡可能性により、開発者はコラボレーション シナリオでのコード変更を追跡できます。 バグの追跡可能性により、ソース コードに関する問題の特定、優先順位付け、および解決が容易になります。 品質の追跡可能性により、テスト アクティビティ、メトリック、フィードバックを開発作業にリンクすることで、ソフトウェアが品質基準とユーザーの期待を満たすことが保証されます。
デザイン
大まかに言えば、追跡可能性はツールに依存しませんが、それに取り組む方法は、目指そうとするソフトウェア開発ライフサイクルの側面によって異なります。 同様に、目的と設計に関する考慮事項は、ソース コード、バグ、品質の追跡可能性によって異なります。
特に、ソースの追跡可能性には、変更を行ったユーザー、変更日時、変更の目的など、コード変更の履歴を追跡する必要があります。 これにより、コード レビュー、デバッグ、および時間の経過に伴うコードベースの進化の理解が促進されます。 この機能は、設計の観点から、開発作業を整理する Git のブランチ戦略およびマージ戦略と密接に結び付いています。 開発者は、新しい作業用の機能ブランチを作成し、ブランチに変更をコミットし、レビューのために pull request を送信します。 その時点で、同僚たちはコード レビューを実施し、正常に完了したら、変更をメイン ブランチにマージすることを承認します。
バグの追跡可能性には、テスト中または運用環境で報告されたバグや欠陥をコードベースの根本原因まで遡ることが含まれます。 また、一般に、バグ レポートの詳細、再現手順、影響を受けるコンポーネント、関連するコード変更などの情報を把握することにも依存します。 これの目標には、ソフトウェアの欠陥に対処するために、バグの優先順位付けと効率的な解決が含まれます。
品質の追跡可能性には、ソフトウェア開発プロセス全体にわたる品質関連のアクティビティと成果物のトレースが含まれます。 これには、品質メトリック、テスト ケース、テスト結果、およびその他の品質保証アクティビティを要件、ユーザー ストーリー、およびコード変更にリンクすることが含まれます。 品質の追跡可能性は、ソフトウェアの変更が品質に与える影響を評価し、改善の領域を特定するのに役立ちます。
追跡可能性の実装
追跡可能性の実装の詳細は、DevOps プラットフォームによってある程度異なります。
ソースの追跡可能性
GitHub と Azure DevOps の両方がソース管理メカニズムとして Git をサポートしているため、多くのソースの追跡可能性手法がこれらの両方に適用されます。 その結果、どちらの場合も、ソース コードの追跡可能性を実装するには、説明的なコミット メッセージの記述、明確に定義されたブランチ戦略の使用、コード レビューの pull request の要求などのベスト プラクティスを採用する必要があります。
ただし、これらにはいくつか違いもあります。 通常 GitHub リポジトリにソースの追跡可能性を実装するには、ブランチ保護規則などの機能を使用してコード レビュー プロセスを適用し、マージ前に変更が確実にレビューされるようにする必要があります。 GitHub と Issues の統合により、コードの変更を対応する問題にリンクでき、コードの変更とプロジェクトの要件の間の追跡可能性が提供されます。 Azure DevOps には、コード品質チェックを適用し、変更を作業項目にリンクするためのブランチ ポリシーと pull request ポリシーが用意されています。これにより、コードの変更とユーザー ストーリーまたはタスク間での追跡可能性が可能になります。 さらに、Azure DevOps は作業項目追跡システムとのより広範な統合を提供し、GitHub の問題追跡に比べて、より詳細な追跡可能性とレポート機能を実現します。
バグの追跡可能性
Azure DevOps では、バグの追跡可能性は Azure Boards を通じて容易になり、バグは作業項目として追跡され、コードの変更、コミット、pull request にリンクできます。 Azure Boards では、バグ管理用のカスタム ワークフローを作成し、New、Active、Resolved、Closed などの状態を定義して、バグのライフサイクルを可視化できます。 さらに、Azure DevOps では、バグとその他の作業項目との間の豊富な統合が提供され、バグとユーザー ストーリー、タスク、エピックの間の追跡可能性が可能になります。
GitHub では、バグの追跡可能性は、問題とコード変更の統合に依存します。ここで、問題として報告されたバグはコミットと pull request にリンクできます。 GitHub Actions では、バグの追跡可能性に関連するものを含め、カスタマイズ可能なワークフローを実装する機能が提供されます。 GitHub Actions を使用すると、問題の作成や変更など、GitHub リポジトリ内のイベントによってトリガーされるプロセスを自動化するワークフローを定義できます。 これにより、状態の定義、タスクの割り当て、特定の条件に基づくアクションの自動化など、バグを管理するためのカスタム ワークフローを作成できます。 実質的に、GitHub Actions はワークフローの自動化に柔軟性を提供しますが、通常、Azure DevOps の Azure Boards の組み込み機能と比較して、より多くの労力とカスタマイズが必要です。
品質の追跡可能性
Azure DevOps では、テスト計画を使用して品質の追跡可能性を管理できます。これにより、チームはテスト ケースを整理、実行、追跡できます。 テスト計画では、テスト ケースの合格率、テストの実行結果、テスト カバレッジ レポートなど、包括的な品質メトリックが提供されます。 さらに、Azure DevOps には、テスト カバレッジを測定し、追加のテストを必要とするコードベースの領域を特定するためのコード カバレッジ ツールとの統合が用意されています。
GitHub には GitHub Actions を通じて同様の機能が用意されており、チームは単体テスト、統合テスト、エンドツーエンド テストなど、さまざまな種類のテストを自動化できます。 ここでも、GitHub Actions はテスト ワークフローの設定やサードパーティのテスト ツールとの統合に柔軟性を提供しますが、Azure DevOps テスト計画と同じレベルの包括的な品質メトリックとテスト カバレッジ レポートを実現するためには、追加の構成が必要になる傾向があります。