Redmine1.4におけるNo Ticket, No Commitの強化
Redmine1.4の機能改善において、No Ticket, No Commitの強化につながる機能があったのでメモ。
【元ネタ】
Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog
Twitter / @mkinside82: Commit Relation Editor - Plugins - Redmine
チケット駆動開発の基本ルールは@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の機能はまだまだ進化する余地がたくさんあるように思う。
| 固定リンク
「Redmine」カテゴリの記事
- AstahのRedmine連携プラグインが公開されました(2018.01.18)
- 複数Redmineの内容を一つのRedmineに集約して見る方法(2018.03.16)
- RedmineもOSLC規格を導入してトレーサビリティを強化すべきか(2018.03.12)
- Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化(2017.11.30)
- ステルス駆動開発でRedmineを浸透させるアイデア(2018.03.09)
「チケット駆動開発」カテゴリの記事
- 第18回Redmine大阪の感想 #RedmineOsaka(2018.02.04)
- 気象庁の数値予報課におけるRedmine利用事例(2017.05.22)
- チケット駆動の罠~複雑さはチケットの粒度に関連している(2016.12.28)
- Redmineのアンチパターンは2種類に区別できるのではないか(2018.02.21)
- 第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT(2017.11.19)
コメント