😸
Trunkベースとか、github-flowなどのブランチ戦略のHowを悩んでみた
最近ブランチ戦略としてTrunkベースとかgithub-flowで有りたいなーと思うことが増えてきました。業務では一部はgithub-flowを採用していたりしますが、git-flow likeなブランチ戦略を採用している事も多いです。
それぞれのブランチ戦略に関しては、赤帽エンジニアブログさんの「トランクベース開発について」にかかれておりますので、こちらを貼っておきますね。
とりあえずExample作ってみた
書いたとおりですが、github-flowでプロダクト開発するとしたらどういう構成がいいかを趣味で雑に考えてみました。実務利用経験は無いので運用しだしたら課題がボロボロでるかもですし、改めて深く見直すとすでにボロボロしているかもです。むしろすでにいくつか課題はあると思っています。
どんなフローになるだろう
こちら↑で書いたGithubのREADMEに添付している内容と同じですが、色々考慮した結果こういう形に落ち着きました。
- 開発者はmainブランチからfeatureブランチを作成
- featureブランチで開発を進めて、mainに対してPull Requst(以下PR）を作成
- mainへのPRが以下の条件を満たしたら、PRをMerge
4. レビュアーからApproveをもらう事
5. TestやLintなどいわゆるCI処理をGreenとする事
6. mainブランチの最新のcommitに追従している事
7. ここを保証することで、mainへマージする前に最新のmainも含めた形でテストを実施できます。 - mainにpushイベントが発火したらステージング環境へデプロイ
9. 開発者などはステージング環境で確認する - 8と同タイミングに、自動的に最新のReleaseを作成（もしくは更新）されます
- Releaseに含まれるPRのすべてをCheckして問題がなければReleaseをPublish
12. feature -> release -> mainとしていた時代には、releaseに積まれたものをcheckしていたケースもあると思います。それをReleaseに置き換えているイメージです。
13. 理想は複数のPRを積む前に1PR単位で動作確認をしてPublishをすることかなと思ってますが、そう出来ないケースなどでは貯める事があると思うので、それもできる形に - ReleaseのPublish時にTagが作られますので、それをトリガーにしてProductionにデプロイ
細かい動きなどは、コードを見てもららう方が早いかもしれませんが、なんとなくこういうフローでいいかなという思いまがあって、整理してみた次第です。
最後に
これは決して正解ではなく課題も多いと思っています。ブランチ戦略に悩まれている方や、github-flowやtrunkベースを実現したいと思っている方にとって少しでも一部でも何かきっかけになれば嬉しく思ってます。
また逆にこうやってるよー！！とかあればどんどん知りたいです！Meetyでお話とかも大歓迎です！！
追記
2022/02/03 こちらにある通り、追従が必要になったときにpullしてrebase、そしてpushをしなくてよくなってました。UI上で出来るので楽になりますね。
Discussion