RedmineをGitHub化するアイデア
RedmineをGitHub化するアイデアをラフなメモ書き。
【元ネタ】
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録
はてなブログチームの開発フローとGitHub(前編)。GitHub Kaigi 2014 - Publickey
はてなブログチームの開発フローとGitHub(後編)。GitHub Kaigi 2014 - Publickey
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点: プログラマの思索
RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索
長沢さんの「モダンなチーム開発環境のフリー利用可能な資料」が素晴らしい~プルリクエストはJiraにあってRedmineにない機能: プログラマの思索
チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索
【1】なぜRedmineにGitHubの機能を実現したいのか?
RedmineはSVNとの連携を前提にしている。
でも、今の開発はGitHubを利用するのが当たり前。
GitHub-flowが非常に使いやすいのだ。
ちょっとしたアイデアの開発、障害修正、機能追加は、masterからfolkして、トピックブランチ上で色々試す。
出来上がったら、マージする対象のリビジョンを指定して、プルリクエストを送る。
コミッタがOKなら、masterに取り込まれる。
ブランチをいくら作っても簡単に管理できる。
いつでもブランチをマージできるのは心強い。
SVNのマージは非常にやりにくかった。
CVSはファイルごとにタグ付けしてマージしていたから、なおさらだ。
プルリクエスト駆動の開発は、動くソースを中心に開発が進むから、アジャイル開発と凄く相性が良い。
わざわざチケットを発行して、ソース変更のリビジョンを紐づけなくても、コミットログそのものがチケットのような働きをする。
チケット管理がコミットログに置き換わったような開発スタイル。
【2】Redmineに取り込みたいGitHubの機能は、フォークとプルリクエストだ。
【2-1】フォークは、No Ticket, No Mergeの運用ルールを実現する。
チケット無しにフォークできない。
ブランチにはチケットIDの情報を持たせる。
Redmineでは、RedmineプロジェクトにGitリポジトリを連携する設計思想だ。
だから、RedmineチケットにGitリポジトリを連携付ける機能はデフォルトにはない。
そこで、RedmineチケットIDをブランチ名にしてフォークを強制するプラグインを使う。
色んな実現方法があるはず。
Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記
Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技:ゆめみスタッフブログ)
あるいは、Redmineプロジェクトとリポジトリを強制的に連携付けるプラグインがあるので、そのやり方を真似れば実現できるような気がする。
つまり、チケットを作成した後、Gitブランチを紐付けるような機能を持たせれば良いと思う。
SCM Creator (+Github) - Plugins - Redmine
RedmineとSubversion・Git・Mercurialのリポジトリ(ともに同じCentOSサーバ上)の連携(リポジトリの作成とアクセス・認証) | misty-magic.h
Redmine+SVN/Gitの環境構築 (3)|パークのソフトウエア開発者ブログ|ICT技術(Java・Android・iPhone・C・Ruby)なら株式会社パークにお任せください
[Alminium][Redmine]複数のリポジトリを作る場合の注意点 | Developers Pit
いずれの方法にしても、「チケット発行→ブランチをフォーク」という流れ。
逆に、「ブランチをフォーク→チケットを自動発行して、チケットに紐づける」流れで実装できないのか?
【2-2】プルリクエストは、No Ticket, No Mergeの運用ルールを実現する。
チケット無しでマージできない。
今の所、下記のプラグインは、ブランチをマージした時に、チケットを自動でCloseする機能を実現する。
つまり、「マージ完了→チケットを自動でClose」の流れ。
この機能は確かに素晴らしい。
mikoto20000/redmine_git_branch_hook
但し、本来のプルリクエストは、「チケット発行→パッチをチケットに添付→チケットを自動でClose」の流れではない。
「リビジョンを指定→チケットを自動発行→コミッタがマージしたらチケットを自動でClose」の流れだ。
つまり、マージしたいリビジョンを指定して、コミッタにメッセージを送信する時に、チケットが自動で発行されるのがミソだ。
気になるプラグインは、下記のプラグインだ。
「Github like pull requests plugin for redmine.」と書かれているので、それが本当なら、プルリクエストをRedmine上で実現してくれるはず。
【3】git-flowモデルは、Redmine上にどのように実現できるか?
一つのアイデアは、Redmineのマルチリポジトリ機能を使って、masterとdevelopをRedmineプロジェクトに対応づける。
そして、トピックブランチ、フィーチャブランチ、ホットフィックスブランチは、Redmineチケットに対応づける方法。
Redmine 1.4新機能紹介: 一つのプロジェクトで複数のリポジトリに対応 | Redmine.JP Blog
一方、下記の記事のように、git の base リポジトリで HEAD の向き先を変更し、masterの代わりに常にdevelopを表示させる方法。
Redmine で git を参照する際、既定ブランチを develop にする | オフィスウーム
但し、再び他から push があると HEAD の向き先が戻ってしまうので、リポジトリのフックを使ってミラーリポジトリに push すると同時に再設定させる。
この手法の利点は、masterよりもdevelopの方が開発者にとって身近であり、頻繁に使うリポジトリなのだから、developを優先して表示できること。
【4】フォークやプルリクエストの機能も、「フォーク→チケット発行」「プルリクエスト→チケット発行」「マージ(pull)→チケットClose」を実現したい。
つまり、リポジトリの操作をRedmineの画面上で行った後、勝手にチケットが自動で発行されたり、チケットが自動でCloseされる運用を実現したいのだ。
換言すれば、リポジトリの操作を実行した時に、チケット登録・Closeのフック処理を実装する必要があるわけだ。
他にも実現できる方法があるか調べてみる。
| 固定リンク
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント
github-flowはソフトウェアに特化し過ぎてる感がして、今一つ乗れません。つまり、成果物がscmと紐付かないならチケット切るな、となりそうで、以前の記事 https://forza.cocolog-nifty.com/blog/2013/06/8redminecrm-rxt.html 辺りの使い方がし難そうに思えます。
投稿: Bak. | 2015/07/18 20:55