チュートリアル

ステップ 1

デモを実行する

前提: Node.js 20.12 以上 — クローンも、インストールも、認証情報も 不要です。

$ npx storepulse demo

デモボードには、実際のチームを模したサンプルデータが入っています — アプリ 2 つ、それぞれ prod・dev のバリアント、両プラットフォーム。 今後目にするバッジがすべて揃っています: LIVE, 50%(段階的リリース), REVIEW, REJECTED, draft。ブラウザで見たい場合は npx storepulse serve --demo が同じボードを 127.0.0.1:4780 で開きます。

ステップ 2

アプリを登録する

$ npx storepulse init

どのフォルダでも使えます — storepulse.config.json と .env のテンプレートを作成し(既存のファイルは 上書きしません)、認証情報ファイルを .gitignore に 追加します。このリポジトリのクローンなら cp storepulse.config.example.json storepulse.config.json でも同じです。続いて storepulse.config.json を開き、 アプリを登録します:

ステップ 3

Apple — App Store Connect API キー

ここからは storepulse init が作った .env を 埋めていきます(リポジトリのクローンなら cp .env.example .env)。

1. App Store Connect → ユーザーとアクセス(Users and Access) → 統合(Integrations) → App Store Connect API へ。
2. チームキー(Team Keys)で ＋ をクリック。ロールは Developer を推奨します — storepulse が読む範囲にはこれで十分です。App Manager でも動作しますが、キーが漏えいするとアプリの提出やメタデータの変更まで可能になるため、最小権限が安全です。
3. .p8 ファイルをダウンロードします。 Apple がダウンロードを許すのは一度きり — 大切に保管してください(storepulse init が既に git 管理外にしています)。このキーはロールが許す範囲で書き込みもできる認証情報なので、万一漏えいしたら App Store Connect で直ちに失効(revoke)させてください。
4. 3 つの値を埋めます:

ASC_KEY_ID=ABC123DEFG          # キーの "Key ID" 列
ASC_ISSUER_ID=xxxxxxxx-...     # ページ上部の "Issuer ID"
ASC_PRIVATE_KEY_PATH=./AuthKey_ABC123DEFG.p8

コンソールの画面はときどき変わります — メニューの場所が違うときは、 Apple の公式ガイド Creating API Keys for App Store Connect API に従ってください。

ステップ 4

Google — Play サービスアカウント

1. Google Cloud Console で プロジェクトを選ぶか新規作成し、Google Play Android Developer API を有効にします。
2. IAM と管理 → サービスアカウント → 1 つ作成(ロールは不要)→ キータブ → 鍵を追加 → JSON。
3. Play Console → ユーザーと権限 → 新しいユーザーを招待 → サービスアカウントの メールアドレス(…@…iam.gserviceaccount.com)を貼り付け → アプリにアプリ情報の表示(View app information)権限を付与します。 付与するのはこの権限だけにしてください — リリース(公開)系の権限は決して付与しないでください。 storepulse には不要ですし、こうしておけばキーが漏えいしても 読み取り専用のままで済みます。
4. .env にその JSON を指定します:

PLAY_SERVICE_ACCOUNT_PATH=./service-account.json

コンソールの画面構成が変わっていたら、Google の公式ガイド Google Play Developer API スタートガイドで 同じ手順を確認できます。

ステップ 5

実行

$ npx storepulse

あなたの実際のボードが現れます(リポジトリのクローンでは pnpm status でも同じです)。認証情報に問題のある行は、 その場所にエラーを表示するだけで、ボードの残りを隠すことはありません。

ステップ 6

Web ダッシュボードで見る

$ npx storepulse serve

http://127.0.0.1:4780 を開くと、 ボードが自動更新される Web ダッシュボードとして表示されます。設定に任意の group があれば一度に 1 グループを選べ、どのアプリにも グループがなければセレクターは表示されません。アプリカードごとに iOS と Android の行、最新バンドル、配信チャネルが分かれ、OS チップで プラットフォーム行を絞り込めます。行をクリックすると、リリースノート全文・ 日付・TestFlight の期限カウントダウンを含む詳細パネルが開きます。行ではなく状態バッジを クリックするとその状態の意味を説明するダイアログが開き、ヘッダーの EN/KO スイッチャーで表示言語も切り替えられます(選択はブラウザに 記憶されます)。認証情報がまだなら npx storepulse serve --demo でも大丈夫です。デフォルトでは 127.0.0.1 にのみバインドします — ボードには未公開の バージョンが並ぶことがあるので、ローカルに留めておくのが安全です。

ステップ 7 — 任意

Expo(EAS)ビルドをつなぐ

Expo でリリースしていますか? .env にアクセストークンを 追加し(expo.dev → Access tokens で作成できます。組織なら View Only の ロボットトークンを推奨します — storepulse はビルドと提出を読むだけ です)、storepulse.config.json の Expo アプリの項目に easProjectId(app.json → extra.eas.projectId)を書きます:

EAS_TOKEN=...

これで、スナップショット(JSON)と Web ダッシュボードの詳細パネルが、 ストアの各バージョンがどの EAS ビルドから生まれたのかを表示します — コミット、ビルドプロファイル、提出ステータスまで(ターミナルの ボードは要約のままです)。npx storepulse doctor の [5] セクションが EAS チェーン全体を点検します。

CI — 任意

リリース状態でビルドを失敗させる

$ npx storepulse check --fail-on rejected,halted

正規化された状態 live、rollout、 in-review、pending、rejected、 halted、draft、unknown を指定できます。 終了コード 0 は該当なし、1 はポリシー違反、 2 は不正な引数または収集エラーです。機械可読の出力には --format json、認証情報なしの試用には --demo を 追加してください。

トラブルシューティング

何かがおかしいとき

まずは npx storepulse doctor を実行してください — 下記の原因の大半を自動で診断し、失敗した項目ごとに一行の解決策を示します。

それでも詰まったら、issue を立ててください — ボードに出たエラー行をそのまま貼っていただければ大丈夫です。