Redmine1.4におけるNo Ticket, No Commitの強化

Redmine1.4の機能改善において、No Ticket, No Commitの強化につながる機能があったのでメモ。

【元ネタ】
Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog

Twitter / @mkinside82: ほんとにCommit Relation Editor Pluginそっくりですね/Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog

Twitter / @mkinside82: Commit Relation Editor - Plugins - Redmine

Twitter / @mkinside82: @akipii もともとチケットが上がっていたようですね ⇒ http://bit.ly/HPLVM5 @haru_iida さんのCommit Relation Editor プラグインを使わさせて頂いてるのでUIがそっくりなのに驚きましたw

チケット駆動開発の基本ルールは@machuさんが提唱された「No Ticket, No Commit」にある。
この運用ルールは本来、障害管理において、どの障害に対してソースの修正がなされたのか、その修正履歴とバグチケットを紐づける運用から生まれた。
そこから、「チケット無しでソースのコミット不可」の運用ルールとなり、チケット駆動開発では、成果物の変更があったら必ずチケットに作業履歴を残す運用へ発展していく。
つまり、「No Ticket, No Commit」は成果物の変更のトレーサビリティを保証してくれる非常に重要な運用ルール。
この運用ルールがあるからこそ、開発者は変更管理を意識しなくても、変更管理を厳格に運用できる。

しかし、コミット時にチケットのNoを間違えたり、他のチケットNoも追加したくなる場合は多い。
GitやMercurialがコミット履歴の改変を行える方向へ進化したように、チケットとソースの紐づけも後から修正できるようにしたいと思うのはとても自然だ。
Mercurialの黒魔術: プログラマの思索でも書いたように、マージ作業のUndoやRedoができるればマージ作業の修正ミスを恐れることなくマージ作業ができる。
同様に、チケットと成果物のトレーサビリティの保証も、RedoやUndoができれば、BTSにたまったチケットのデータを保守することで、意味ある作業情報を蓄積できるようになる。

既に@haru_iidaさんが Commit Relation Editor pluginを公開されていたが、その機能とRedmine本家の機能がほとんど同じらしい。
記事を読む限り、画面UIはとても使いやすそうだ。

こういう細かい機能改善が積み重なることによって、ツールが使いやすくなるだけでなく、ソフトウェア開発のベストプラクティスがツールの1機能として実現されていくのだろう。
それによって、ツールの運用に慣れれば、自然にソフトウェア開発の良い習慣が身につくようになるのだろう。
更に、世の中の問題をできるだけソフトウェアで解決できる問題へ変換することによって、プログラマが活躍できる場が増えていくのだろう。

Redmineの機能はまだまだ進化する余地がたくさんあるように思う。