プログラマの思索

RedmineとGitを巡る疑問点をメモ。
詳細は後で書き足す。

【参考】
チケット駆動開発に分散バージョン管理を組み合わせるアイデア: プログラマの思索

分散バージョン管理ツールにおけるブランチ戦略: プログラマの思索

Gitによるチケット駆動開発の事例: プログラマの思索

A successful git branching model とgithub flowの比較: プログラマの思索

第9回RxTstudy勉強会の感想～Redmineとチケット駆動開発の今後の課題　#RxTStudy: プログラマの思索

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点: プログラマの思索

【1】Redmineは日本のSIでかなり普及しているらしい。
その状況と並行して、オープンソース界隈では、GitHubでチケット管理する運用も多い。
すると、最近の状況としては、RedmineとGitを連携して、うまく運用したいという要望があるように思える。

しかし、RedmineとGitの連携とその運用は、まだまだ試行錯誤の部分が多いと思う。
RedmineとGitを巡る疑問点をリストアップしてみる。

【Q1】RedmineとGitリポジトリブラウザのツールと連携する方法はあるか？
具体的には、Gitlab、GitHub、GitBucketなど。

Redmineのリポジトリ管理機能には、GitをSVNと同様に設定できる機能はある。
しかし、Git単体で入れるよりも、Gitlab、GitHub、GitBucketのようなGit用のリポジトリブラウザを入れる方がGitのブランチ管理がやりやすい。

Gitlab、GitHub、GitBucketのいずれともRedmineと連携する方法については、既にネット上にたくさん書かれている。

だが、問題は、Redmineのチケット管理とGit用リポジトリブラウザのツール上のチケット管理をどのように使い分けるか、だ。
Gitlab、GitHub、GitBucketともに、Redmineのチケット管理よりも機能は貧弱。
でも、Redmineのリポジトリ画面よりも、Gitlab、GitHub、GitBucketの方が、Gitのブランチ管理やマージ管理はすごくやりやすい。

その問題の解決方法はまだ僕には分からない。

redmineとgithubの連携 - katashiyo515's diary

GitBucketとRedmineを連携する | 眠るシーラカンスと水底のプログラマー

GitLabとRedmineを連携してみるの巻 - アルパカDiary

RedmineとGithubの連携 - Qiita

【Q2】Gitのブランチ管理をRedmineへどのように対応づけるか？

Gitの利点の一つは、ブランチの生成と消滅に至るまでのライフサイクル管理がすごくやりやすいことだ。
ちょっとした機能追加、障害修正があれば、トピックブランチをすぐに作って、実験すればいい。

その場合、Gitブランチは、Redmineのどの機能と対応付けられるか？

ブランチをRedmineへ対応する方法は2つある。
一つは、プロジェクト。
もう一つは、チケット。

Redmineプロジェクトをブランチに対応付けた場合、ブランチからビルドされるモジュールは製品とみなされ、その製品のタスク・障害・課題管理にチケット管理が対応付けられる。
そのような運用がおそらく理想だと思う。

僕が6年前にRedmine＋Subversionを運用した時も、リリースブランチを作るたびにRedmineのサブプロジェクトに対応付けて、リリースブランチの生成と消滅のライフサイクルと、Redmineのサブプロジェクトを対応付けていた。
SCMCreatorのようなプラグインでは、Redmineプロジェクト名とSVNリポジトリ名を合わせて新規作成する機能を持っていた。

Redmine+SVN/Gitの環境構築 (3)｜ソフトウエア開発（android・iphone・windows・java等）の事なら株式会社パークにお任せください＿パク太郎のソフトウエア開発者ブログ

概要 - SCM Creator (+Github) - Andriy Lesyuk site

だが、Gitのようにブランチがたくさん作られる運用では、このような運用は非常に面倒になる。
Redmineプロジェクトの生存期間がすごく短くなるし、Redmineプロジェクトが乱発されて、チケットが散在してしまい、見通しも悪くなる。

後者の運用では、トピックブランチの生成のタイミングでチケットを作成し、マージのタイミングでチケットをCloseする。
Gitでブランチを作る時、チケットを先に作成し、ブランチの名前をチケットNoにしてブランチを作る。
そのようなコマンドもネット上にはある。

bleis-tift/Git-Hooks

mikoto20000/redmine_git_branch_hook

この運用の利点は、チケットにトピックブランチの修正履歴が残ることだ。
つまり、トレーサビリティを実現することができる。

この運用は、「No Ticket, No Fork」という運用ルールに発展する。

【Q3】Gitのマージ or PushをRedmineチケットのステータスとどのように対応づけるか？

Redmineチケットにトピックブランチを対応付けた場合、Pushするタイミングで、チケットも同時にCloseできるようにしたい。
そうすれば、「fixes #123」のコミットログを書いてコミットしたらチケットの進捗率が100％になってCloseされる運用と同じように運用できるから。
そのようなコマンドもネット上で公開されている。

mikoto20000/redmine_git_branch_hook

Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技：ゆめみスタッフブログ)

coiled-coil/git-redmine

この運用は、「No Ticket, No Merge」という運用ルールに発展する。

しかし、この運用ルールには幾つかの問題もある。
一つ目は、トピックブランチをマージする時に、特定のリビジョンを選択してマージしたり(cherry-pick)、複数のリビジョンをまとめて一括でマージする(squash)する時、現状のトピックブランチから別のブランチ上にパッチを一旦作成する必要があるために、チケットとマージ用ブランチが対応しなくなる。
つまり、トピックブランチの全ての修正履歴がチケットに記録されなくなる。

もう一つは、トピックブランチをPushするのは普通はありえないので、masterへrebaseが許せるのか？
本来は、rebaseのマージが一番美しい。
トピックブランチの修正履歴がそのままmasterに引き継がれるので、修正履歴が残るから。

しかし、トピックブランチの修正履歴を全てmasterに反映する必要は、普通はそもそもない。
コミッタやライブラリアンの立場では、masterには完成されたパッチだけマージすれば良いのであり、パッチの作成に至るまでの試行錯誤の修正履歴は必要ない。
パッチのコードレビューは、マージするタイミングの完成したパッチだけで十分。

この辺りの運用ルールの判断は、品質保証部やPMOと開発チームの力関係に依存する。

【Q4】プルリクエストをRedmineにどのように実現できるか？

GitHubが優れている利点の一つは、パッチのマージをプルリクエストという手法で実現することで、Web上でそのやり取りが見える化され、コミッタがコードレビューして判断するプロセスを自然に実現できたこと。
コミッタは、プルリクエストされたパッチが気に入らなければ、Rejectすればいいだけ。
コミッタとコントリビュータの間のやり取りは、プルリクエストのコメント履歴に残り、その後の運用保守で非常に役立つ。

しかし、RedmineではプルリクエストをGitHubのように自動化できていない。
プルリクエストするためにチケットを作り、そのチケットにパッチを添付するような運用しか無い。

本来は、プルリクエストを依頼する時に、チケットが自動作成されて、そのパッチのリビジョンが自動で添付されるような仕組みが作られるべきだ。
わざわざチケットを作って、依頼するための文章を書くのは面倒な手続きだからだ。

この点は、今後のRedmineの課題になるだろう。

【Q5】git-flowやGitHub-flowをRedmineにどのように実現して運用したらよいか？

Gitのブランチ管理を体系づけたgit-flowや、それをGitHub用に簡略化したGitHub-flowは、Gitを使う人なら当たり前の運用方法だ。
しかし、Redmineではそれをどのように運用すればいいのか？

GitHub Flow (Japanese translation)

git-flow によるブランチの管理 - O'Reilly Japan Community Blog

Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）：プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - ＠IT

ブランチ管理やマージ方法やプルリクエストを、Redmineのチケット管理とどのように対応付けるとよいのか？
Gitのブランチ管理やマージ方法やプルリクエストなどの一連の作業を、Redmine上で自動化して、もっとアジャイルに開発できる仕組みを実現できないのか？

現状のRedmineは、Subversionに特化しすぎていて、Gitとの連携方法の研究は未完成だ。
幾つかの手法は試されているが、それだけでは不十分だ。

Gitとの連携機能の強化は、Redmineの今後の課題になるだろう。