ブランチのマージ作業を効率化するGitHub Actionsワークフローの導入

前提

GitHub Actionsの導入ではなく、ブランチのマージを効率化するためのGitHub Actionsワークフローの導入について説明します。 このワークフローは「Branch Merger」と名付け、自チームの運用ルールに合わせた自作のワークフローです。

具体的なコードや詳しい説明は以下のテックブログをご覧ください。

GitHub Actionsでブランチのマージを効率化する方法

ツール導入前の課題

フィッツプラスでは、動作検証用のステージング環境を用意しており、その環境にて開発中の機能をテストしています。 開発用のブランチをstagingブランチにマージするとデプロイ処理が走り、ステージング環境に開発中の機能を反映させることができます。

そのため、開発中のブランチをstagingブランチへマージする作業が度々発生するのですが、以下のような小さな手間がありました。

• staging環境へデプロイする前に自動テストなどのCIが通るまで待つ必要があります。
• CIが通るまでの間、別のブランチで開発やレビューを進めています。 そして、いざCIが通って開発中のブランチをマージする際、git switchでブランチを切り替えたり、作業中のコードをgit stashしたりする手間がかかります。

どのような状態を目指していたか

このワークフローによって、ブランチのマージ作業が楽になることを目指しました。

具体的なシチュエーションは以下です。

• ローカル環境で別の開発作業を行っていても、ブランチを切り替える必要がありません。
  • git worktreeコマンドを使ってマージ作業を行うこともできますが、コメント1つでマージできるのは便利です。
• DependabotやDevinが作ったプルリクエストをローカル環境にプルして、マージする手間が省けます。
  • DependabotやRenovateなどのライブラリ更新ツールやDevinなどの生成AIが作ったプルリクエストをGitHub上からマージすることができます。

YAMLファイルを書くだけでワークフローを構築できるのがとても便利です。

チーム内ではすでにGitHub Actionsワークフローを使って定型作業を自動化しているので、今回も同様にGitHub Actionsを用いることにしました。

改善したかった課題はどれくらい解決されたか

「プルリクエスト上でコメントするだけでマージできる」という手軽さによって、ブランチの切り替えやリモートブランチをプルする手間はかなり削減できたと感じています。

ただし、マージ時にコンフリクトが発生した際は手動でコンフリクト解消を行う必要があり、ローカル環境でのマージ作業が0になったわけではありません。

どのような成果が得られたか

Branch Mergerワークフローの導入後、各リポジトリで/merge stagingコメントを見かけるようになりました。 チーム全体で活用することができています。

また、開発生産性に関するふりかえり会にて、「Branch Mergerワークフローが使いやすい」というメンバーの声も聞くことができました。

ワークフローを追加するにあたり、下記のような点に苦労しました。

• GitHub Appの設定:
  • GitHubにプッシュする際にGitHub Appから発行されたトークンを利用する必要がありました。
  • 弊社では、GitHub Actionsのpushイベントで起動するワークフローによって、ステージング環境へのデプロイを行っています。
  • GITHUB_TOKENシークレットを用いる場合、Branch Mergerワークフローによってstagingブランチをプッシュした際にpushイベントが発火せず、他のワークフローが動かないという制限があります。

  • リポジトリの GITHUB_TOKEN を使ってタスクを実行した場合、GITHUB_TOKEN によってトリガーされたイベントでは (workflow_dispatch と repository_dispatch を除きます)、新しいワークフロー実行は作成されません。 これによって、予想外の再帰的なワークフローの実行が生じないようになります。 https://docs.github.com/ja/actions/concepts/security/github_token#when-github_token-triggers-workflow-runs

  • つまり、GITHUB_TOKENシークレットを用いるとステージング環境へのデプロイができなくなってしまいます。
  • この制限を回避するため、GitHub Appを作成してそれから発行されたトークンを利用するようにしました。
• ワークフローの検証:
  • GitHub Actions ワークフローを検証するには、ワークフローのファイルをデフォルトブランチにマージしなければならない点も苦労しました。
  • 今回のワークフローはユーザーがコメントすることによって起動します。コメントの追加イベントによってワークフローを起動するには、ワークフローのファイルをデフォルトブランチにマージしなければなりません。そのため、ワークフローの検証を行うために何度もプルリクエストを作成する必要がありました。

GitHubでソースコードを管理している場合、手軽に導入することができると思うのでぜひ使ってみてください。