ReviewBoardとMercurial+TiDDは相性が良い?
Mercurialによるチケット駆動開発の仕組みがコードレビューのプロセスに似ているアイデアをメモ。
#ラフなメモ書き。
【元ネタ】
ReviewBoard | Documentation | General Workflow
Mercurialによるチケット駆動開発は強力だ!: プログラマの思索
コードレビューWebシステムReviewBoardには、「pre-commit review」「post-commit review」の2種類のやり方がある。
ReviewBoardは「pre-commit review」の考え方で作られている。
つまり、改変したコードをtrunkにコミットする前にレビューを受けるプロセス。
多分、オープンソースの開発ではよく使われているコードレビュー手法だと思う。
開発者は、SVNなどでdiffを作り、ReviewBoardリクエストに登録し、レビューアのレビューを受ける。
つまり、trunkにすぐにコミットせず、自分のローカルに修正パッチを保持し、レビューアの指摘を反映して、OKが出たら、trunkへ初めてコミットできる。
このやり方は、trunkに中途半端なソースをコミットしないための運用ルール。
「post-commit review」は、改変したソースをtrunkとは別ブランチに作り、レビューを受けるプロセス。
「post-commit review」のレビュー方法は、Mercurial+TiDDでもっと簡単になるはず。
そのアイデアをまとめてみた。
つまり、チケット単位にMercurialのトピックブランチを作り、担当者はトピックブランチでガンガン開発する。
そして、ソース修正が終われば、チケットを解決ステータスにし、ReviewBoardリクエストへ登録してレビューを依頼する。
この時、ReviewBoardリクエストとRedmineチケットを相互リンクさせておく。
そして、レビューアの指摘を受けてMercurialのトピックブランチ上で修正し、レビューOKが出たら、初めてtrunkへpushする。
MercurialやGitならば、トピックブランチの管理が簡単で、trunkから最新機能を随時pullすればいい。
当然このやり方でも、trunkに中途半端なソースはマージされないので、trunkの品質は保たれる。
ReviewBoard上のコードレビューはRedmineチケットと紐づいているため、Redmineのワークフロー管理機能を使って、レビュー用プロセスを容易に管理できる。
もちろん、進捗管理も可能だ。
おそらく、コードレビューが重要と誰もが知っているのに実プロジェクトで運用できない原因は、分散バージョン管理のようなインフラがない為にソースの品質管理が難しく、ReviewBoard+TiDDのようなインフラがない為にコードレビューをワークフロー管理するプロセスが曖昧だからだろう。
Mercurial、TestLink、Hudsonなどのツールと連携したチケット駆動開発には色んな可能性を感じている。
ツールを駆使して、SW開発の生産性を上げてプロセス改善していくやり方は、もっと研究されていい気がする。
| 固定リンク
「Mercurial」カテゴリの記事
- ソフトウェア開発の諸問題はソフトウェアで解決する(2009.09.24)
- Mercurial以前と以後のチケット駆動開発(2009.12.15)
- ReviewBoardとMercurial+TiDDは相性が良い?(2009.12.09)
- Mercurialによるチケット駆動開発は強力だ!(2009.12.08)
- 【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較~TiDDに必要な必須機能」(2009.09.12)
「チケット駆動開発」カテゴリの記事
- ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか(2015.07.18)
- 第19回Redmine大阪の見所 #redmineosaka(2019.01.26)
- Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影(2016.02.10)
- 大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響(2016.06.19)
- チケット駆動開発のアイデアがRedmineへ与えた影響は何か(2018.12.10)
コメント