手動では動くものの、チームで繰り返しリリースを行う必要が出てくると、すぐに脆弱になるデプロイパイプラインに直面しているのではないでしょうか。開発者がbundleを作成し、ノートPCからuploadし、dashboardを確認して、channelを切り替え、その後に導入状況データが反映されるのを待つ。小規模なプロジェクトならこれで済むかもしれませんが、複数のアプリ、環境、デプロイジョブが同じインフラを共有する場合、これは回避可能なリスクを生みます。
有用な公開 API リストは、「どのエンドポイントが存在するか？」以上の答えを示すべきです。認証、リソース識別子、リリース状態、クォータ、ヘッダー、リトライ、そしてバッチワークフローがどのように連携するかを示す必要があります。本ガイドでは、単発のテストリクエストではなく、CI/CD自動化を構築する Capacitor チームに適用できるパターンを用い、運用的な観点から Capgo API にアプローチします。
目次
- Capgo API 認証を理解する
- API の認証情報を生成する
- アプリ管理のコアエンドポイント
- リリースの作成と管理
- チャネル戦略とロールアウトパターン
- モニタリングと診断エンドポイント
- レート制限とセキュリティヘッダー
- よくある API エラーのトラブルシューティング
Capgo API 認証を理解する
初回統合で最もよくあるミスは、誤ったクレデンシャル形式で有効なリクエストを送ってしまうことです。ダッシュボードからコピーしたキーがそのままベアラートークンになるわけではありませんし、リクエストに Authorization ヘッダーが含まれていなかったり、誤ったスキームで送られていたりすると、ベアラートークンは役に立ちません。サーバーはエンドポイント、ペイロード、アプリ識別子を評価する前に認証エラーを返します。
まず、現在の Capgo API ドキュメントがクレデンシャルと呼んでいるものを特定し、そのサンプルリクエストをそのまま再現してください。一般的なベアラートークンリクエストでは、Authorization ヘッダーは次のパターンに従います:
Authorization: Bearer YOUR_TOKEN
ローカルテスト中は、認証情報を環境変数に格納してください。CI/CD では、リポジトリにコミットしたり、モバイルバンドルに含めたり、クエリ文字列に追加したりするのではなく、プラットフォームのシークレットストア経由で注入してください。モバイルアプリケーションに管理用認証情報を含めるべきではありません。デバイスに配信されたものは、最終的に解析されてしまう可能性があるためです。
アイデンティティと認可を分離する
Authentication は、リクエストを発行した主体が誰かを答えます。Authorization は、そのアイデンティティが何を変更できるかを答えます。デプロイサービス設計時には、これらを別々のチェックとして扱うようにしてください。
個人キーは探索には便利ですが、本番環境の自動化を個人のアカウントに依存させることになります。共有パイプラインには、組織が関連しないジョブを中断せずにキーを失効・交換できる場合に限り、チーム管理キーの方が適切です。ダッシュボードと権限モデルがその分離をサポートしている場合、開発、ステージング、本番環境のワークフローにはそれぞれ別の認証情報を使用してください。
リリースエンドポイントを呼び出す前に、リスクの低い読み取り操作をテストしてください。以下を確認します：
- ホストが正しいこと： アクティブな環境用にドキュメント化された API のベースURLを使用します。
- ヘッダーが完全であること： 必須の認証スキームと
AcceptJSONレスポンス用のヘッダーを含めます。 - ボディが正しくエンコードされていること： 送信
Content-Type: application/jsonリクエストにJSONが含まれる場合のみ。 - スコープは十分です: アプリのメタデータを読み取れるクレデンシャルでも、リリースの作成や配布が許可されない場合があります。
- レスポンスは安全にログに記録されます: ステータスコードとリクエスト識別子は記録し、キー、トークン、バンドル内容、機密性の高いデバイスデータはマスクしてください。
公開された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 ガイドライン.
アプリ管理のコアエンドポイント
アプリ管理は、以降のすべての操作におけるコントロールプレーンです。リリース作成、チャネル割り当て、バンドル配布、診断のいずれにも、安定したアプリケーション識別子が必要です。実務でよくあるミスは、人間が読めるアプリ名をすべてのジョブに渡し、それが一意であり続けると想定することです。アプリは一度解決し、正規の識別子を永続化して、以降の操作ではその識別子を使用してください。
本番環境の統合では、アプリのライフサイクルを次の4つの機能を中心にモデル化すべきです。
| 操作 | HTTP の意図 | 統合上の考慮事項 |
|---|---|---|
| アプリケーション一覧 | GET |
ページネーション、組織スコープ、安定した識別子 |
| アプリケーションを1件取得 | GET |
設定バージョンとデプロイメントの関係 |
| 設定の更新 | PATCH またはドキュメントに記載された更新方法 |
部分的な変更と完全な置換 |
| アプリケーションの削除 | DELETE |
不可逆な操作、承認と監査のコントロール |
ブログ記事や古いSDKからエンドポイントのパスを推測しないでください。現在の機械可読な定義を読み取り、その契約から型付きクライアントやリクエストラッパーを生成してください。 OpenAPI仕様 は、HTTP API のためのプログラミング言語に依存しない形式を定義し、ソースcodeやネットワークトラフィックを調べなくても、エンドポイント、認証、リクエストスキーマ、レスポンス、動作を人もツールも把握できるようにします。
識別子優先のワークフローを構築する
デプロイワーカーは、変更（mutation）を実行する前に読み取り（read）を行うべきです：
- 組織とアプリケーションのコンテキストを特定します。
- アプリのレコードを取得し、それが想定どおりのアカウントに属していることを確認します。
- 想定するプラットフォームと環境を、返された設定と比較します。
- 正規のアプリ識別子をジョブの状態に保存します。
- その識別子を使ってリリースまたは設定変更を送信します。
- 後続のポーリングや診断のために、レスポンスの識別子を永続化します。
この手順により、パイプライン変数が古いプロジェクトを指しているせいで有効なキーが誤ったアプリを更新してしまうという、意外と高くつく種類のエラーを防げます。書き込みを許可する前に、ステージングジョブはステージングアプリを対象にすることを必須にするなど、環境の明示的なアサーションを追加してください。
緩いJSONアクセスではなく、レスポンススキーマを使いましょう。APIが識別子、名前、ステータス、設定フィールドを持つアプリオブジェクトを返すなら、ジョブに必要なフィールドを検証し、無関係な追加には寛容に対応します。未知のリクエスト属性を拒否すれば、設定キーのスペルミスを誤って送信するのを防げます。一方、レスポンス解析を寛容にしておけば、非破壊的なレスポンス拡張があってもクライアントは動作し続けます。
ロールバック設計では、アプリの識別情報とリリースの識別情報を分けておきます。 Capgoのバージョン管理とロールバックに関するドキュメント が該当する運用上のリファレンスです。ロールバックでは、記憶を頼りにアプリ設定を作り直すのではなく、正常動作が確認済みのリリースまたはチャネル状態を選ぶべきです。
リリースの作成と管理
アップロードが成功した後も、本番リリースは失敗する可能性があります。アーティファクトが正しく保存されていても、処理が完了していない、チャネルへの割り当てが未実施、対象デバイスがアップデートを受信していないなどの状態があり得ます。ワークフローは、永続的な識別子と各操作のリトライ計画を備えた、観察可能な状態変化のシーケンスとして扱ってください。
リリースペイロードの準備
プロパティ名、リクエストパス、必須フィールドには、現在の Capgo スキーマを使用してください。同様の名前のエンドポイントからコピーしたリクエストボディは、一部だけ受け入れられたり、予期しない理由で拒否されたりすることがあります。実務上、ペイロードには3つの領域が含まれます:
- アプリケーションの識別情報: 関連するコントロールプレーン操作が返すアプリケーション識別子。
- リリースメタデータ: API が期待するバージョン、バンドル識別子、ビルドコンテキスト、互換性情報。
- 配布の意図: リリース操作が対応している場合は、チャネルまたはロールアウトのコンテキスト。
送信前にバンドルを検証します。Capacitor ビルドに期待される Web アセットが含まれているか、バージョンが CI メタデータと一致するか、ジョブが部分的に書き込まれたファイルを読み込んでいないかを確認します。API がチェックサムを受け入れる場合は、ローカルでチェックサムを計算します。デプロイ記録にビルド URL、コミット参照、サーバー発行のリリース識別子を残し、後続のジョブがアップロード、処理、配布の各イベントを関連付けられるようにします。
信頼できる手順は次のとおりです:
- クリーンなワークスペースでアプリケーションをビルドします。
- ユニット、統合、プラットフォーム固有のチェックを実行します。
- ドキュメントに記載されたリリース操作で、バンドルを作成またはアップロードします。
- 返されたオペレーションまたは release リソースを、終了状態に達するまでポーリングしてください。
- 完了したリリースを、対象のチャンネルに関連付けます。
- プロモーションを行う前に、採用状況や失敗のシグナルを確認してください。
アップロードのレスポンスはサービス側での受理を意味するものであり、ユーザーへの配信を保証するものではありません。アップデートがデバイスに届くかどうかは、処理ステータス、デバイスの適合性、接続性、およびチャンネルへの所属によって決まります。
リトライを安全に行う
タイムアウトが発生した場合、サーバーがリクエストを拒否したのか、接続が切れる前に処理が完了したのかは判別できません。そのため、同じリリースを再送信すると、重複やバージョンの競合が発生する可能性があります。Capgo がサポートしている場合は、冪等性キー（idempotency key）を使用してください。サポートされていない場合は、リトライする前にリリースのメタデータやクライアント側で生成したビルド識別子を使用してクエリを実行してください。
一括アップロードには、アイテムごとのステータス管理が必要です。各アプリのバリアントを永続的なキューに入れ、それぞれの結果を個別に記録してください。ワーカーのリトライ時には、1つの失敗に対してバッチ全体を再実行するのではなく、未完了のアイテムのみを選択するようにします。一括エンドポイントが利用可能な場合は、レスポンスに全アイテムの結果が含まれているか確認してください。集約された成功ステータスは一部のバリアントの失敗を隠してしまう可能性があり、逆に集約されたエラーは完了した作業を不明瞭にする可能性があります。
運用ルール: サーバーから返されたリリース識別子を即座に保存し、その識別子を使用して処理チェック、チャンネル割り当て、および診断を行ってください。
レート制限は、アップロードとポーリングの両方に影響します。 API のレート制限に関するガイダンス クォータは実行するアクションを反映すべきで、クライアントには使えるヘッダーとリトライ動作が必要です。リリース作成、ステータスポーリング、検索、慎重に扱うべきミューテーションは個別に処理してください。アップロード速度でリトライするポーリングループは、修正アクションに必要なクォータを消費しかねません。
レート制限ヘッダーが返されたら読み取り、サーバー指定のリトライ間隔に従ってください。ヘッダーがない場合は遅延を段階的に増やします。複数のCIワーカーが一斉にリトライしないよう、ジッターを追加してください。ポーリングに上限を設け、終了状態で停止し、認証情報とトークンを除去した最終レスポンスボディをCIログに含めます。デプロイがキャンセルされた場合は、実行者または自動化ジョブ、現在のリリース状態、アーティファクトが後でリトライできる状態かどうかを記録してください。
チャネル戦略とロールアウトパターン
チャネル設計は単なる命名作業ではなく、リリースガバナンスの判断です。Staging、beta、productionの各チャネルは対象ユーザーが異なり、それぞれ異なる昇格ルールを持つべきです。最適な選択は、bundleに残る不確実性の度合いと、チームがどれだけ早くフィードバックを必要としているかによって決まります。
| チャンネル | 対象ユーザー | 検証すべき項目 | 昇格の判断 |
|---|---|---|---|
| ステージング | 社内デバイスとテストアカウント | インストール、マイグレーション、ネイティブ互換性、ログ | テクニカルチェック合格 |
| ベータ | 早期アクセスユーザー | 実環境での挙動、サポートフィードバック、更新の採用状況 | ブロッキングとなるリグレッションなし |
| プロダクション | 一般ユーザー | 安定性、診断、ロールバックの準備状況 | リリース責任者の承認 |
ステージングチャネルは決定論的であるべきです。既知のテストデバイスやアカウントを割り当て、チャネルを無断変更から保護し、CIは必須チェックがパスした後にのみプロモーションするようにします。本番環境に近いトラフィックが重要であればベータは有用ですが、明確な対象定義と障害報告のためのサポートプロセスが必要です。本番環境は退屈であるべきです：リリースは以前のゲートを通過済み、ロールバック先が明確、監視がすでに接続済みであること。
API のワークフローはこれらの境界を反映すべきです。パイプラインはリリースを一度作成し、ステージングに割り当て、検証後に同じリリースオブジェクトをプロモーションできます。チャネル間で再ビルドすると、チームがテストした成果物とユーザーに配布される成果物が一致しない可能性があるため、トレーサビリティが弱まります。
現在の公開 API エコシステムも、広さと同じくらいメンテナンスが重要であることを示しています。 APIトラッカー は膨大な数のAPIや開発者リソースのカタログを提供していますが、パブリックなAPIまとめに関する議論では、金融、政府、医療、機械学習、天気、交通など多岐にわたる項目を含む場合のメンテナンス負荷が指摘されています。チャネルカタログにも同様の問題があります。古いエントリや所有権の不明確さは、大規模なリストよりも、小規模で適切にメンテナンスされたリストの方が有用であることを示しています。
制御されたテストの実装詳細については、 チャネルによるCapgoステージング環境。重要なパターンは、ビルドジョブが本番環境に直接書き込めるようにするのではなく、チャネルの移動を承認境界を伴う明示的なAPIアクションにすることです。
モニタリングと診断エンドポイント
デプロイは、APIが成功応答を返した時点で完了したわけではありません。チームが、どのリリースがデバイスによって検出され、ダウンロードされ、インストールされ、正常に実行され続けているかを説明できる時点で初めて完了です。これには、リリース識別子、チャネルメンバーシップ、デバイス記録、ログ、採用データを結びつけるワークフローが必要です。
デプロイシステムに相関レコードを作成することから始めます。アプリ識別子、リリース識別子、チャネル、コミット参照、ビルドメタデータ、リクエストタイムスタンプ、最終的なAPIステータスを保存します。サポート報告が届いた場合、オペレーターは非構造化のCIログを探索することなく、影響を受けたデバイスからそのチャネルとリリースに移動できるようにすべきです。
集計前にクエリを絞り込む
診断用エンドポイントは、期間、チャンネル、デバイス、プラットフォーム、リリースによるフィルターをサポートしていることがよくあります。知りたいことに答える最も絞り込んだフィルターを使ってください。インストール済みデバイス全体を対象とする広いクエリは、遅く、解釈しづらく、ページネーションやクォータの制約に引っかかりやすくなります。
実践的な調査の流れは次のとおりです：
- リリースビュー： 意図したリリースが存在し、対象チャンネルに到達しているかを確認します。
- 導入状況ビュー： 対象デバイスと、アップデートを検知またはインストールしたデバイスを比較します。
- 失敗ビュー： エラーをリリース、プラットフォーム、デバイスクラス、インストール段階ごとにグループ化します。
- デバイスビュー： 集計パターンから個別の問題が示唆された場合にのみ、特定デバイスのログを確認します。
- インシデントビュー： 調査に使用した生のレスポンスとクエリパラメータを保存します。
低採用シグナルはバンドルが壊れているとは限りません。デバイスがオフライン、チャネルから除外、非互換バージョンを実行中、またはアプリの更新チェックを待っている可能性があります。逆に、ダウンロード数が多いことは正常な起動を保証しません。API がそれらの状態を公開している場合、発見、ダウンロード、インストール、ランタイムヘルス状態を常に分離してください。
診断を自動化につなげる
スケジュールされたワーカーはリリースステータスをクエリし、パイプラインが許可する時間を超えて非終端状態にとどまっている場合にアラートを出すことができます。別のワーカーは失敗レコードを収集し、エラーコードを正規化してデプロイメントチケットに添付できます。アラートペイロードは簡潔にし、リリース、チャネル、フィルタリングされた診断クエリへのリンクを含めてください。
認証とエラーハンドリングは、エンドポイント呼び出しと同じクライアント層に属します。ワーカーはクレデンシャルポリシーに従ってクレデンシャルを更新または交換し、不正なリクエストとは別に認可失敗を分類し、保持します 429 リトライスケジューリングのためにレスポンスを保持し、一般的なサーバーエラーとして扱わないでください。
ページネーションカーソルまたは文書化されたオフセットは、指定された通りに正確に使用してください。バッチ診断ジョブはページ間で位置を保持し、最初のページを繰り返しリクエストすることを避ける必要があります。クエリ実行中にレコードが変更される可能性がある場合、結果レポートを再現可能にするために、安定した時間境界またはリリースフィルタを使用してください。
レート制限とセキュリティヘッダー
本番クライアントは、リトライパスを選択する前にレスポンスヘッダーをインスペクトする必要があります。キャプチャ X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After、およびドキュメントに記載されている RateLimit-* API クライアントミドルウェアのフィールド。これらをリトライコントローラーと構造化ログに渡します。アカウント、エンドポイント、または操作によって異なる可能性があるクォータをハードcodeしないでください。
の区別 容量情報 と リトライ指示 が次のリクエストを決定します。残数ヘッダーは、クライアントが制限にどの程度近づいているかを示します。 Retry-After は、サーバーが次の試行を許可するタイミングを指定します。指示が存在する場合は、それに従ってください。レスポンスにタイミングのガイダンスがない場合は、ジッター付きの限界付き指数バックオフと固定の試行回数制限を使用してください。
管理インターフェースを保護する
Capgo 管理リクエストは、信頼できるバックエンドまたはCIランナー上で実行してください。Capacitor アプリケーションは、狭い範囲のアプリケーション向けサービスを呼び出すことができますが、リリース、チャネル、または組織リソースを変更できる認証情報を決して受け取ってはいけません。TLSを強制し、ボディを検証し、トレースやエラーレポートから認可ヘッダーを削除してください。
操作ごとに個別の制御を適用します。安全な場合、読み取り専用のメタデータリクエストをキャッシュまたは結合します。アップロード、エクスポート、ログイン試行、リリース変更にはそれぞれ独自の制限を設けてください。API がバッチ操作をサポートしている場合は、独立したメタデータ読み取りをバッチ処理し、1つのバッチが1ユニットのコストであると仮定するのではなく、バッチのリクエスト数とアイテム数の制限を考慮してください。行動ベースの制御は、分散型悪用パターンの検出にも役立ちます。これは レート制限に関するセキュリティガイドライン.
すべてのリクエストにタイムアウトを設定し、トランスポート失敗とHTTPレスポンスを区別してください。タイムアウトが発生すると変更の結果が不明確になるため、再試行前にステータスを確認してください。 429 レスポンスはサーバーからの明示的なフィードバックであり、クライアントはヘッダーに基づいて次の試行をスケジュールすべきです。
Capacitor のデプロイでは、 Capgo の API に関するアプリストアコンプライアンス向けレート制限ガイドライン が関連する運用上の参考情報となります。認証情報を秘密に保ち、サーバーヘッダーを尊重し、再試行をサイレントではなく観測可能にしてください。
よくある API エラーのトラブルシューティング
ほとんどの失敗は認証、検証、スロットリングの3つのグループに分類されます。code を変更する前に、どのグループに属するかを診断してください。レスポンスステータス、構造化エラーボディ、関連するヘッダーから、次のアクションを選択するのに十分な情報が得られるはずです。
認証失敗
ある 401 または同等の認可レスポンスは、認証情報が欠落、形式不正、期限切れ、失効、または誤ったスキームで送信されたことを示すことが多いです。ローカルシェルだけでなく、実際のCIジョブ内の環境変数を確認してください。現在の API ドキュメントに記載されている正確なヘッダー形式がリクエストに含まれていることを確認し、読み取り専用操作に対して認証情報をテストしてください。
レスポンスが無効なアイデンティティではなく権限不足を示している場合、それを認可の問題として扱ってください。組織管理者にキーのスコープ、アプリアクセス、環境のレビューを依頼してください。権限エラーを解決するために、広範な権限を持つ個人キーを配布しないでください。
無効なリクエストボディ
バリデーションエラーは、サーバーがリクエストを受信したが、構造や値を拒否したことを意味します。現在のスキーマとペイロードを照合し、必須フィールド、型、enum 値、ネストされたオブジェクト、識別子に注意してください。サービスが無視してくれると期待するのではなく、サポートされていないフィールドは削除してください。
マスク済みのペイロードとレスポンスのフィールドレベルのエラーをログに記録してください。CI にスキーマバリデーションを追加し、不正なリリースメタデータがアップロード開始前に失敗するようにします。操作が部分的な更新である場合、エンドポイントが完全な置換ではなくパッチ形式のボディを期待していることを確認してください。
スロットリングと曖昧なミューテーション
ある 429 は、ワーカーがリクエストの送信を停止し、サーバーのリトライガイダンスに従う必要があることを意味します。 Retry-After が存在する場合、フォールバック遅延を計算する際にジッターを適用し、複数の並行ワーカーが同時にリトライすることを防止してください。
アップロードまたはリリース作成中のタイムアウトが発生した場合、すぐに別のミューテーションを送信しないでください。クライアント生成のビルド参照または返された識別子（受信済みの場合）を使用して、操作を検索または取得してください。識別子が利用できない場合は、API のドキュメント化されたサポートまたは冪等性メカニズムに、元のリクエストが完了したかどうかを確認してください。これにより、重複したリリースを回避し、最終的なデプロイ記録の信頼性を確保できます。
Capgo は、アプリ配信のリソース、リリース、チャンネル、デバイス、および関連するデプロイメントワークフローを管理するための公開 REST API を提供しており、チームはライブアップデートの運用を既存の CI/CD やモニタリングシステムに接続できます。まずは現在の Capgo ドキュメントを確認し、最小権限のテスト用認証情報を作成して、本番環境へのプロモーションを自動化する前に、リリースとロールバックの一連の流れを1つ検証してください。
