gplay-release-flow
End-to-end release workflows for Google Play tracks (internal, beta, production) using gplay release, promote, and rollout commands. Use when asked to upload a build, distribute to testers, or release to production.
摘要
- 用途
- 透過 gplay CLI 協調 Google Play 上的應用程式發布、測試軌道升級與分階段推出。
- 使用時機
- 當需要為特定測試或正式版軌道準備版本、升級已測試版本,或調整分階段推出比例時使用。
- 輸出結果
- 將 AAB 或 APK 上傳至指定的 Play 軌道,並可同步版本說明、商店資訊與螢幕截圖,或變更既有版本的軌道或推出狀態。
上游變更(3 筆,最新收錄 2026-07-04)
439c9ae fix(skills): audit cleanup — correct every command, cut dead weight, add drift guardrail (#3) 此技能指南將 rollout 範例與說明從百分比數值改為 0–1 小數,更新了 track 與 release notes 的指引,並將手動更新 track 的範例改為使用 `--releases`。 f8592d5 feat: add skills for v0.4.2 new commands (vitals, users, migrate) 此指南新增 dry-run 與 metadata/listing/screenshot 發布範例,擴充 release notes 和旗標說明,並新增 dry-run 檢查清單項目及結合 metadata 與 dry-run 的發布策略。 acb31df Initial commit: Google Play CLI Skills repository 初始技能指南說明了前置條件、端對端與手動發布流程、track 升級、分階段推出、release notes、發布前檢查及發布策略。 npx skills add "lettucebo/Skills#v2.2.0@gplay-release-flow" --full-depth ⚠ v2.2.0 發布後即可使用
Release flow (Internal, Beta, Production)
Use this skill when you need to get a new build onto Google Play Store.
Preconditions
- Ensure credentials are set (
gplay auth loginorGPLAY_SERVICE_ACCOUNTenv var). - Build must be an AAB (App Bundle) or APK.
- Version code must be higher than previous releases.
- Service account needs "Release Manager" permission in Play Console.
Android Release
Preferred end-to-end commands
Internal track (for internal testing):
gplay release \
--package com.example.app \
--track internal \
--bundle app-release.aab
Beta track (for beta testers):
gplay release \
--package com.example.app \
--track beta \
--bundle app-release.aab \
--release-notes @release-notes.json
Production with staged rollout (gradual release):
gplay release \
--package com.example.app \
--track production \
--bundle app-release.aab \
--release-notes @release-notes.json \
--rollout 0.1
Dry run (preview the release without executing):
gplay release \
--package com.example.app \
--track production \
--bundle app-release.aab \
--dry-run
Release with metadata (listings and screenshots)
Include store listings from a directory:
gplay release \
--package com.example.app \
--track production \
--bundle app-release.aab \
--listings-dir ./metadata \
--screenshots-dir ./metadata
Skip metadata or screenshots:
# Upload bundle only, skip metadata sync
gplay release \
--package com.example.app \
--track production \
--bundle app-release.aab \
--skip-metadata
# Upload bundle and metadata, skip screenshots
gplay release \
--package com.example.app \
--track production \
--bundle app-release.aab \
--listings-dir ./metadata \
--skip-screenshots
Combine listings and screenshots directories:
gplay release \
--package com.example.app \
--track beta \
--bundle app-release.aab \
--listings-dir ./metadata/listings \
--screenshots-dir ./metadata/images \
--release-notes @release-notes.json
Manual sequence (when you need more control)
Create edit session:
EDIT_ID=$(gplay edits create --package com.example.app | jq -r '.id')Upload bundle:
gplay bundles upload \ --package com.example.app \ --edit $EDIT_ID \ --file app-release.aabUpdate track:
gplay tracks update \ --package com.example.app \ --edit $EDIT_ID \ --track production \ --releases @releases.json--releasestakes a JSON array of track releases (or@file).Validate edit:
gplay edits validate --package com.example.app --edit $EDIT_IDCommit edit (publishes changes):
gplay edits commit --package com.example.app --edit $EDIT_ID
Track Promotion
Promote a release from one track to another:
# Promote from internal to beta
gplay promote \
--package com.example.app \
--from internal \
--to beta
# Promote from beta to production with 25% rollout
gplay promote \
--package com.example.app \
--from beta \
--to production \
--rollout 0.25
Staged Rollout Management
Start with a 10% rollout (fraction 0.1):
gplay release \
--package com.example.app \
--track production \
--bundle app.aab \
--rollout 0.1
Increase to 50% (fraction 0.5):
gplay rollout update \
--package com.example.app \
--track production \
--rollout 0.5
Halt rollout (pause distribution):
gplay rollout halt --package com.example.app --track production
Resume rollout:
gplay rollout resume --package com.example.app --track production
Complete rollout (release to 100%):
gplay rollout complete --package com.example.app --track production
Release Notes Format
The single --release-notes flag accepts three shapes: a JSON array (multi-locale), plain text (auto-assigned to en-US), or an @file path pointing to either. There is no separate locale flag.
JSON array format (multi-locale)
release-notes.json — a JSON array of {language, text} entries:
[
{ "language": "en-US", "text": "Bug fixes and performance improvements" },
{ "language": "es-ES", "text": "Correcciones de errores y mejoras de rendimiento" },
{ "language": "fr-FR", "text": "Corrections de bugs et améliorations des performances" }
]
Pass it with --release-notes @release-notes.json.
Plain text format (single locale)
Provide release notes as plain text — it is auto-assigned to en-US:
gplay release \
--package com.example.app \
--track beta \
--bundle app.aab \
--release-notes "Bug fixes and performance improvements"
Or from a file (plain text or a JSON array) with @:
gplay release \
--package com.example.app \
--track beta \
--bundle app.aab \
--release-notes @release-notes.txt
Release Flags Reference
| Flag | Description |
|---|---|
--package |
App package name (required) |
--track |
Target track (production, beta, alpha, internal; default: internal) |
--bundle |
Path to AAB file (use --bundle or --apk, not both) |
--apk |
Path to APK file (alternative to --bundle) |
--release-notes |
Release notes: plain text (auto-assigned en-US), a JSON array of {language, text}, or @file |
--rollout |
Staged rollout fraction (0.0-1.0, default: 1.0 for full rollout) |
--listings-dir |
Directory containing store listings to sync |
--screenshots-dir |
Directory containing screenshots to upload |
--skip-metadata |
Skip metadata/listings sync during release |
--skip-screenshots |
Skip screenshots upload during release |
--dry-run |
Preview the release without executing |
--output |
Output format (json, table, markdown) |
Pre-release Checklist
Before releasing, verify:
- Version code is incremented
- AAB/APK is signed with correct keystore
- ProGuard/R8 mapping files uploaded (for crash reports)
- Release notes written for all locales
- Testing completed on internal/beta track
- Service account has correct permissions
- Dry run passes:
gplay release ... --dry-run
Common Release Strategies
Strategy 1: Internal -> Beta -> Production
# Week 1: Internal
gplay release --package com.example.app --track internal --bundle app.aab
# Week 2: Beta (after testing)
gplay promote --package com.example.app --from internal --to beta
# Week 3: Production with staged rollout
gplay promote --package com.example.app --from beta --to production --rollout 0.1
gplay rollout update --package com.example.app --track production --rollout 0.5 # Day 2
gplay rollout complete --package com.example.app --track production # Day 7
Strategy 2: Direct to Production with Staged Rollout
# Day 1: 10%
gplay release --package com.example.app --track production --bundle app.aab --rollout 0.1
# Day 2: 25%
gplay rollout update --package com.example.app --track production --rollout 0.25
# Day 3: 50%
gplay rollout update --package com.example.app --track production --rollout 0.5
# Day 7: 100%
gplay rollout complete --package com.example.app --track production
Strategy 3: Full release with metadata and dry-run verification
# 1. Dry run to verify everything
gplay release \
--package com.example.app \
--track production \
--bundle app.aab \
--listings-dir ./metadata \
--screenshots-dir ./metadata \
--release-notes @release-notes.json \
--rollout 0.1 \
--dry-run
# 2. Execute the release
gplay release \
--package com.example.app \
--track production \
--bundle app.aab \
--listings-dir ./metadata \
--screenshots-dir ./metadata \
--release-notes @release-notes.json \
--rollout 0.1
Notes
- Always use
--helpto verify flags for the exact command. - Use
--output tablefor human-readable output; default is JSON. - For CI/CD, use
GPLAY_SERVICE_ACCOUNTenvironment variable. - Upload deobfuscation files after each release for crash symbolication.
- Use
--dry-runin CI to validate releases before actual deployment.