GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。
【参考】
GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録
GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ]
Fujimura ? GitHubで既存のissueに対してpull requestする
hub コマンドで github から fork して pull request をさくっと - #生存戦略 、それは - subtech
Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記
かんばん!~もし女子高生がRedmineでスクラム開発をしたら(6):Redmine×Gitのハーモニーは涙のチケット駆動開発!? (1/3) - @IT
mikoto20000/redmine_git_branch_hook
Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技:ゆめみスタッフブログ)
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineers' Blog
GitHub直伝 プルリクエスト活用の3つのコツ | A-Listers
percolとgit-issueを使って、redmineのチケットをブランチに切って作業するのが捗る設定 | Technology-Gym
Gitブランチを使いこなすgit-flow/GitHub Flow入門(1):いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 (1/2) - @IT
Gitブランチを使いこなすgit-flow/GitHub Flow入門(2):git-flowのインストールとブランチ運用前のリポジトリ準備 (1/2) - @IT
【1】GitHubでも、チケット駆動開発を運用することはもちろん可能だ。
チケット駆動開発の利点であるトレーサビリティを実現するには、コミットログにGitHubのIssueNoを書く運用をすればいい。
しかし、GitHub上でプルリクエストする時には、以下の問題点がある。
(引用開始)
しかし GitHub では、Issue 番号を発行するためには Pull Request を作る必要があり、Pull Request を作るためにはコミットを作る必要がありますが、コミットをする際には予め Issue 番号を知らなければならないため、 Issue 番号付きでのコミットができません。
そのため、しばらくは
1.チケット番号を発行するための Issue をまずは発行する
2.そのチケット番号をコミットログに含めてコミットする
3.その番号とは別に Pull Request を発行する
といった運用をしていました。
一つのトピックに対して、Issue 番号と Pull Request 番号の2つができてしまうため、あまりイケていませんでした。
(引用終了)
GitHubでプルリクエストを行う時、このパッチをマージして下さい、というコメントを書くが、そのチケット番号は新規発行されるために、そのチケット番号をプルリクエストするパッチに紐付けすることができない問題点がある。
【2】解決方法としては、他の記事「GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ]」にもあるように、hubコマンドを使う方法があるだろう。
(引用開始)
#例: pullreq ブランチから master ブランチに対して Pull Request を送りたいが、その際に既存の Issue#123 にコードを添付したい
git checkout -b pullreq
hub pull-request -i 123
(引用終了)
【3】上記の記事の問題点は、チケット駆動開発とGitとの相性が良くない点があることに起因しているように思う。
第9回RxTstudy勉強会の感想~Redmineとチケット駆動開発の今後の課題 #RxTStudy: プログラマの思索にも書いたけれど、Gitでチケット単位にトピックブランチを作る運用では、幾つかの問題点が提起されていた。
一つ目は、コミット履歴が故意に改変される危険があること。
これは、特に、trunkの履歴は改変できないように、運用ルールでカバーするしかないだろう。
2つ目は、チケットNo付きトピックブランチで作業していたとしても、trunkへpullする場合、squashで過去のコミット履歴をまとめてパッチ1個で送ろうとすると、新たにチケット番号を付与しなくてはいけないこと。
上記の記事のように、トピックブランチ上のコミット履歴をそのままtrunkに反映する場合は、hubコマンドを使って、トピックブランチと関連付けられたチケット番号を付与してPullRequestすれば良い。
しかし、trunkのコミット履歴には、トピックブランチ上の試行錯誤した履歴は特に欲しくない時もある。
修正のレビューも終わり、完成版のパッチのみを記録したいのが普通だから。
すると、PullRequest用のパッチを作るために、別のブランチを作って操作する必要が出てくる。
そのための新たなチケット番号を作るしか無い。
さらには、本来は、Atlassian製品のように、folkすると自動でチケット番号が付与され、pullされる時にチケットも自動でCloseされるように運用したいのだ。
Atlassian製品による「No Ticket, No fork!」: プログラマの思索
そうなれば、仕様変更や機能追加、障害修正、課題が発生するたびに、チケットを起票する癖がつき、そのチケットに作業履歴を残す運用が徹底される。
また、それらチケットと、トピックブランチが密に関連付けられることによって、何のためにソースを修正しているのか、をいつも自覚するようになるから、ソース修正の意図も明確になる。
プログラミングにはまっていると、ソースを綺麗にしたり、たくさんの機能を追加することに気を取られてしまいがちだから。
【4】トピックブランチとチケット駆動開発の運用ルールや運用方法については、色んなツールが出てきており、試してみる価値があると思っている。
そんなことを思う理由は、チケット駆動開発はTrac+Subversionの運用が発端であったために、Gitのような優れた分散バージョン管理の機能とチケット管理ツールの連携が不十分な面がまだあるように思えるからだ。
【4-1】例えば、Redmineチケットごとにトピックブランチを「id/12」のように作った場合、bleis-tiftというフックスクリプトを使うと、id/12というブランチで作業してるときは、コミットメッセージの末尾にrefs 12を自動付与してくれる。
Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記
このフックスクリプトのメリットは、チケットNo付きトピックブランチをいちいち気にしなくても作業できることだ。
つまり、トピックブランチ上で作業している時、「No Ticket, No Commit」を意識せずとも、ツールが自動補完してくれるわけだ。
【4-2】例えば、「Redmine Git Branch Hook」スクリプトを使うと、トピックブランチをマージするタイミングでRedmineチケットを自動でCloseする運用も可能だ。
かんばん!~もし女子高生がRedmineでスクラム開発をしたら(6):Redmine×Gitのハーモニーは涙のチケット駆動開発!? (1/3) - @IT
mikoto20000/redmine_git_branch_hook
このフックスクリプトのメリットは、マージしてトピックブランチが廃止される時に、チケットをCloseする手間を省いてくれることだ。
つまり、Redmine+SVNで、「fixes #12」でコミットした時にチケットがCloseされる運用をGitのブランチのマージへ適用したものだ。
【4-3】上記の2つの運用は、Gitのトピックブランチ上で「No Ticket, No Commit」「No Ticket, No Merge」をサポートするためのツールといえる。
それらのツールを運用すれば、開発者はトレーサビリティや変更管理、構成管理などの複雑な標準プロセスを意識せずとも、プログラミングに専念するだけでいい。
本来のアジャイルな開発は、複雑で無駄が多い標準プロセスを意識せずとも、プログラミングだけに専念すれば、ユーザに価値あるソフトウェアを即座にリリースできる環境を整えることにあるはずだ。
これらの観点で、分散バージョン管理Gitとチケット管理ツールの相性について、もっと考えてみたいと思う。
【参考】
| 固定リンク
「Agile」カテゴリの記事
- 法律のケース問題をモデル化するアイデア(2019.02.11)
- Coplienの開発工程の生成的パターン言語を読むpart1(2012.10.11)
- ユーザ機能駆動開発FDDを再考(2011.05.28)
- Redmineプロジェクトの構造とConwayの法則(2011.05.18)
- Conwayの法則~アーキテクチャは組織にしたがう(2011.04.17)
「Git・構成管理」カテゴリの記事
- 第14回東京Redmine勉強会の感想 #redmineT(2018.05.27)
- 歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク(2018.12.30)
- 第19回Redmine大阪の見所 #redmineosaka(2019.01.26)
- PlantUML Example for モデルベース要件定義テクニックの記事のリンク(2019.01.04)
- GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか(2019.01.11)
「ソフトウェア工学」カテゴリの記事
- ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか(2015.07.18)
- 【告知】2019/2/16にSEA関西でIPAの方の講演「IoT時代のシステム開発アプローチ」の見所 #seakansai(2019.01.11)
- 【告知】2019/3/2にSEA関西で「気象予報システムを支える技術」の見所 #seakansai(2019.01.11)
- 大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響(2016.06.19)
- チケット駆動開発のアイデアがRedmineへ与えた影響は何か(2018.12.10)
「チケット駆動開発」カテゴリの記事
- ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか(2015.07.18)
- 第19回Redmine大阪の見所 #redmineosaka(2019.01.26)
- Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影(2016.02.10)
- 大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響(2016.06.19)
- チケット駆動開発のアイデアがRedmineへ与えた影響は何か(2018.12.10)
コメント