Redmine運用例part3～OpenPNE3

Redmine.JP | Redmine on Twitterで、OpenPNE3が何故Trac＋SVNからRedmine＋Gitへ変更したのか、その理由と運用例が書かれていたのでメモ。
内容がとても素晴らしいので、共有する為に書く。
#下記は僕の想像の部分も含む。

【元ネタ】
【提案】OpenPNE3 の BTS と SCM を Trac + SVN から Redmine + Git に変更する ([Suggestion] Switch the BTS and the SCM that are used for OpenPNE3, from Trac + SVN to Redmine + Git) - openpne-dev | Google グループ

OpenPNE 3 - Ticket Workflow (ja) - OpenPNE Issue Tracking System

OpenPNE 3 - How To Report Issue (ja) - OpenPNE Issue Tracking System

バックポートとは 【backport】 - 意味/解説/説明/定義 ： IT用語辞典

【提案】OpenPNE3 の BTS と SCM を Trac + SVN から Redmine + Git に変更する ([Suggestion] Switch the BTS and the SCM that are used for OpenPNE3, from Trac + SVN to Redmine + Git) - openpne-dev | Google グループの内容を整理すると、下記になる。

【1】Tracの問題点

(引用開始)
a. 多くの情報が OpenPNE2 向けのものであり、その大半が OpenPNE3 に適合していない

b. 情報が OpenPNE2 向けなのか OpenPNE3 向けなのかが判別できない

c. ドキュメントが多くなりすぎて管理できておらず、現状に追いついていない誤った情報であることが多い

d. チケットのキーワードに「確認中」「テスト待ち」などのステータスを設定し、進捗を把握しているが、独自の方法であり、外から見て状況を把握できなかったり、新規参加者が適切に使用できるようになるまで時間を要する

e. 複数のバージョンにまたがるチケットは、まず、現安定版の対応バージョンをマイルストンに設定し、その後、旧安定版、開発版の順でキーワードに対応バージョンを指定している。独自のレポートを用いてなんとか管理しているが、ルールが複雑でわかりにくい

f. e のような管理をおこなっている関係で、開発の進捗がロードマップから追えない（ロードマップに記録されるチケットはマイルストンにそのバージョンが指定されている物に限られるため）

g. チケットやレポートなどが全プロジェクトで共用である。そのため、ドキュメントやプラグインに関するタスクが OpenPNE3 本体のものと混在してしまい、扱いにくい

h. 標準で Subversion 以外の SCM を扱えず、それ以外の SCM で開発されているプラグインなどの管理がおこなえない

i. リモートのリポジトリの管理ができず、 GitHub など外部のリポジトリで開発されているプラグインなどの管理ができない
(引用終了)

要約すると、下記の問題点があったと言えるだろう。

1-1・旧来のTracでは情報集約できてない。
1-2・チケットのステータスを増やせないので、複雑なワークフローに対処できない。
1-3・Tracのバージョンとマイルストーン、ロードマップの機能だけでは、複数のブランチのタスク管理がやりにくい。
1-4・SVN以外のSCM(例：Git)が使えない。リモートのSCMリポジトリが扱えない。

【2】SVNの問題点

(引用開始)
A. 気軽に fork ができず、 fork 先での改善を fork 元にインポートするのは困難である

B. プラグイン開発などの途中で OpenPNE3 本体に問題を見つけた場合、コミット権限がなければ容易にフィードバックができない

C. すべてのコミットは公開されることを前提にしなければならない。たとえば実験的なコードの中に暫定的に生のパスワードを入れる必要があった場合、その実験段階のコードはコミットできないまま大きく膨れあがっていくという危険な状態になる

D. コミットの際に、元のコードの作者と取り込んだ作業者との区別が付けられず、すべて作業者の名前でコミットされてしまう

E. インターネットにつながっていなければコミットがおこなえない

F. リポジトリのサーバがダウンしていた場合にコミットがおこなえない
(引用終了)

要約すると、下記の問題点があったと言えるだろう。

2-1・気軽にタスクブランチやトピックブランチで実験(ハック)する事がやりにくい。
2-2・パッチを作っても、コミット権限が無いのでテストできず、フィードバックしにくい。
2-3・パッチ作成者とマージした人の区別が付かないので、作業履歴が分かりにくい

当然、Gitならば、上記の問題点を全て解決できる。

【3】Redmine導入による解決方法

(引用開始)
a, b, c・Redmineへ変更すれば解決できる

d・独自にチケットのステータスを作成できる

g・プロジェクトがウェブから複数作成でき、それぞれにチケットやレポートを作ることができるほか、チケットを他プロジェクトのチケットと関連づけることもできる

h・SVN, CVS, Git, Mercurial, Bazaar, Darcs などをサポートしている

i・リモートのリポジトリを扱える

e と f・現状の運用を、「開発版で対処してからバックポート用のチケットで取り込み作業をおこなう」という形に変更する
(引用終了)

要約すると、Redmineで下記のように解決する。

3-1・Redmineの複数プロジェクト機能などを使って、情報を整理する。
3-2・想定されるワークフローごとにステータスを追加する。
3-3・Redmineの複数プロジェクト機能を使って、ブランチのタスク管理を分ける。
　チケットに必ずリリース予定バージョンを付与すれば、バージョンをイテレーションと見なせば、機能拡張を小刻みにリリースできる。
　Redmineのロードマップは、バージョンをリリース後、変更履歴として自然に表示できる。
　更にや他のチケット集計機能を使えば、進捗や作業状態がリアルタイムに分かる。
3-4・当然、GitもMercurialなども使える。SVNならリモートもOK。

興味深いのはOpenPNE 3 - Ticket Workflow (ja) - OpenPNE Issue Tracking Systemにあるワークフローだ。

ステータスには「レビュー待ち」「テスト待ち」があるので、コードレビューやテストの作業担当者がきちんとアサインされていると推測される。
つまり、開発者とレビューイやテスターが別人なので、自然にオンラインのペアプロのような作業になる。
故に、二人の目による品質チェックが有効に効いているはず。

また、終了ステータスに「再現せず」「無効」「対応せず」という別のステータスがあるのも注意。
Bugzillaでもこれらのステータスは存在しているが、これらはRedmineのデフォルトステータスの「却下」に相当する。
つまり、別の理由で対処せずに完了にした事を意味する。
実際のバグ修正では、確かにバグもあろうが、再現できないバグのチケットはある一定期間が経ったら却下(再現できない・対応せず)する時もあるだろう。
あるいは、報告者がバグと報告しても、そのバグは仕様通りです、と却下(無効)する時もあるだろう。

ステータスを細かく分類しておけば、Redmineのサマリ欄でステータスごとのチケット数が表示されるので、リリース後に分析資料として使える。

又、トラッカー(ワークフロー)は、バグ・改善・バックポートの3種類がある。
「バックポート」という言葉は初めて知った(恥)

バックポートとは 【backport】 - 意味/解説/説明/定義 ： IT用語辞典によれば「新しい機能などを古いソフトウェアに移植すること」。
例えば、trunkやタスクブランチなどで修正したパッチをリリースブランチにマージする作業をバックポートと呼んでいるのだろうと推測される。

普通は、リリースブランチ上で障害修正を施せば、必ずturnkにマージ作業が発生する。
しかし、セキュリティパッチなど安定性に関するバグ修正は逆に、trunkのような最新機能を持つコードラインからリリースブランチへマージされる時もあるのだろう。

その場合、「開発版で対処してからバックポート用のチケットで取り込み作業をおこなう」ワークフローなので、下記のタスク管理を行っていると推測される。

開発ブランチのチケットとリリースブランチにあるバックポート用のチケットを相互リンクしておく。
↓
開発ブランチのチケットは終了ステータス
↓
開発ブランチのチケットにあるリビジョンからパッチを作成
↓
リリースブランチへ上記パッチを取り込む
↓
古いバージョンでも動くように当然テストして、バグがあれば修正
↓
バックポート用のチケットにパッチ取込のリビジョンが紐づけられる
↓
レビューやテストが終われば、バックポート用のチケットも終了ステータスへ更新

つまり、各ブランチ間のタスクやマージ作業をチケットで管理することによって、作業漏れをなくす。
この手法によって、複数ブランチによる並行開発のタスク管理が非常にスムーズになる。

上記の運用ルールを読む限り、最近の開発スタイルに合った良い例だと思う。
今後、「Trac＋SVN」から「Redmine＋Git(Mercurial)」へタスク管理や構成管理を入れ替える運用例は増えるだろうと思う。