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.