Gitホスティングサービスではチケット管理が可能ですが、昔ながらのやり方のプロジェクトの場合、Azure Borads以外のチケットでは管理できる項目が不足しているため、Gitホスティングサービスとは別にプロジェクト管理ツールを導入したり、Excel管理したりすることがあります。
概要
Azure DevOpsではワークアイテムというチケットがあり、ワークアイテムは帳票自体をユーザが作成可能で、項目等のカスタマイズも可能です。そのため、Azure DevOpsで開発で管理が必要となる情報に合わせてワークアイテムを作成して管理を行います。
但し、GitLabやGitHubはそのような機能がないため、ラベルという機能を利用することで任意設定可能な項目を代替します。
例えば、以下のようなラベルを定義し、マージリクエスト(プルリクエスト)やイシューに設定することで、そのマージリクエストやイシューに情報を付与することができます。ラベルは任意で定義可能なので、開発で管理が必要となる情報に合わせて定義します。
GitLabはPremium版以上であれば::
で区切ることでスコープのラベルセットとして扱うことができますが、GitHubではセットとして扱うことはできません。
ラベル名 |
---|
a_分類::機能追加 |
a_分類::要件変更 |
a_分類::作業依頼 |
a_分類::バグ |
a_分類::タスク |
a_分類::問合せ |
a_分類::その他 |
b_ステータス::未着手 |
b_ステータス::対応中 |
b_ステータス::レビュー中 |
b_ステータス::承認済 |
b_ステータス::差し戻し |
b_ステータス::保留 |
c_優先度::高 |
c_優先度::中 |
c_優先度::低 |
d_グループ::GW |
d_グループ::UI |
d_グループ::基盤 |
d_グループ::運用 |
d_グループ::その他 |
e_環境::本番 |
e_環境::準本番 |
e_環境::テスト |
e_環境::開発 |
e_環境::机上 |
e_環境::その他 |
y_バグ事象::システムダウン |
y_バグ事象::異常終了 |
y_バグ事象::データ破壊 |
y_バグ事象::データ誤更新 |
y_バグ事象::一部機能障害 |
y_バグ事象::表記誤り |
y_バグ事象::その他 |
z_バグ原因::非エラー扱い |
z_バグ原因::設計もれ |
z_バグ原因::設計誤り |
z_バグ原因::説明内容不明確 |
z_バグ原因::再利用誤り |
z_バグ原因::データバリエーション |
z_バグ原因::コーディング誤り |
z_バグ原因::環境のバグ |
z_バグ原因::その他 |
バージョン管理システム別の管理方法
GitLab
レビュー時にコメントがある場合にはマージリクエストにコメントを追記しますが、どういった種類のエラーか分からないため、上記のzx_バグ原因
のようなラベルを定義し、コメントにエラー種類を設定することでエラー種類を管理することが可能です。設定はレビュー者が実施します。
GitLabからAPIで情報を取得・加工することで、イシューやマージリクエストのステータスとレビュー時のコメントを取得することが可能です。
尚、BIツールやスクリプト、Excelマクロ等色々方法はありますが、プロジェクト要件にあわせて作成が必要となります。
GitHub
GitLabではコメントごとにラベル設定が可能でしたが、GitHubではその機能がないため、プルリクエスト内で出たすべてのエラーをプルリクエスト自体に設定することでレビュー時に出たエラーの管理が可能です。
GitLabと同じようにAPIで情報を取得・加工することで、イシューやプルリクエストのステータスとレビュー時のコメントを取得することが可能です。
尚、BIツールやスクリプト、Excelマクロ等色々方法はありますが、プロジェクト要件にあわせて作成が必要となります。
Azure Boards
Azure DevOpsではワークアイテムを任意の種類を作成することが可能であるため、例えばレビュー
のようなワークアイテムを作成することが可能です。
そのレビュー
のワークアイテムではプロジェクトとして管理をしたい項目を管理するように設計し、そのワークアイテムをプルリクエストに紐づけることでレビュー結果の確認が可能となります。
Azure DevOpsではクエリで抽出したい条件で集計することが可能。
尚、Self-ManagedのAzure DevOpsの場合にはSQL Server Analysis Servicesが使用可能であり、様々な品質管理のレポートを取得することが可能。