この記事は、 Kyash Advent Calendar 2025 14日目の記事です。
昨日は松本さんの 絵心よりも“分解力”が大事だった話 でした。自分の子供にこの記事を紹介して一緒に図形の組み合わせでイラストを書いてみようと思います。
KyashでiOSアプリを開発している tamadon です。Cornix LP という分割キーボードが欲しくて毎日注文ページをチェックしています。第2弾の販売受付が開始されることをお待ちしております 🙏
この記事ではKyashのモバイルチームで採用している トランクベース開発 を便利にする仕組みについて紹介します。
「トランクベース開発とはなんぞや？」という話は以下の記事を参考にしていただけると、イメージが掴めるかと思います。
メチャクチャ簡単に説明すると「開発中のコードをどんどんmainブランチにマージしつつアプリをリリースする。ただし開発中の機能はフィーチャフラグ等を使用してユーザーに見えない状態にする」開発スタイルです。
この開発スタイルになってから、featureブランチがなくなりmainマージ時のコンフリクトが発生しないため最高です。
そんな最高なトランクベース開発ですが運用を始めてみて改善点が見つかってきました。それは「リリース前テストで見つかった不具合修正をリリースブランチにcherry-pickするのが地味に面倒」ということです。
もう少し詳しく説明します。
Kyashのモバイルアプリは、開発中のコードをどんどんmainブランチにマージするのは先程書いたとおりです。
そして、アプリのリリーススケジュールが決まった際にはリリースする機能を決めてmainブランチからリリースブランチ(例: release/10.0.0)を切り、テスト用アプリを配布します。
その後テストで問題がなければ、リリースブランチの内容でアプリを申請してリリースします。
ここで問題になるのが、リリース前テストで不具合が見つかった等の理由でコードの修正が必要になるケースです。
トランクベース開発では、mainブランチとリリースブランチの両方に修正を適用する必要があります。
以前は、温かみのある手作業でmainブランチにマージした内容をリリースブランチにcherry-pickした後にリリースブランチに対して修正するPull Rqsuestを作成し修正を適用していました。
これがなかなか大変だったので「リリースブランチにcherry-pickしたい修正がmainブランチにマージされたら自動でcherry-pickのPull Requestを作成してくれる」名付けて 自動チェリピくん というGitHub ActionsのWorkflowを作成しました。
自動チェリピくんの紹介
ソースコードはこちらになります。
使い方はシンプルで、こんな感じで「このPull Requestがマージされたら同じ内容をcherry-pickしたい」Pull Requestに need cherry-pick というラベルを付けるだけです。
そうするとPull Requestがマージされるとこんな感じで自動でマージコミットをcherry-pickしたPull Requestが作成されます 🙌
手動チェリピくんの紹介
我々は人間なので、Pull Requestにラベルをつけ忘れることもあると思います。そんな事もあろうかと、先程のworkflowを後から手動で実行できるworkflowも用意しています 👍️
ソースコードはこちらです
使い方はこちらもシンプルです。GitHubのActionsタブからRun workflowで実行してください。 マージコミットのハッシュ値を貼り付けて実行すれば自動でcherry-pickしたPull Requestが作成されます。
両Workflow共に [CUSTOMIZE] とコメントがある箇所は皆さんの環境で変更してください。
注意点と改善点
このWorkflowを実行するにあたって1つ注意点があります。
コメントにも書いてありますが GITHUB_TOKENで作成したPRはCIが自動起動しません。 業務で開発作業を行う際にはPR作成時にUnitTestやLintチェック等、何かしらCIが動作するかと思います。
PR作成時にCIを動作させたい場合はPAT(Personal Access Token)を使用してください。
会社のセキュリティ要件等でPATが使えない場合は、自動作成されたPRを手動でcloseした後にreopenすればCIが動き始めます。試してみてください。
改善点としては、複数リポジトリにこのworkflowを配置すると更新があった時に大変というものがあると思います。
KyashではiOSアプリ、Androidアプリ、KMP(Kotlin Multiplatform)という3つのリポジトリで運用しているため、 GitHub Actions Reusing Workflow を使用してworkflowを共通化しています。
記事の内容が複雑になるためこの記事では紹介しませんが、こうすることでworkflowの実体を1箇所で管理できるようになります。呼び出し元リポジトリはReusable Workflowを呼ぶだけです。
Tokenの定義を呼び出し元リポジトリで行う という事に気をつければそんなに難しくないと思います。複数リポジトリにまたがるプロダクト開発をしている際には検討してみてください。
これにより、手動でcherry-pickする手間がなくなりトランクベース開発のテンポが良くなったように感じています。
いかがでしたでしょうか。この記事がトランクベース開発を行うチームの参考になれば幸いです。
仲間を募集しています！
Kyashではサーバーサイド と SREのポジションを募集しています。 興味のある方は X のDM か YOUTRUST から気軽にご連絡ください！
