LIFULL Creators Blog

LIFULL Creators Blogとは、株式会社LIFULLの社員が記事を共有するブログです。自分の役立つ経験や知識を広めることで世界をもっとFULLにしていきます。

リリース作業からの完全解放!週2回のリリースが1日2回リリースへ!集約と自動化によりリリースフロー改革を実現したGitHub Actions活用法

こんにちは、LIFULLでシニアエンジニアをしている渡邉です。普段はLIFULL HOME'Sの流通領域のエンジニアチームにて、マネジメントをしています。好きなCI/CDツールはGitHub Actionsです。

以前、こちらの記事で、私たちのリリースフロー改善への取り組みをお話しました。

www.lifull.blog

あれから数ヵ月が経ち、私たちのGitHub Actions集約型リリースフローは想像以上に進化を遂げました。今回は、その変化と新しく追加された機能について、実際の開発現場での体験を交えながらお伝えします。

🚀 何が変わったのか?主要なアップデート

1. セットアップが驚くほど簡単になりました

以前は手動での設定が必要でしたが、今では対話形式のinquirerを用いたCLIツールを用意しました。

npm install
npm run setup

これだけで、チームに必要なワークフローを選択しながら自動生成できます。「どの機能を組み合わせればよいかわからない」という悩みから解放されます。

CLIを実行した様子

2. Chrome拡張機能で承認作業が格段に楽になりました

リリース承認の煩雑さを解決するChrome拡張機能を開発しました。

  • ボタン一つで承認完了: /G長承認OK/PJ承認OKのコメントがワンクリック
  • 新リリースフローの対象リポジトリにて、承認に必要なドキュメントのリンクを表示

拡張機能により提供されるもの

もう「承認コメントってどう書くんだっけ?」と悩む必要はありません。

具体例: /G長承認OKというコメントを手動で入力する代わりに、PR画面に表示される「G長承認」ボタンをクリックするだけで承認が完了します。

3. 企画担当者の方でも迷わず使えるガイドを作りました

技術に詳しくない方でも安心してリリース承認ができるよう、専用ガイドを整備しました。

  • 確認すべきポイントを4つに絞った分かりやすい説明
  • 豊富なスクリーンショットで視覚的にサポート
  • 「ここだけ見れば大丈夫!」という安心感を提供

具体例: 「Epic Issueの確認」「ビジネス観点のチェック」「PJ承認コメント」「承認状況確認」の4ステップで、技術的な知識がなくても確実に承認作業を完了できます。

4. リリース忘れを防ぐ機能を追加しました

新しく追加したRelease PR Reminder機能で、リリース日にPRが長時間未マージの場合、自動でSlack通知が送られます。

  • Google Calendarと連携してリリース日を自動判定
  • 通知タイミングは調整可能(デフォルト1日)
  • リリーサーへの確実な通知でリリース漏れを防止

5. 開発タスクの管理が自動化されました

Sub-Issue自動管理システムにより、開発タスクの進捗管理が飛躍的に向上しました。

  • 自動でタスク分解: PRに紐づく開発作業を自動で細分化
  • 進捗の可視化: 全タスク完了時に自動でラベル付与
  • 承認者も安心: 開発作業の完了状況が一目でわかる

具体例: PRを作成すると「QA仕様書作成」「デザインチェック」「開発チェックシート」などのSub-Issueが自動生成され、各タスクの完了に応じてPR上の進捗バーが更新されます。

subissueによるタスク分解

開発タスクの進捗状況の確認

6. 🎯 自動リリース機能でリリーサーの負荷がほぼゼロに

今回の最大の進化は、完全自動リリース機能の実装です。これにより、リリーサーの作業負荷が劇的に軽減されました。

自動リリースのしくみ:

  • リリース条件がすべて満たされた場合、自動的にmasterブランチへのマージ
  • ステージング環境テスト・プロダクション環境テストが完了したPRのみが対象
  • ステージング環境テスト、プロダクション環境テストが終了していない場合には開発者への訴求をGitHub上で自動通知
  • リリース後の開発者への通知も自動化
  • 1日経っても未マージのリリースPRの自動検出と通知

リリーサーのタスク変化:

  • 従来: 手動でのPRマージ、リリースしたことを開発者へ通知、確認作業の管理
  • 現在: 例外的なケースのみの対応(通常時はほぼ作業なし)

メリット:

  • 人的ミスの排除: 手動操作によるミスが完全になくなりました
  • リリース時間の短縮: 条件が整い次第、即座にリリースが実行されます
  • リリーサーの負荷軽減: 定型作業から解放され、より重要な業務に集中できます
  • 24時間対応: 人の都合に関係なく、いつでもリリースが可能です

7.使いやすさへのこだわり

見た目でわかる設計

  • ラベルによる可視化: 承認状況がPRのラベルで即座にわかる
  • 進捗バー: タスク完了率を視覚的に表示
  • ステータスアイコン: 一目で状況を把握できる

自動化されたリリースプロセスにおける課題を解決するためのしくみ

  • 自動導入: リリースフローのワークフローを導入する際にCLIを利用して導入することで、手続的にリポジトリナイズされた設定を施したうえで導入が可能
  • 権限管理: 承認、マージする際には適切な権限を持つ人のみが実施可能
  • 自動チェック: リリースに必要な開発タスクや、リリースチェックなど実施すべき項目が適切に行われていることをワークフローにより自動的にチェック
  • 通知の強化: あらゆるリリースに関する通知を自動化し、人間による通達漏れを排除
  • リリース依存性の担保: リリース順序が決まっているマイクロサービスにおけるリリース順序が逆転しないようにするための依存先のリリースストップ機能
  • 強行リリース: 何らかの理由によりワークフローが失敗し続ける際や、承認をまたずリリースしたいものがある場合のための承認者による強制リリースの実行方法の確立

グローバルチームにも対応

  • 日本語・英語両対応のドキュメント
  • 国際的なチームでも安心して利用可能

実際の開発現場での変化

導入前の悩み

  • 「承認コメントの書き方がわからない...」
  • 「どのタスクが終わっているか把握できない...」
  • 「リリース日なのにPRがマージされてない!」
  • 「企画の人にGitHubの使い方を説明するのがたいへん...」
  • 「リリーサーが忙しくてリリースが遅れる...」

導入後の声

  • 「ボタン一つで承認が終わるなんて!」
  • 「タスクの進捗が自動で更新されるから楽」
  • 「リリース忘れがなくなった」
  • 「企画の人も迷わず承認してくれる」
  • 「リリーサーを待つ必要がなくなった!」

🎉 実際の導入効果:数字で見る劇的な改善

リリース頻度の大幅向上

導入後、1日に2回のリリースが可能になりました。従来は承認プロセスの複雑さから週1-2回程度だったリリースが、自動化により大幅に増加。これにより、ユーザーへの価値提供スピードが格段に向上しています。

リリース数の変化

承認からリリースまでの時間短縮

承認からリリースまでの時間が劇的に短縮されました。従来は承認後数日かかっていたリリースが、現在では承認と同日、場合によっては数時間以内にリリースが完了するケースも増えています。

リリースまでのリードタイムの変化

企画担当者にもわかりやすい

専用ガイドとChrome拡張機能により、技術的な知識がなくても確実に承認作業を完了できるようになりました。

自動マージ機能の効果

開発チームでは自動マージ機能が特に高く評価されています。

自動マージには、承認が完了したPRが自動的にステージング環境でマージされる機能と自動的にリリースを行う機能の2つが用意されています。

条件の整ったPRが自動的にマージされることで、リリーサー、開発者の待ち時間が大幅に削減され、より重要な開発作業に集中できます。

通知システムの効果

リアルタイム通知システムにより、リリース状況の把握が格段に向上しました。関係者全員がリリースのタイミングを正確に把握できるようになり、連携ミスが大幅に減少しています。

あらゆるリポジトリ形態に対応

私たちが特に重視したのは、どのような形態のリポジトリでも問題なく使える汎用性です。

  • モノリスアプリケーション: 単一リポジトリでの大規模開発
  • マイクロサービス: 複数の小さなサービスに分かれた構成
  • フロントエンド・バックエンド分離: 異なる技術スタックでの開発
  • ライブラリ・SDK: ほかのプロジェクトから利用されるコンポーネント

どのような開発スタイルでも、チームが同じ操作感でリリース管理を行えるよう設計しています。

柔軟な導入アプローチ

私たちが特に意識したのは、「チームの状況に合わせて必要な機能だけを選んで導入できる」ということです。

ユースケースに合わせた導入方法の提供

  1. 承認フローの改善: G長・PJ承認をGitHub上で完結
  2. 開発タスク管理: Issue駆動開発でタスク管理を自動化
  3. リリースチェック: 本番・検証環境での確認作業を体系化
  4. 完全自動化: リリーサー不要の自動リリースを実現
  5. メンテナンス性: 自動バージョンアップ機能の提供

どの段階でも確実に開発体験が向上するよう設計しています。

自動リリースがもたらした革命的変化

リリーサーの役割の変化

従来のリリーサーの1日:

  • 午前中: リリース予定PRの確認
  • 昼ごろ: リリースの実施と開発者への通知
  • 夕方: リリースチェック作業の確認

現在のリリーサーの1日:

  • 午前、午後: システムからの自動通知を確認(必要時のみ)
  • 例外ケース発生時のみ対応
  • 通常時はほかの業務を行い、リリース作業は実施せず

組織全体への影響

  • 開発速度の向上: リリーサーの都合を待つ必要がなくなり、定刻にリリースできるようになりました
  • 品質の安定: 人的ミスが排除され、リリース品質が向上しました
  • コスト削減: リリース作業にかかる人的コストが大幅に削減されました
  • ストレス軽減: リリース日の緊張感が大幅に軽減されました

これからの展望

私たちの目標は変わりません。

  1. リリース関連作業の一元管理
  2. 自動チェックによる作業負荷軽減
  3. 最終的なリリーサー不要の実現

今回のアップデートで、この目標の大部分を達成できたと感じています。特に自動リリース機能により、「リリーサー不要」という最終目標にかなり近付きました。残りの部分も、社内のプロダクト運用チームからのフィードバックを元に継続的に改善していきます。

まとめ

今回のアップデートにより、私たちのGitHubリリースフロー自動化は、単なる「効率化ツール」から「開発体験を根本から変えるシステム」へと進化しました。

特に自動リリース機能の導入により、リリーサーの作業負荷がほぼゼロになったことは、私たちの想像を超える効果をもたらしました。実際の導入現場では、1日2回のリリースが可能になり、承認からリリースまでの時間が劇的に短縮されるなど、具体的な成果が現れています。

技術者も、企画者も、リリーサーも、全員が「使っていて気持ちよい」と感じられるシステム。それが私たちの目指した姿であり、今回のアップデートで大きく近付けたと確信しています。

もしチームでリリース作業に課題を感じているなら、ぜひ一度試してみてください。きっと、リリース作業に対する考え方が変わるはずです。

私たちは今後も、実際のユーザーフィードバックをもとにした継続的な改善を続けていきます。より多くのチームが、この「未来のリリース体験」を享受できるよう、取り組みを続けてまいります。

今後も一歩ずつ改善を積み上げることで、リリースのさらなる加速化につなげていければと思います。

最後に、LIFULL ではともに挑戦し成長していける仲間を募集しています。よろしければこちらのページもご覧ください。

hrmos.co

hrmos.co