【要約】Macだけで Google Play 製品版まで1コマンド ― fastlane不要・Developer API直叩き（Flutter） [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
個人開発者が、Flutterアプリのリリース作業において、手動操作の繰り返しによる非効率性に直面している。アプリの数が増えるにつれ、以下の課題が顕在化する。
- ・Android Studioでのビルド、Play Consoleへの手動アップロード、リリースノート入力の繰り返し。
- ・fastlane等のツール利用時における、Ruby/gemの依存関係増大と動作のブラックボックス化。
- ・Google側のAPI仕様変更に対し、既存ツールでは追従が困難になるリスク。
// Approach
開発者が、依存関係の複雑化を避けるため、Google Play Developer APIをPythonで直接操作する手法を採用した。具体的には以下のステップで実装している。
- ・
google-api-python-clientを用い、APIのedit（トランザクション）機能で一連の操作を管理。 - ・重いビルド処理の前に、リリースノートの500字上限をチェックするPre-flight処理を実装。
- ・サービスアカウントのJSON鍵を用い、aabのアップロードから製品版トラックへの更新、コミットまでを自動実行。
// Result
開発者が、ビルドから製品版公開までのプロセスを、ターミナルから1コマンドで完結できるようになった。これにより以下の成果が得られる。
- ・
python3 store_submit.py androidの実行のみで、リリース作業が完結。 - ・リリースノートの文字数超過による、ビルド後のAPIエラー（HTTP 403）を未然に防止。
- ・API仕様変更に対し、自身のコードを修正することで迅速かつ確実に追従可能。
Senior Engineer Insight
> 抽象化されたツールに頼らず、APIを直接制御する設計は、トラブルシューティングの観点から極めて合理的だ。特に
editによるトランザクション管理は、不完全な状態での更新を防ぐ堅牢な設計と言える。ただし、Google Playの「12人・14日間のクローズドテスト」のような、API外のポリシー制約を理解していなければ、自動化の恩恵を享受する前に躓く。ツール作成においては、こうした「API外の仕様」を考慮した運用設計が不可欠である。