Git-flowからGitHub-flowへ

こんにちは 👋

KINTOテクノロジーズ、グローバルグループのRuoyang Wenです。 Global KINTO App チームのフルスタックエンジニアとして勤務しています。当グローバルグループについての詳細はこちらでご確認いただけます

目的

スタートアップ企業ではよくあることですが、初期のプロダクトにはいくつかの妥協点があります。ベネフィットを増やすためには、サービス改善の他に、ワークフローも改善する必要があります。

本記事では、Git-flowからGithub-flowへ変更した理由とその方法をお伝えします。

試み

トヨタグループの企業として、当社では日々の作業の中で日本語の「カイゼン（改善）」という言葉を使って改善を実施しています。お客様からのフィードバックと分析データによって、さらに良いサービスを提供するためのカイゼンはたくさんあります。自動化により、カイゼンプロセスを加速させることが可能です。

エンジニアにとって、ソースコードをコミットすることは日々の業務であり、単に成果物を提出するだけでなく、サーバー環境でコードをテストすることも含みます。我々は継続的インテグレーションと継続的デプロイ（CI/CD）をチームに導入することで、反復作業の削減を図りました。

CI/CDは、自動化を導入することにより、高頻度でアプリをリリースできる手法です。^[1]

我々はこれまで、Git-flowに従って、ソースコードと開発の進捗を管理してきました。しかし、CI/CDを導入してすぐに、作業プロセスがスピードアップしないことに気がつきました。

推論

git flow ダイアグラム

CI/CDスクリプトを利用したり、管理する作業は煩雑です。様々なブランチが多くあるため、ブランチを一つのカテゴリからもう一つの他のカテゴリにマージさせる際、別のスクリプトが必要になります。：featureからdevelopへ、developからreleaseへ、releaseからmainへ、hotfixからmainへ、mainからdevelopへ、_developからfeatureへ_等… いたるところにコンフリクトが生じます。コンフリクトは自動化スクリプトでは解決できません。自動化により日々の作業量が増大しました。なぜでしょうか。

リサーチを実施して判明したこと：**Git-flowは元来、手動かつラグのあるワークフローです。**そこで、新しいワークフローが必要になります。

再試行

先のリサーチで見つけたいくつかのワークフローの中で、私たちはもともとソースコードをGitHubに保存していることもあり、GitHub-flowを試してみることにしました。

github flow ダイアグラム

今回はブランチが二種類のみです：mainと「change-of-anything」。そしてmainへ直接コミットすることをブロックします。mainをアップデートする唯一の方法は、mainに対してプルリクエストを実施することです。その結果、必要なのは1つのCI/CDスクリプトのみとなり、どんなコンフリクトもプルリクエストの中で発見・解決することが可能です。

新しい課題

我々はブランチ戦略を簡素化し、CI/CDを実施するスクリプトは1つだけで、コンフリクトを管理するためにプルリクエストを利用しました。これですべて解決でしょうか。プラス面もありますが、マイナス面もあります。

プラス面を見てみましょう。反復作業を自動化スクリプトに移管したことで、全員がより生産性の高い作業を行うことができます。リリースとデプロイのプロセスはスクリプトによって処理されるため、ローカルで加えた変更は2分以内にサーバーにデプロイできます。

では、マイナス面を見てみましょう。システムの機能/バージョンの管理ができなくなりました。機能は各ブランチには保存されず、プルリクエスト後に直接 main に保存されるため、次のバージョンでどの機能を保留し、どの機能をリリースするかが決められません。また、main ブランチは最新のソースコードでアップデートされ続けるので、バージョンの番号は1日で数百も増加する可能性があります。

ネクストステップ

幸いなことに我々のみが直面している課題ではありません。すでにこれらの課題に直面している人々がおり、我々は彼らの歩みをたどり、彼らの解決策を見ることができます。

フィーチャートグルを使って、いつでも機能を有効／無効にできます。パラメータの中に保存できるので、新規のリリース／デプロイは不要です。異なる機能の組み合わせを備えた異なるバージョンをリリースするGit-flowよりも優れています。

バージョン番号は、特定のコミットを本番環境にデプロイした後にのみ追加されます。残りの環境には、バージョン番号としてコミットハッシュを使用します。これは、そのコミットのバグや欠陥を即座に見つけるのに役立ちます。

まとめ

疑う余地もなく、すべての問題を解決する完璧なソリューションはありません。GitHub flowには欠点もあり、私はチームと一緒に我々のプロダクトだけではなく、作業方法についてもカイゼンするべく動いています。

個人的には、Git-flowはウェブポータルのようなもので、定義されたルールですべてを分類します。誰もミスしなければ、問題なく動作します。一方、GitHub-flowはサーチエンジンのようなもので、本番環境にリリース／デプロイするコミットにバージョン番号をタグ付けし、他の環境ではコミットハッシュがバージョン番号として利用されます。そのため、何か問題があれば、検索でそれらのバージョンを簡単に見つけることができます。

参考

• トヨタ生産方式
• What is CI/CD?
• What is Continuous Integration?
• Git flow for agile teams is a no no
• Please stop recommending Git Flow!
• Git Flow vs GitHub Flow
• GitHub flow - GitHub Docs
• Continuous Integration Contradicts Features Branches!
• How to Achieve Continuous Deployment with Feature Flags

脚注

1. https://www.redhat.com/en/topics/devops/what-is-ci-cd#overview ↩︎