手動では動くものの、チームで繰り返しリリースが必要になった途端に脆弱になるデプロイパイプラインに直面していませんか？開発者がbundleを作成し、ノートPCからuploadし、dashboardを確認して、channelを切り替え、その後に採用データを待つ。このプロセスは小規模なプロジェクトなら耐えられますが、複数のアプリ、環境、デプロイジョブが同じインフラを共有する場合、回避可能なリスクを生みます。
有用な API 公開リストは、「どのエンドポイントが存在するか」以上の答えを示すべきです。認証、リソース識別子、リリース状態、クォータ、ヘッダー、リトライ、バッチワークフローがどのように組み合わさるかを示す必要があります。本ガイドでは、単発のテストリクエストではなく、CI/CD自動化を構築する Capacitor チームに適用できるパターンを用い、運用的な観点から Capgo API にアプローチします。
目次
- Capgo API 認証の理解
- API 認証情報の生成
- アプリ管理の主要エンドポイント
- リリースの作成と管理
- チャネル戦略とロールアウトパターン
- モニタリングと診断のエンドポイント
- レート制限とセキュリティヘッダー
- よくある API エラーのトラブルシューティング
Capgo API 認証の仕組み
最初の統合で最も多いミスは、正しいリクエストを誤った認証形式で送ってしまうことです。ダッシュボードからコピーしたキーがそのまま bearer token になるわけではなく、また、リクエストにヘッダーが含まれていない、あるいは誤ったスキームで送信されている場合、bearer token は機能しません。 Authorization その場合、サーバーはエンドポイントやペイロード、アプリ識別子を評価する前に、認証エラーを返します。
まずは現在の Capgo API ドキュメントでその認証情報がどのように呼ばれているかを確認し、例示されているリクエストを正確に再現してください。一般的な bearer token リクエストでは、authorization ヘッダーは以下のパターンに従います。
Authorization: Bearer YOUR_TOKEN
ローカルでのテスト中は、認証情報を環境変数に保持してください。CI/CD では、リポジトリへのコミットやモバイル bundle への埋め込み、クエリ文字列への追加は避け、プラットフォームの secret store を介して注入してください。デバイスに配信されるものは最終的に解析される可能性があるため、モバイルアプリ内に管理用の認証情報を含めてはいけません。
アイデンティティと認可を分離する
認証（Authentication）は「誰がリクエストしているか」を特定し、認可（Authorization）は「そのユーザーが何を変更できるか」を決定します。デプロイサービスを設計する際は、これらを別々のチェック項目として扱ってください。
個人用のキーは検証には便利ですが、本番環境の自動化を特定の個人のアカウントに依存させてしまいます。共有のパイプラインには、組織が他のジョブを中断せずにキーの失効や更新ができることを前提として、チーム管理のキーを使用するのが適切です。また、ダッシュボードや権限モデルが分離をサポートしている場合は、開発、ステージング、本番のワークフローごとに個別の認証情報を使用してください。
リリース用のエンドポイントを呼び出す前に、リスクの低い読み取り操作でテストを行ってください。以下の点を確認しましょう：
- ホストが正しいか： アクティブな環境に対してドキュメント化されている API のベースURLを使用してください。
- ヘッダーが完全か： 必要な認証スキームと、
AcceptJSONレスポンス用のヘッダーを含めてください。 - ボディが正しくエンコードされているか： Send
Content-Type: application/json送信してください。 - スコープは十分か： アプリのメタデータを読み取れる認証情報であっても、リリースの作成や配布は許可されない場合があります。
- レスポンスは安全にログ出力されます： ステータスコードとリクエストIDは記録しますが、キー、トークン、bundleの内容、および機密性の高いデバイスデータは伏せ字にします。
公開 API カタログは、単なるディレクトリから運用上のディスカバリーツールへと進化してきました。 ProgrammableWebの履歴によると、 あるディレクトリは、 2018年1月時点で19,000件のAPIを通過しました。これは、 2017年に2,294件の新しいAPIが追加され、 その後、年間平均で 2,000件以上の追加が 2014年1月以降続いてきた結果です。この歴史こそが、現代の公開 API リストには、単にURLを見つけるだけでなく、エンジニアが統合時の挙動を評価できる機能が必要である理由を物語っています。
クライアント側のアクセス制御に関する詳細は、以下を参照してください： Capgo のアプリ認可パターン。ここでも同様の原則が適用されます。管理用クレデンシャルは信頼できるサーバーに保持し、権限を慎重に定義し、認可エラーが発生した際に原因を特定しやすくしてください。
API クレデンシャルの生成方法
クレデンシャルの作成は、単なるセットアップ作業ではなく、アクセス管理の変更として扱うべきです。ダッシュボードのラベルは変更される可能性があるため、最新の Capgo インターフェースとドキュメントを正として参照してください。ただし、ワークフロー自体は一貫しています。
用途別のキーを作成
組織またはアカウントの設定エリアを開き、API または developer-credentials 画面を見つけて、キー作成のアクションを選択します。キーには、ステージング用のデプロイパイプラインや本番リリースのワーカーなど、その役割を特定できる名前を付けてください。チーム変更時に所有者が不明確になるのを防ぐため、個人名のみに基づいた名前付けは避けてください。
そのワークフローに必要な最小限の権限を選択してください。デプロイ状況の読み取りのみを行うジョブに、アプリの削除やチャネルの変更権限を与えるべきではありません。インターフェースで組織レベルとアプリレベルのスコープが選択できる場合は、業務を遂行できる範囲内でより狭い境界を選択してください。
ダッシュボードに表示されたら、すぐにシークレットをコピーしてください。多くのクレデンシャルシステムでは、作成時のみ完全な値が表示されます。値を CI/CD のシークレットマネージャーに保存し、パイプライン内で値をログに出力せずに取得できるかテストしてください。ローカル .env ファイルは開発時に役立ちますが、バージョン管理からは除外し、Capacitor webディレクトリにバンドルされないようにしてください。
ダウンタイムなしでローテーション
認証情報のローテーション時は、重複期間を設けてください。新しい値をシークレットストアに追加し、それを使用するパイプライン設定をデプロイして、問題のない認証読み取りを実行した後に、古いキーを無効化します。サービスが複数の有効なキーをサポートしている場合は、すべてのワーカーやスケジュールジョブが移行するまで、古い値を保持しておいてください。
チーム運用では、キーの所有者、目的、環境、作成日、および失効手順を内部のアクセス管理台帳に記録してください。その際、シークレット自体は台帳に記載しないでください。これにより、ドキュメントが別のシークレットリポジトリ化することを防ぎつつ、インシデント対応を実用的なものにできます。
この 英国政府の API 標準 OpenAPIドキュメントの早期設計、入力値のバリデーション、未知の属性の拒否、TLS 1.2以上の使用、およびアクセス制御へのOAuth 2.0の適用を推奨しています。これらの原則は、統合に API キーを使用する場合でも有用です。自動化を構築する前にコントラクトを定義し、予期しない入力を拒否し、トランスポートセキュリティを不可欠なものとして扱ってください。
パイプラインのストレージおよびローテーションパターンについては、以下を参照してください： CI/CDパイプラインにおけるシークレット管理の Capgo ガイダンス.
アプリ管理の主要エンドポイント
アプリ管理は、以降のすべてのプロセスのコントロールプレーンとなります。リリース作成、チャネル割り当て、bundle配布、診断には、すべて安定したアプリケーション識別子が必要です。よくある間違いは、人間が読みやすいアプリ名を各ジョブに渡し、それが一意であり続けると想定してしまうことです。アプリは一度だけ解決し、正規の識別子を保持して、その後の操作には常にその識別子を使用してください。
本番環境への統合では、アプリのライフサイクルを以下の4つの機能に基づいてモデル化すべきです：
| 運用 | HTTPインテント | 統合に関する事項 |
|---|---|---|
| アプリケーション一覧の取得 | GET |
ページネーション、組織スコープ、安定した識別子 |
| アプリケーション詳細の取得 | GET |
設定バージョンとデプロイの関係性 |
| 設定の更新 | PATCH またはドキュメント化された更新メソッド |
部分的な変更か、フルリプレイスか |
| アプリケーションの削除 | DELETE |
取り消し不能な操作です。承認および監査コントロールが必要です |
ブログ記事や古い SDK からエンドポイントのパスを推測しないでください。最新の機械判読可能な定義を読み取り、そのコントラクトから型定義されたクライアントやリクエストラッパーを生成してください。 OpenAPI 仕様書 は、HTTP APIのためのプログラミング言語に依存しないフォーマットを定義します。これにより、ソース code やネットワークトラフィックを調査することなく、エンドポイント、認証、リクエストスキーマ、レスポンス、および挙動を人間やツールが発見できるようになります。
識別子ファーストのワークフローを構築
デプロイメントワーカーは、ミューテーションを実行する前に必ず読み取り操作を行うべきです：
- 組織とアプリケーションのコンテキストを解決します。
- アプリのレコードを取得し、想定通りのアカウントに属していることを確認します。
- 対象のプラットフォームと環境を、返された設定と比較します。
- ジョブの状態に正規のアプリ識別子を保存します。
- その識別子を使用して、リリースまたは設定変更を送信します。
- 後続のポーリングや診断のために、レスポンスの識別子を保存しておきます。
この手順により、パイプライン変数が古いプロジェクトを指しているために、有効なキーが誤ったアプリを更新してしまうという、非常にコストの高いエラーを防げます。書き込みを許可する前に、ステージングジョブがステージングアプリをターゲットにするよう要求するなど、明示的な環境のアサーションを追加してください。
緩いJSONアクセスではなく、レスポンススキーマを使用してください。API が identifier、name、status、configuration フィールドを持つアプリオブジェクトを返す場合、ジョブに必要なフィールドのみを検証し、無関係な追加には寛容であるべきです。未知のリクエスト属性を拒否することで、設定キーのタイポによる誤送信を防げます。一方で、レスポンスの解析を寛容にすることで、破壊的でないレスポンスの拡張にもクライアントが対応できるようになります。
ロールバックの設計では、アプリのアイデンティティとリリースのアイデンティティを切り離して管理してください。 Capgo のバージョン管理とロールバックに関するドキュメント は、運用上の重要なリファレンスとなります。ロールバックは、メモリからアプリケーション設定を再構築するのではなく、既知の正常なリリースまたはチャネルの状態を選択すべきです。
リリースの作成と管理
本番リリースのアップロードが成功した後でも、失敗する可能性があります。アーティファクトは正しく保存されていても、処理が未完了であったり、チャネルの割り当てが行われていなかったり、対象デバイスにアップデートが届いていなかったりする場合があるためです。ワークフローは、永続的な識別子と各操作に対するリトライプランを備えた、観測可能な状態変化のシーケンスとして扱ってください。
リリース用ペイロードの準備
プロパティ名、リクエストパス、および必須フィールドには、現在の Capgo スキーマを使用してください。類似した名前のエンドポイントからコピーしたリクエストボディは、一部のみ受け入れられたり、予期しない理由で拒否されたりする可能性があります。実用的な観点では、ペイロードは以下の3つの領域で構成されます：
- アプリケーションの識別情報： 関連するコントロールプレーン操作によって返されるアプリケーション識別子。
- リリースのメタデータ： API が期待するバージョン、bundle identity、ビルドコンテキスト、および互換性情報。
- 配信の意図： リリース操作がサポートしている場合の、channel またはロールアウトのコンテキスト。
送信前に bundle を検証してください。Capacitor のビルドに期待通りの web assets が含まれているか、バージョンが CI メタデータと一致しているか、また書き込み途中のファイルを読み込んでいないかを確認してください。API が対応している場合は、ローカルでチェックサムを計算してください。後続のジョブが upload、処理、配信のイベントを紐付けられるよう、ビルド URL、コミットリファレンス、サーバー発行のリリース識別子をデプロイ記録に保持してください。
推奨される手順は以下の通りです：
- クリーンなワークスペースでアプリケーションをビルドする。
- ユニットテスト、統合テスト、およびプラットフォーム固有のチェックを実行する。
- ドキュメント化されたリリース操作を通じて bundle を作成または upload する。
- 操作が終了状態に達するまで、返された操作をポーリングするか、リソースを解放してください。
- 完了したリリースを、対象となるチャンネルに関連付けます。
- プロモーションを行う前に、採用状況や失敗のシグナルを確認してください。
アップロードのレスポンスはサービスによる受理を意味するものであり、ユーザーへの配信を保証するものではありません。アップデートがデバイスに届くかどうかは、処理ステータス、デバイスの適合性、接続性、およびチャンネルへの所属によって決まります。
リトライを安全にする
タイムアウトが発生した場合、サーバーがリクエストを拒否したのか、接続が切れる前に完了したのかは判別できません。そのため、同じリリースを再送信すると、重複や競合するバージョンが発生する可能性があります。Capgo がサポートしている場合は、べき等性キー（idempotency key）を使用してください。その機能がない場合は、ミューテーションをリトライする前に、リリースのメタデータやクライアント側で生成したビルド識別子を使用してクエリを実行してください。
一括アップロードでは、アイテムごとのステータス管理が必要です。各アプリのバリアントを永続的なキューに入れ、その結果を個別に記録してください。ワーカーのリトライでは、1つの失敗に対してバッチ全体を再実行するのではなく、未完了のアイテムのみを選択するようにしてください。バルクエンドポイントが利用可能な場合は、レスポンスにすべてのアイテムの結果が含まれているか確認してください。集約された成功ステータスは一部のバリアントの失敗を隠してしまう可能性があり、逆に集約されたエラーは完了した作業を不明瞭にする可能性があります。
運用ルール: サーバーから返されたリリース識別子をすぐに保存し、その識別子を使用して処理チェック、チャンネル割り当て、および診断を行ってください。
レート制限は、アップロードとポーリングの両方に影響します。 API のレート制限に関するガイダンス クォータ（割り当て）は実行中のアクションを反映すべきであり、クライアント側には適切なヘッダーとリトライ動作が必要です。リリース作成、ステータス・ポーリング、検索、および機密性の高いミューテーションには、それぞれ個別のハンドリングを適用してください。アップロード速度でリトライを繰り返すポーリングループは、修正アクションに必要なクォータを使い果たしてしまう可能性があります。
レート制限ヘッダーが返された場合はそれを読み取り、サーバーが指定するリトライ間隔に従ってください。ヘッダーがない場合は遅延時間を段階的に増やします。複数のCIワーカーが同時にリトライしないよう、ジッター（ゆらぎ）を追加してください。ポーリングには上限を設け、終了状態に達したら停止し、認証情報やトークンを除去した上で最終的なレスポンスボディをCIログに含めてください。デプロイがキャンセルされた場合は、実行者または自動化ジョブ、現在のリリース状態、およびアーティファクトが後のリトライに利用可能かどうかを記録してください。
チャネル戦略とロールアウトパターン
チャネル設計は単なる命名作業ではなく、リリースのガバナンスに関する決定事項です。Staging、beta、productionの各チャネルは対象となるユーザーが異なり、それぞれ異なるプロモーションルールを持つべきです。最適な選択は、bundleに残っている不確実性の度合いや、チームがどれだけ迅速にフィードバックを必要としているかによって決まります。
| チャンネル | 対象ユーザー | 確認事項 | プロモーションの決定 |
|---|---|---|---|
| Staging | 社内デバイスおよびテストアカウント | インストール、マイグレーション、ネイティブ互換性、ログ | 技術チェックを通過 |
| Beta | 選定された早期アクセスユーザー | 実環境での挙動、サポートへのフィードバック、アップデートの採用率 | 致命的なデグレがないこと |
| 本番環境 | 一般ユーザー | 安定性、診断機能、ロールバックの準備状況 | リリース責任者の承認 |
ステージングチャネルは決定論的であるべきです。特定のテストデバイスやアカウントを割り当て、不用意な変更からチャネルを保護し、必要なチェックを通過した後にのみCIが昇格（promote）を行うようにします。Betaは本番に近いトラフィックを確認したい場合に有用ですが、対象ユーザーの定義と、障害報告のためのサポートプロセスが明確である必要があります。Productionは「退屈」であるべきです。つまり、リリースは以前のゲートを通過済みであり、ロールバック先が明確で、モニタリングが既に接続されている状態を指します。
API のワークフローは、これらの境界を反映している必要があります。パイプラインはリリースを一度だけ作成してステージングに割り当て、検証後に同じリリースオブジェクトを昇格させることができます。チャネル間で再ビルドを行うと、チームがテストしたアーティファクトとユーザーに配布されるアーティファクトが異なる可能性があるため、トレーサビリティが低下します。
現在の API エコシステムを見ても、メンテナンスの重要性は、その広さと同じくらい重要であることがわかります。 API トラッカー 膨大なAPIや開発者向けリソースのカタログが存在する一方で、公開APIのまとめに関する議論では、金融、政府、ヘルスケア、機械学習、気象、交通といった多岐にわたる項目を維持することの負担が指摘されています。チャンネルカタログも同様の課題を抱えています。情報の鮮度が落ち、所有者が不明確な大規模なリストよりも、規模は小さくても適切にメンテナンスされたリストの方が価値があります。
制御されたテストの実装詳細については、以下を参照してください： チャンネルを使用したCapgoステージング環境。重要なパターンは、任意のビルドジョブが直接本番環境に書き込むことを許可するのではなく、承認プロセスを伴う明示的なAPIアクションとしてチャンネルの移動を定義することです。
モニタリングと診断のエンドポイント
APIが成功レスポンスを返しただけでは、デプロイは完了したとは言えません。どのリリースをデバイスが検出し、ダウンロードし、インストールし、その後も正常に動作し続けているかをチームが説明できて初めて、デプロイは完了したと言えます。そのためには、リリース識別子、チャンネルの所属、デバイスの記録、logs、および採用データを紐付けるワークフローが必要です。
まずはデプロイシステムに相関レコードを作成することから始めましょう。アプリ識別子、リリース識別子、チャンネル、コミットリファレンス、ビルドメタデータ、リクエストのタイムスタンプ、そして最終的なAPIステータスを保存します。サポート報告を受けた際、オペレーターが非構造化されたCI logsを検索することなく、影響を受けたデバイスからそのチャンネルやリリースへと即座に辿り着けるようにするためです。
集計前に絞り込んでクエリする
診断用エンドポイントは、多くの場合、期間、チャンネル、デバイス、プラットフォーム、またはリリースによるフィルタリングをサポートしています。目の前の疑問を解決するには、可能な限り絞り込んだフィルタを使用してください。インストールベース全体に対する広範なクエリは、実行速度が遅くなり、解釈が困難になるだけでなく、ページネーションやクォータ制限に抵触する可能性が高まります。
実用的な調査手順は以下の通りです：
- リリース表示： 対象のリリースが存在するか、またターゲットのチャンネルに到達しているかを確認します。
- 採用状況表示： 対象となるデバイスと、アップデートを検知またはインストールしたデバイスを比較します。
- 失敗表示： エラーをリリース、プラットフォーム、デバイスクラス、およびインストール段階ごとにグループ化します。
- デバイス表示： 集計データからローカルな問題が疑われる場合にのみ、特定のデバイスのログを調査してください。
- インシデント表示： 調査に使用した生のレスポンスとクエリパラメータを保存しておいてください。
採用率の低さが必ずしもbundleの破損を意味するとは限りません。デバイスがオフラインであったり、チャンネルから除外されていたり、互換性のないバージョンを実行していたり、アプリのアップデート確認待ちである可能性があります。逆に、ダウンロード数が多いからといって起動が成功しているとは限りません。API がそれらの状態を公開している場合は、検出、ダウンロード、インストール、およびランタイムの健全性を切り分けて管理してください。
診断と自動化の連携
スケジュールされたワーカーを使用してリリースステータスを照会し、リリースがパイプラインの許容時間を超えて非終端状態のままの場合にアラートを通知できます。別のワーカーで失敗の記録を収集し、エラーコードを正規化してデプロイチケットに添付することも可能です。アラートのペイロードは、リリース、チャンネル、およびフィルタリング済みの診断クエリへのリンクを含め、簡潔に保ってください。
認証とエラーハンドリングは、エンドポイント呼び出しと同じクライアントレイヤーで行うべきです。ワーカーは認証ポリシーに従って資格情報を更新または置換し、認可エラーを不正なリクエストから区別して分類し、 429 それらを一般的なサーバーエラーとして扱うのではなく、リトライスケジュールのためのレスポンスとして保持してください。
ページネーションのカーソルや、ドキュメント化されたオフセットを仕様通りに正確に使用してください。バッチ診断ジョブはページ間で位置を保持し、最初のページを繰り返しリクエストしないようにする必要があります。クエリ実行中にレコードが変更される可能性がある場合は、結果のレポートが再現可能になるよう、安定した時間境界やリリースフィルターを使用してください。
レート制限とセキュリティヘッダー
本番環境のクライアントは、リトライパスを選択する前にレスポンスヘッダーを検査する必要があります。以下をキャプチャしてください。 X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After、およびドキュメント化されているすべての RateLimit-* API クライアントミドルウェアのフィールド。これらをリトライコントローラーと構造化ログに渡してください。アカウント、エンドポイント、または操作によって異なる可能性がある code クォータをハードコードしないでください。
〜の違いは、 容量情報 と リトライ指示 次のリクエストを決定します。remaining-count ヘッダーは、クライアントが制限にどれくらい近づいているかを示します。 Retry-After サーバーが次の試行を許可するタイミングを指定します。指示がある場合はそれに従ってください。レスポンスにタイミングのガイダンスがない場合は、ジッター付きの指数バックオフ（bounded exponential backoff）と固定のリトライ回数制限を使用してください。
管理面を保護する
Capgo の管理リクエストは、信頼できるバックエンドまたは CI ランナーで行ってください。 Capacitor アプリケーションは、限定的なアプリケーション向けサービスを呼び出すことはあっても、リリース、チャンネル、または組織のリソースを変更できる認証情報を受け取るべきではありません。TLSを強制し、ボディを検証し、トレースやエラーレポートから認証ヘッダーを削除してください。
操作ごとに個別の制御を適用してください。安全な場合は、読み取り専用のメタデータリクエストをキャッシュまたは集約します。upload、export、ログイン試行、およびリリース変更には、それぞれ独自の制限を設けてください。API がバッチ操作をサポートしている場合は、独立したメタデータ読み取りをバッチ化し、1つのバッチが1ユニットを消費すると仮定するのではなく、バッチのリクエスト制限とアイテム制限を考慮してください。また、以下で説明するように、振る舞いベースの制御は分散型の不正利用パターンの検出にも役立ちます。 レート制限に関するセキュリティガイドライン.
すべてのリクエストにタイムアウトを設定し、トランスポート層の失敗とHTTPレスポンスを区別してください。タイムアウトが発生した場合、ミューテーションの結果は不明なため、リトライする前にステータスを確認してください。 429 レスポンスは明示的なサーバーからのフィードバックであり、クライアントはヘッダーに基づいて次回の試行をスケジュールすべきです。
Capacitor のデプロイメントにおいて、 App Storeのコンプライアンスに向けた Capgo の API レート制限ガイドラインは、 運用上の有用なリファレンスとなります。認証情報は非公開を徹底し、サーバーヘッダーに従い、リトライはサイレントに行わず、観測可能な状態にしてください。
よくある API エラーのトラブルシューティング
ほとんどの失敗は、認証、バリデーション、スロットリングの3つのグループに分類されます。code を変更する前に、まずグループを特定してください。レスポンスステータス、構造化されたエラーボディ、および関連するヘッダーを確認すれば、通常は次のアクションを判断するのに十分な情報が得られます。
認証エラー
ある 401 または同等の認可レスポンスは、通常、認証情報が不足している、形式が正しくない、期限切れ、失効している、あるいは誤ったスキームで送信されていることを意味します。ローカルのシェルだけでなく、実際のCIジョブ内の環境変数を確認してください。リクエストが最新の API ドキュメント通りのヘッダー形式であることを確認し、その後に読み取り専用操作で認証情報をテストしてください。
レスポンスが「無効なアイデンティティ」ではなく「権限不足」を示している場合は、認可の問題として扱ってください。組織の管理者に、キーのスコープ、アプリのアクセス権、および環境を確認するよう依頼してください。権限エラーを、広範な権限を持つ個人用キーを配布することで解決しようとしないでください。
リクエストボディの不正
バリデーションエラーは、サーバーがリクエストを受信したものの、その構造や値が拒否されたことを意味します。ペイロードを現在のスキーマと比較し、必須フィールド、型、enum値、ネストされたオブジェクト、識別子を注意深く確認してください。サービスが無視してくれることを期待せず、サポートされていないフィールドは削除してください。
機密情報をマスクしたペイロードと、レスポンスのフィールドレベルのエラーをログに記録してください。CIにスキーマバリデーションを追加し、不正なリリースメタデータがuploadされる前にエラーになるようにします。部分的な更新（partial update）の場合は、エンドポイントが完全な置換ではなく、patch形式のボディを期待しているか確認してください。
スロットリングと曖昧なミューテーション
ある 429 は、ワーカーがリクエストの送信を停止し、サーバーの再試行ガイダンスに従う必要があることを意味します。リトライの際は、 Retry-After が存在する場合は、フォールバックの遅延を計算する際にjitterを適用し、複数のワーカーが同時に再試行するのを防いでください。
upload中やリリース作成中のタイムアウトが発生した場合、すぐに別のミューテーションを送信しないでください。クライアント側で生成したbuildリファレンス、または返された識別子を使用して、操作を検索または取得してください。識別子が利用できない場合は、APIのドキュメント化されたサポート機能やべき等性メカニズムを確認し、元のリクエストが完了したかどうかを判断してください。これにより、リリースの重複を防ぎ、最終的なデプロイ記録の信頼性を確保できます。
Capgo は、アプリの配信リソース、リリース、チャンネル、デバイス、および関連するデプロイメントワークフローを管理するための公開 REST API を提供します。これにより、チームは live-update 操作を既存の CI/CD やモニタリングシステムと連携させることが可能です。まずは現在の Capgo ドキュメントを確認し、最小権限のテスト用認証情報を作成して、本番環境への自動プロモーションを行う前に、リリースからロールバックまでの全工程を検証してください。
