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とチケット管理ツールの相性について、もっと考えてみたいと思う。
【参考】
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「Git・構成管理」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
「チケット駆動開発」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
「Agile」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
コメント