Redmine Commit Relation Editor Pluginで変更管理を強化する
@haru_iidaさんがRedmine Commit Relation Editor Pluginという有用なプラグインをリリースされたのでメモ。
【元ネタ】
Haru's blog: Redmine Commit Relation Editor Plugin 0.0.1をリリースしました。
r-labs - Commit Relation Editor - Redmine
(引用開始)
Redmineではリポジトリのコミットメッセージにチケット番号を入力することでコミットとチケットの関連付けを行うことができます。チケット駆動開発の合言葉「No ticket, No commit」が示すようにこの関連付けは非常に重要です。
しかしコミットメッセージに入力するチケット番号を間違えたり、番号を入れ忘れたりすると後から関連付けを修正することができず悲しい思いをします。
このプラグインを使用するとリポジトリブラウザ上から新たにチケットを関連付けたり既存の関連付けを削除したりできるようになります。
(引用終了)
チケット駆動開発の発端となった運用ルールである「No ticket, No commit」を実践する場合、コミットログに「refs #12」「fixes #23」のようにチケットNoを書くようにする。
しかし、チケットNoを誤って書いたり、#を大文字で書いたり、間違える時がある。
すると、せっかくの変更履歴が本来のチケットとリンクしなくなる弱点があった。
現状は、チケットに本来のリビジョンを「r123」のように書いてチケット画面からリンクするする手法しかフォローすることができなかった。
だが、上記のプラグインのおかげで、間違ったチケットNoでコミットログを書いても、後から修正できるようになる。
そうすれば、チケットとバージョン管理のリビジョンを本来のあるべき姿でリンクさせることができるから、トレーサビリティを強化することができる。
このトレーサビリティという概念は最終的には変更管理プロセスを補強することにつながる。
何故なら、例えば、何故こんな汚いパッチを当てたのか、何故本来の要件がこんな複雑な仕様になってしまったのか、という変更履歴をチケットと成果物の修正履歴から辿ることができるからだ。
その作業によって、例えば、今回のバグ修正では過去のパッチを安易に修正してはいけない、とか、技術上の制約から本来の要件が現在の仕様に変わったので今回の仕様変更も同様に考慮する必要がある、などと言った判断を自信を持って説明することができる。
アジャイル開発では、頻繁なリファクタリングと小刻みな機能改善を同時並行で開発しているので、ソースはどんどん成長して変化していく。
だから、Git/Mercurialで並行開発をサポートするだけでなく、RedmineやTracで変更履歴を後から調査しやすくする環境を作ることはとても重要だと思う。
| 固定リンク
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント