長沢さんの「モダンなチーム開発環境のフリー利用可能な資料」が素晴らしい～プルリクエストはJiraにあってRedmineにない機能
長沢さんのモダンなチーム開発環境のフリー利用可能な資料が素晴らしいと思った。
長沢さんのJira資料を読むと、RedmineよりもJiraの方がチケット管理の環境が一歩進んでいる印象を持った。
その理由を書いてみる。
【元ネタ】
モダンなチーム開発環境のフリー利用可能な資料を公開
Atlassian製品による「No Ticket, No fork!」: プログラマの思索
GreenHopper を使用した Bamboo と Bitbucket の自動化 | Atlassian Japan
Stash 3.3: タスク機能を利用してプルリクエストの進捗状況を追跡 | Atlassian Japan
RedmineとGitを巡る疑問点～Gitとの連携機能の強化がRedmineの課題: プログラマの思索
【1】JiraでもRedmineでもチケット管理の手法は同じだし、SVNやGitのような構成管理ツールとチケットを連携する機能も手法も同じ。
しかし、JiraがRedmineよりも優れている点は、Git連携の機能強化の部分にあると思う。
換言すれば、Gitからのブランチ派生、Gitのmasterへプルリクエストする機能が、JiraはRedmineよりも優れていると言える。
Jiraでは、Git上でトピックブランチを作ると、チケット画面にブランチのリンクが作られる。
例えば、障害修正やちょっとした仕様変更が発生したら、トピックブランチを派生させるが、そのトピックブランチがチケットに自動で連動されている。
つまり、トピックブランチを派生させるタイミングで、チケットへブランチにリンクする機能をフックしているわけだ。
Jiraのチケット画面を見ると、ステータスが「提案済み」「オープン」では「ブランチを作成」リンクがあるので、チケット画面上でワンクリックでトピックブランチを関連付けることができる。
つまり、「No Ticket, No fork」の運用が、Jiraではチケットの一機能に含まれているので、開発者にトピックブランチの運用を強制できるし、開発プロセスを標準化することもできる。
この運用は、「No Ticket, No fork」に相当する。
すなわち、トピックブランチは必ずチケットにリンクさせて、相互追跡可能にする。
この機能と運用の利点は、トピックブランチの修正が全てチケットに記録されること。
「No Ticket, No Work」の運用のGitブランチ版と言える。
【1－1】但し、Redmineのデフォルト機能には、「No Ticket, No fork」をサポートする機能はない。
そこで、RedmineとGitを巡る疑問点～Gitとの連携機能の強化がRedmineの課題: プログラマの思索にも書いたが、Redmineでは、redmine_git_branch_hookプラグインを使うのが良いだろうと思う。
mikoto20000/redmine_git_branch_hook
redmine_git_branch_hookプラグインを使えば、チケットIDに対応付けたトピックブランチを自動生成してくれるから、「No Ticket, No fork」をRedmineの一機能に実現できる。
しかし、Redmineチケットにブランチのリンクを貼ってくれる機能はない。
その点は残念だ。
【2】そして、ブランチを作成後、Jiraチケットのステータスが「進行中」ならば、「1個のブランチ」というリンクが表示される。
また、トピックブランチ上の修正は、自動でチケットに記録され、「1件のコミット」というコミットログが残る。
つまり、チケットのコメント履歴とブランチのコミット履歴は、「No Ticket, No Commit」の運用ルールによって、相互リンクされている。
この運用によって、なぜこんなIF文の多い修正をしたのか、なぜこんなパッチを作ったのか、という変更理由や本来の要件を追跡できるようになり、その後の機能追加や障害修正で役立つ。
この部分は、Redmineならば、コミットログに「refs #12」のように書く運用を義務付ける必要がある。
できれば、Redmineでも、チケット番号をコミットログに書く運用をしなくても、自動でチケットにリビジョンが紐づけられるような機能があればよい。
Jiraでは、そのような機能が実現されているのだから。
【3】また、Jiraチケットでは、ビルドが終了して通過できれば「1件のビルド」という履歴が残る。
Jiraでは、Bambooというビルド管理ツールを組合せて実行するようだ。
この機能は、Redmineなら、Hudson Pluginで実現できるだろう。
Hudson Pluginを使えば、チケット履歴にビルド履歴が表示され、ビルド番号とチケットを紐付けることができる。
また、チケット欄に、ビルド成功・ビルド失敗も表示されるので、ビルド失敗ならば、すぐに対処するような運用を課しても良い。
【4】さらに、Jiraのトピックブランチ上で修正が終わり、masterへマージしたい時、プルリクエストを送ることができる。
Jiraでは、プルリクエストを送ると、Stashというコードレビューツールでコードレビューが行われ、それがOKなら、masterにマージされるという運用になっているようだ。
つまり、プルリクエストは必ずコミッタまたはライブラリアンのレビューを通過するという運用が、ツール上で実現されている。
Jiraチケットでは、ステータスが「レビュー中」にプルリクエストを送ると、「1件のプルリクエスト」というリンクが貼られる。
但し、僕がまだ理解できていない部分は、Jiraのプルリクエスト機能はJiraのどの画面から送信するのか？、ということだ。
おそらく、Gitのトピックブランチへコミットした後、プルリクエスト対象のリビジョンを指定した時に、プルリクエストのボタンがGitリポジトリ画面にひょうじされるのではないか、と想像する。
つまり、GitのCherry-pickによるマージ作業を実施している時に、プルリクエストを送信できるようにしているのだろう。
そうすれば、Git画面上でプルリクエストを送ると、Jiraチケット画面に「1件のプルリクエスト」リンクを表示するような機能がフックされる仕組みを実現すればいい。
そのプルリクエストが承認されて、検証環境へデプロイされれば、Jiraチケットのステータスは「解決済み」へ変わる。
最終的に本番環境へデプロイされれば、Jiraチケットは「完了」ステータスになる。
この運用は、「No Ticket, No Merge」と呼ばれる。
つまり、プルリクエストを送り、そのプルリクエストが承認されれば、マージされてチケットもCloseする運用だ。
Jiraが優れている部分は、プルリクエスト機能を持ち、プルリクエストが承認されるタイミングで、チケットのステータスが自動的に変更される機能を持つことだ。
【4－1】しかし、Redmineでは残念ながら、「No Ticket, No Merge」はデフォルトの機能では実現されていない。
但し、RedmineとGitを巡る疑問点～Gitとの連携機能の強化がRedmineの課題: プログラマの思索にも書いたが、Redmineでは、redmine_git_branch_hookプラグインが、プルリクエスト相当に似た機能を持っている。
かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）：Redmine×Gitのハーモニーは涙のチケット駆動開発!? (3/3) - ＠ITにも、その運用方法が一部記載されている。
mikoto20000/redmine_git_branch_hook
redmine_git_branch_hookでは、チケットIDを含むトピックブランチをマージした時に、自動的にチケットをクローズする機能を持つ。
つまり、マージするタイミングで、チケットのステータスを「解決」または「完了」へフックして自動で変更してくれる。
だが、これは「プルリクエストに似た機能」としか言えない。
コミッタまたはライブラリアンがプルリクエストを受け付けて、承認するかReject(差し戻し)するか、という機能は実現されていない。
本来なら、この部分もRedmineで実現されるべきだ。
本来のプルリクエストは、「リビジョン指定→チケットの自動発行」であり、「チケット発行→リビジョンを指定してパッチを添付」の流れではないのだ。
残念だが、redmine_git_branch_hookプラグインは、「リビジョン指定→チケットの自動発行」まで実現してはいない。
【5】以上のように、JiraとRedmineのGit連携の機能を比較すると、Jiraの方が優れている機能がある。
なぜ、このようにチケット管理ツールのGit連携に力を注ぐべきなのか？
その理由は、モダンなチーム開発環境のフリー利用可能な資料を公開で長沢さんが書かれている。
換言すれば、最大の利点は、チケットと構成管理配下のソースのコミット履歴を連携することで、トレーサビリティを完全に実現することだ。
(引用開始)
したがって、ウォーターフォールだからとか、アジャイルだからとかではなく、追跡可能性が常に維持されている環境にしたいわけですが、そのためには、開発者をはじめとしたチームメンバーにかなりの負担を強いることになります。それこそ、本業よりも、情報収集や更新作業に費やさなければならないくらいに。
ただし、これをやっておかないと、バグ1件ですら満足に対応できない事態にすぐに陥ります。なので、よりよい開発環境にすることはとても重要になってきています。
(引用終了)
WF型開発でも、設計書とソースのトレーサビリティを重視する動きは過去も今もあるが、普通は、Excelの設計書の変更履歴や、Excelのリリース管理台帳で管理しがちだ。
それでは、過去の履歴を検索したり、調査するのに、Excelの山から逐一検索する手間がかかる。
また、ソースや設計書は頻繁に修正するから、トレーサビリティを維持するために、Excelの設計書や管理台帳を保守するコストもかなり大きい。
変更履歴の入力ミスは結構あるし、修正履歴やリリース履歴が多くなるほど、保守が面倒になって、最終的に誰も保守しなくなる。
アジャイル開発では、開発環境をツールでできるだけ自動化し、成果物の構成管理やトレーサビリティをツールで実現する方向へ進化している。
そして、TracやRedmineから生まれたチケット駆動開発は、「No Ticket, No Commit」の運用ルールによって、成果物とソースのトレーサビリティを自然に運用できる開発基盤を提供した。
【6】しかし、TracやRedmineは、Subversionを前提としているため、Gitのようなブランチ管理とマージ方法とチケット管理ツールを連携する機能が貧弱だ。
つまり、トピックブランチのように一時的に生成され、その修正パッチをプルリクエストで送り、コミッタの承認を得るという仕組みが、RedmineやTracでは実現されていない。
したがって、GitHubで皆が普通に使っているプルリクエストがRedmineで使えない現状があるために、Redmineが最近の開発環境の進化から遅れているようにも見受けられる。
ただし、JiraはGit連携を強化しているように思える。
そもそも現代の開発では、プログラマはGitで構成管理するのが普通であり、タスクをチケット管理するのも普通だ。
なのに、RedmineではGitとうまく連携できていない課題がある。
「nanapi勉強会 vol4」に参加してきました - 勉強会ログ
RedmineのGit連携の機能強化はどのように実装すべきなのか、どのように運用すべきなのか、という課題は、今後も考えていく、
最近のコメント