KTC 27インチ QD-MiniLED 4K UHD 量子ドットゲーミングモニター|デュアルモード技術 320Hz/160Hz|HDR1400|Type-C 65W|HDMI2.1/DP1.4|Adaptive Sync|フリッカーフリー対応(DC調光)| KVM対応|145% sRGB|フル装備のエルゴノミクス機能 | PS5で120 Hz(VRR)対応 | 3年保証 M27P6
(2025年4月26日 13:07 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)【Amazon.co.jp限定】 バッファロー WiFi ルーター 無線 LAN Wi-Fi 6 11ax AX3000 2,401+573Mbps 日本メーカー 【 iPhone 16e / 16 / 15 / 14 / Nintendo Switch / PS5 動作確認済み 】 スマート 引っ越し エコパッケージ ブラック WSR-3000AX4P/NBK
¥9,980 (2025年4月26日 13:07 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)
メグリ株式会社のモバイルアプリチームでは、以下のような Git flow もしくは GitHub flow を模したブランチ運用を採用しています。
このブランチ管理では、main (古いリポジトリでは master) ブランチに、現在ストア公開されているアプリの内容が反映されていて、develop ブランチは開発中の最新情報が反映されるようにしています。
アプリを新しくストア申請する際には、まず releaseブランチを作成し、そのブランチ上で必要なアプリバージョンを設定して、申請用のアプリをビルドしています。
これまでアプリがストア公開された際には、releaseブランチを手動で main と develop にマージしていました。しかしリリースが頻繁になるにつれて、手動作業によるマージ漏れや遅延のリスクが無視できなくなりました。
特に、ビジネスサイドの制約でストア公開時期が変わるため、releaseブランチの作成タイミングと実際のストア公開のタイミングがズレることが頻繁にあり、マージ作業が忘れがちという問題がありました。
また、ストア公開したアプリに不具合があった場合は、mainブランチからhotfixのブランチを作成して対応するため、mainブランチは常に最新の内容が反映されている必要があります。
幸い、現在の開発フローでは、releaseブランチへのpushをトリガーとして、自動的に main ブランチへのPull Requestが作成される仕組みがあります。この仕組みをさらに発展させ、ストア公開をトリガーとして Releaseブランチを自動で main と develop にマージする運用をGitHub Actionsで実現しました。本記事ではその背景と実装の詳細を紹介します。
手動マージには以下の課題がありました。
- 時間的コスト: リリースの度にエンジニアや関係者の工数が発生
- 人的ミス: マージ漏れ、タグ付け忘れ、ブランチ間違いなど
- 属人化: 担当者による対応遅延や実施内容の差異
これらを解決するため、GitHub Actionsを利用してストア公開を監視し、対象ブランチを自動的にマージするなどのクロージング作業を自動化しました。
Play Console の API や App Store の API を利用してストア公開を検知する方法も検討しましたが、クライアントごとにアカウントの管理方法が異なり、統一的にAPIを利用することが難しかったため、定期的にストア情報をチェックする方法を採用しました。
ストア公開バージョンの取得方法
ストア公開されたアプリのバージョンを監視するため、AndroidアプリとiOSアプリのそれぞれについて、以下のようなPythonスクリプトを実装しています。
Androidアプリの場合(Google Play)
Pythonの google-play-scraper を利用して最新バージョンを取得します。
from google_play_scraper import app
def get_android_version(package_name):
"""
Get app version from Google Play
"""
result = app(package_name)
return result['version']
latest_version = get_android_version('com.example.app')
print(latest_version)
iOSアプリの場合(App Store)
iTunes Search APIを利用して最新バージョンを取得します。
import requests
def get_app_version(bundle_id):
"""
Get app version from App Store
"""
base_url = "https://itunes.apple.com/lookup"
params = {
"bundleId": bundle_id,
"country": "JP"
}
response = requests.get(base_url, params=params, timeout=(10.0, 10.0))
data = response.json()
if data["resultCount"] == 0:
return "not_found"
app_info = data["results"][0]
return app_info["version"]
latest_version = get_app_version('com.example.app')
print(latest_version)
実装の詳細
実装した自動化の流れは以下の通りです。
- 定期的実行: 毎日決まった時刻にGitHub Actionsが起動
- ストアの最新バージョンを取得: 上記の方法でGoogle Play/App Storeから公開バージョンを取得
- releaseブランチ存在確認: 取得したバージョンのreleaseブランチのPRがGitHub上に存在するかを確認
- main へのマージ: 該当するPRがあれば自動でマージ
- develop へのマージ: main マージ成功後に自動マージ
- Slack通知: マージ結果をSlackに通知
主要スクリプト(概要)
自動マージの核となるスクリプト の要点は以下の通りです。
- リポジトリをクローンして最新バージョン取得
- 対応するreleaseブランチとPRの存在を確認
- GitHub CLIでPRを自動マージ
- マージ結果をSlackに通知
主要コードの抜粋
# PR番号を取得
pr_number=$(gh pr list --base $main_branch --head release/v${version} --state open --json number --limit 10 2>/dev/null | jq -r '.[0].number // empty')
# PRが見つからなかった場合の処理
if [[ -z "$pr_number" || ! "$pr_number" =~ ^[0-9]+$ ]]; then
echo "No valid PR found."
exit 0
fi
# PRをマージ
if gh pr merge $pr_number --merge; then
echo "PR $pr_number merged successfully."
else
echo "Failed to merge PR $pr_number."
exit 1
fi
スクリプト内で参照している変数version
は前述したストア公開バージョン取得のスクリプトを利用して設定しています。
GitHub Actionsワークフローの設定
ワークフローの具体例は以下です。
- 毎日2回ほど定期実行
- 手動実行にも対応
- 対象リポジトリに対してBashスクリプトを実行
主要コードの抜粋
on:
workflow_dispatch:
schedule:
- cron: '0 9,21 * * *' # JSTで18:00, 6:00
jobs:
auto-pr-merger:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: merge release PRs
run: |
bash run.sh
env:
GH_TOKEN: ${{ secrets.GH_TOKEN }}
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
運用してみての効果
この仕組みを導入したことで、以下のようなメリットがありました。
-
工数削減: PRをマージするタスクがなくなった(ビジネスサイドによる公開の通知、それに伴うエンジニアの手動マージ作業など)
-
人的ミス削減: 自動化による安定運用
-
安定した開発フロー: 常に最新の状態を保持
以下の記事にも記載しましたが、これらの自動化で各種アプリの最新バージョンを把握することが容易になりました。
以下のように社内ではDocbaseとGoogleスプレッドシートに情報を集約していますが、今回の対応によって、エンジニアに限らず関係者が簡単に最新アプリバージョンを把握することができるようになりました。
GitHub Actionsを活用することで、煩雑な手動マージ作業を効率化し、より快適な開発環境を実現できました。今後も積極的にGitHub Actionsを活用して効率化を模索していこうと思います。
メグリでは、こうした開発環境の改善や自動化、生成AIの活用に興味があるエンジニアを募集しています。
GitHub Actionsを始めとする最新技術を活用した効率的な開発環境の構築に加えて、モバイルアプリ開発、サーバサイド開発に興味がある方はぜひ以下のページをご覧ください。
カジュアル面談も随時実施していますので、お気軽にお問い合わせください。