本番環境の修正は完了し、Webビルドもグリーン（成功）です。チームは数分でデプロイできる状態にあります。しかし、モバイルリリースはアプリストアの審査、コンプライアンスチェックリスト、あるいは不在のリリースマネージャーに依存していることを誰かが思い出します。codeは終わっていますが、プロダクトは前に進んでいません。
そのギャップこそが 継続的デリバリー が重要です。最終ステップが本番への自動デプロイ、人による承認、インストール済みアプリに配信されるモバイル更新のいずれであっても、チームはすべての変更をテスト済み・パッケージ済み・追跡可能・リリース可能な状態に保つ再現可能な方法を得られます。
目次
- モダンなソフトウェア開発チームの継続的デリバリーを理解する
- Continuous Delivery パイプラインの主要コンポーネント
- DORAメトリクスでパイプラインの健全性を測る
- Continuous Delivery と Continuous Deployment の違い
- Progressive Deliveryのパターン
- モバイルおよびクロスプラットフォームアプリのContinuous Delivery
- 規制の厳しい業界におけるスピードと安全性の両立
- 実装ステップと避けるべき一般的な落とし穴
モダンなソフトウェア開発チームの継続的デリバリーを理解する
あるチームは小さな修正をマージし、プロダクトマネージャーがIssueの確認を終える前に、リリース可能な検証済みビルドを用意できます。別のチームは変更をまとめて大規模なモバイルリリースにし、バイナリのレビューサイクルを待ち、限られたリリースウィンドウで何も壊れないことを祈ります。両方のチームがContinuous Integrationを使っているかもしれませんが、ソフトウェアを常にリリース可能な状態に保つデリバリープロセスを構築できているのは、最初のチームだけです。
Continuous Deliveryとは、ビルド、テスト、パッケージング、リリース準備の自動化を通じて、ソフトウェアを常にリリース可能な状態に維持することです。 Jez HumbleとDavid Farleyは、2010年に次の著書を通じてこの手法を正式に広めました。 継続的デリバリー：ビルド、テスト、デプロイの自動化による信頼性の高いソフトウェアリリース。彼らの定義は、ACMのContinuous Deliveryに関する記録で述べられているように、Continuous Integrationをビルドの自動化にとどめず、新しいビルドのテストとデプロイに必要なより広範なワークフローへと拡張しました。
継続的インテグレーション（CI）は、開発者が共有コードベースに変更をマージする際にそれを検証します。継続的デリバリー（CD）はその次のステップとして、リリース候補の作成、明確な品質ゲートによる検証、生成されたアーティファクトの保存を行い、制御されたリリースが可能な状態にします。最終的なリリースには、依然として人の承認が必要な場合があります。
手動での判断は意図的です
継続的デリバリーと継続的デプロイメントは同じものではありません。
継続的デリバリーでは、パイプラインが本番リリース可能な状態までのすべてを自動化します。リリースマネージャー、プロダクトオーナー、エンジニアが、いつ変更をライブユーザーに届けるかを引き続き判断できます。継続的デプロイメントはその判断を不要にし、パイプラインを通過したすべての変更を直接本番環境へ送ります。
工場の組立ラインが分かりやすい例えです。各工程で製品をチェックし、結果を記録して、不良品が次に進まないようにします。出荷場では、マネージャーがどのトラックをいつ出発させるかを依然として決めています。継続的デリバリーもこれと同じ仕組みです。 自動化が繰り返しの検証を担い、ビジネス上のタイミングとリスクの判断は人が握り続けます。
モバイルチームにとって、この区別は特に重要です。ネイティブバイナリは、ストアの審査、関係者との調整、または規制対象の事業部門からの承認を必要とする場合があります。最終リリースを人間が管理する場合でも、パイプラインはバイナリのビルド、テスト、署名、準備を自動で実行できます。
実践的なルール： オンデマンドでテスト済みかつ識別可能なリリース候補を生成できない場合、そのチームはまだ継続的デリバリーを実現していません。
重要な問いは、チームが常にリリースしているかどうかではありません。次のリリースが予測可能で、再現可能であり、安全にプロモーションできるかどうかです。
Continuous Delivery パイプラインの主要コンポーネント
デリバリーパイプラインは、ソースの変更を制御されたリリース候補に変換します。実装はWebサービス、Capacitorアプリケーション、Electronデスクトップアプリによって異なりますが、その責務は一貫しています。
ソース管理がインプットを定義する
すべてのパイプラインには信頼できるソース・オブ・トゥルースが必要です。開発者はアプリケーションのcode、設定、テスト、パイプライン定義をバージョン管理にコミットします。変更は、文書化されていないローカルビルドではなく、コミット、プルリクエスト、または承認されたリビジョンに追跡可能であるべきです。
ブランチング戦略よりも重要なのは明確さです。チームは短期間のブランチ、トランクベース開発、または他のモデルを使用できますが、パイプラインはどのリビジョンがビルドされ、どのリビジョンがリリース対象であるかを明確に示す必要があります。
ビルドは再現可能なアーティファクトを生成する
ビルドステージはソースcodeをデプロイ可能な形に変換します。クロスプラットフォームアプリケーションの場合、Webバンドル、ネイティブプロジェクトの出力、Electronパッケージ、署名済みのモバイルバイナリなどが含まれる可能性があります。ビルドはクリーンで一貫した環境で実行され、開発者のマシンに依存するのではなく、依存関係をキャプチャする必要があります。
ローカルでは成功してもCIで失敗するビルドは、デリバリープロセスではありません。リリースドリフトを招く誘い文句です。
テストは多層的なエビデンスを提供する
単一のテストスイートではリリースへの信頼を確立できません。効果的なパイプラインは、異なるスコープのチェックを組み合わせます：
- ユニットテスト 隔離された関数やコンポーネントの欠陥を素早く検出します。
- 統合テスト サービス、プラグイン、ストレージ、プラットフォームAPIとの通信を検証します。
- 受け入れテスト 認証、チェックアウト、同期、オフライン復旧などのユーザーワークフローをテストします。
- 静的チェックとポリシーチェック フォーマット、依存関係ルール、セキュリティ要件、その他のプロジェクト標準を強制します。
モバイルおよびクロスプラットフォームアプリでは、本番構成に近いステージング環境でE2Eテストを実行してください。簡略化したモックでテストが通っても、プラットフォームの権限問題や API のバージョン不一致、アップデート処理の失敗を検出できない場合があります。
アーティファクトはリリースの同一性を保つ
パイプラインは、検証を通過したアーティファクトそのものを保存すべきです。依存関係やツール、設定が変わっていれば、後から同じソースで再ビルドしても異なる結果になる可能性があります。アーティファクトを保存しておけば、チームはプロモート、検査、比較、ロールバックに使える安定したオブジェクトを得られます。
デプロイ自動化が承認済みアーティファクトを送り出す
デプロイ自動化は、検証済みのアーティファクトを対象環境へ公開します。設定を一貫して適用し、誰が、または何がアクションを開始したかを記録し、ステージが失敗したときは明確なステータスを表示する必要があります。デプロイサービス、CIワークフロー、プラットフォーム固有のリリースシステムを利用できますが、プロセスは一連の手動コマンドに依存すべきではありません。
この Capacitor チーム向けデプロイ自動化ガイド 検証済みの変更を環境間で進める運用面を解説します。
品質ゲートとロールバックは設計の一部
品質ゲートとは、パイプラインが次に進む前に必ず通過しなければならない明示的な条件です。例として、テストの成功、有効な署名、承認済みの依存関係スキャン、環境構成の一致、必須レビューなどが挙げられます。ゲートは、チームが何を保護し、誰がオーバーライドできるかを文書化しておくと最も効果を発揮します。
ロールバックにも同じくらい注意を払う必要があります。デプロイで重大な欠陥が入り込んだ場合、復旧経路は自動化するか、シンプルで十分にテストされた操作に落とし込むべきです。素早く公開できても、以前のリリースを手動で再構築する必要があるパイプラインは、頻繁なデリバリーには安全とは言えません。
技術的な 継続的デリバリーの定義と、その自動化されたパイプラインの仕組みは この中心的な特性を強調しています。つまり、変更は自動的にビルド・テストされ、リリース準備が整えられますが、本番デプロイには手動の判断が必要な場合もあります。パイプラインは単なるスケジュールではありません。リリース可能な状態を継続的に保つためのアーキテクチャです。
DORAメトリクスでパイプラインの健全性を測る
デプロイ頻度を上げながら、本番環境の安定性を損なうチームもあります。だからこそ、デリバリーのパフォーマンスを測るには、リリース回数だけでは足りません。
DORAは4つの主要なフローメトリクスを定義しています：
| メトリクス | 何がわかるか |
|---|---|
| デプロイ頻度 | チームが変更をデプロイする頻度 |
| 変更のリードタイム | 変更がコミットから本番環境に反映されるまでの時間 |
| 変更失敗率 | デプロイが失敗やロールバック、ホットフィックス、その他の復旧対応につながる頻度 |
| サービス復旧までの平均時間 (MTTR) | 障害発生後、チームがサービスを正常な状態に戻すまでの速さ |
DORAのパフォーマンス帯が示すように、エリートチームは 1日に複数回デプロイし、リードタイムを 1時間未満に抑え、変更失敗率を 0〜15%の範囲に維持しています. パフォーマンスの低いチームは 6ヶ月に1回未満しかデプロイせず、 さらに 6ヶ月以上 変更が本番環境に反映されるのを待っています。これは Octopusの継続的デリバリーメトリクス論文によるものです。.
これらの数値は、文脈を無視して模倣すべき目標ではありません。むしろ、デリバリーを「制御システム」として扱うべき理由を示しています。バッチサイズを小さくすると各リリースの影響範囲が狭まり、フィードバックループが短いほど、欠陥を引き起こした変更の近くで検知できます。
リカバリのないスピードは罠
デプロイ頻度は、称賛しやすい一方で誤用しやすい指標です。モバイルチームは、失敗した変更を何度もロールバックしながら、リスクの低いbundleを大量に公開しているかもしれません。バックエンドチームは頻繁にデプロイしていても、インシデント後のサービス復旧に時間をかけすぎているかもしれません。どちらの場合も、スピードだけでは運用上の弱点が隠れます。
4つのメトリクスをまとめて追跡してください。リードタイムが短縮する一方で変更失敗率が上がっているなら、パイプラインは安全策より速く動きすぎています。デプロイ頻度が低いまま、ビルドが承認待ちで止まっているなら、ボトルネックはエンジニアリングではなくガバナンスにあるかもしれません。
現在のDORAのガイダンスでは、中核となるフローメトリクスだけでなく、次の指標も確認することを推奨しています。 変更失敗率、デプロイ手戻り率、デプロイ失敗時の復旧時間、パイプラインの安定性、で説明したように DORAメトリクスのガイドライン。これらの対策は、モバイルパイプラインにおいて特に有効です。ストアへの提出失敗、バイナリの拒否、問題のある live update は、単純なデプロイ回数では把握できない再作業を生み出す可能性があります。
パスをエンドツーエンドで計測する
コミットからビルド、テスト、成果物の公開、承認、デプロイ、復旧までのタイムスタンプと結果を記録します。各リリースをソースリビジョンと環境に関連付けます。モバイル更新の場合には、チャネル、バンドルバージョン、採用状況、失敗状況、ロールバックイベントを含めます。
4つのDORA成果指標に、メトリクスが悪化する前に問題を浮き彫りにする先行指標を組み合わせます：
- パイプライン所要時間： バイパスを誘発するほど長引くビルドやテストステージに注意してください。
- デプロイ失敗率： アプリケーションの欠陥と、インフラストラクチャ、設定、パイプラインの失敗を区別します。
- ロールバック回数： 頻繁なロールバックは、テストの欠落、ロールアウト設計、または変更サイズを点検すべきシグナルと捉えましょう。
- テストの不安定性: 意味のある製品上の欠陥なしに失敗するテストを追跡します。ノイジーなゲートは、チームが失敗を無視するよう訓練してしまうためです。
- 成果物のトレーサビリティ: 本番環境のバージョンがソースリビジョンとその検証エビデンスにマッピングされていることを確認します。
チームは、最も遅い部分がコンパイラやテストランナーではないことに気づくことが多いです。それは、手動承認キュー、信頼性の低いステージング環境、欠落した署名ステップ、あるいは誰もリハーサルしていないロールバックプロセスです。
健全なパイプラインは、失敗を早期に可視化し、復旧を退屈なものにします。
使用する リリース速度の実践 単一のステージを孤立して最適化するのではなく、フロー全体を調査するためです。目標は、出荷速度に紐づく虚栄の数字ではなく、より速い学習とより安全な変更です。
Continuous Delivery と Continuous Deployment の違い
違いはゲート1つですが、そのゲートが運用モデルを変えます。
継続的デリバリー 通過したすべての変更をリリースに向けて準備し、最終的な本番リリースの判断は人間の管理下に置きます。 継続的デプロイメント すべての品質ゲートを通過した変更を自動的に本番環境へプロモートします。2つ目のモデルはフィードバックループを短縮できますが、承認ステップに代わるほど自動化されたチェック、オブザーバビリティ、ロールバックが十分に強力であることを前提としています。
| 項目 | Continuous Delivery（継続的デリバリー） | Continuous Deployment（継続的デプロイ） |
|---|---|---|
| パイプラインのスコープ | ビルド、テスト、パッケージ化、リリースの準備 | ビルド、テスト、パッケージ化、リリースのデプロイ |
| 本番リリースの判断 | 人間が承認またはデプロイをトリガーできます | パイプラインが本番環境への移行を自動で行います |
| リスク管理 | 自動化と意図的なリリースゲートを組み合わせます | 自動検出と復旧に大きく依存します |
| 適したユースケース | モバイルアプリ、規制のあるワークフロー、調整が必要な変更 | テスト、フラグ、監視、ロールバックが充実した成熟したWebサービス |
| 主なトレードオフ | 制御は強化されますが、承認の遅延が発生する可能性があります | フィードバックは速くなりますが、公開前の人的レビューが減ります |
チームが不良な変更を素早く検出し、躊躇なく以前の状態に復元できる場合に、Continuous deploymentが意味を持ちます。Feature flags、canary exposure、health checks、自動ロールバックは影響範囲を縮小しますが、テストの弱さやobservabilityの欠如を補うものではありません。
モバイルアプリケーションでは、Continuous deliveryの方が現実的な選択であることが多いです。ストアレビュー、ネイティブバージョンの調整、顧客への連絡、プラットフォームの制約により、完全な自動本番デプロイは非現実的になり得ます。チームはほぼすべてを自動化しつつ、ビジネスやプラットフォームのリスクを伴うステップには意図的な判断を残すことができます。
導入障壁に関する研究は、その慎重な姿勢を裏付けています。2017年の実証研究では、 11の要因 が特定されました。組織が変更を本番環境に自動デプロイするのを妨げる要因として、自動受け入れテストの欠如、手動の品質チェック、自動テストカバレッジの不足、官僚的なデプロイプロセスなどが挙げられています。これは以下で文書化されています： 継続的デリバリーの限界に関する研究.
この選択は成熟度を競うものではありません。チームが制御できる障害モードを反映すべきです。
2つのモデルのより詳細な比較については、 継続的デリバリーと継続的デプロイを参照してください。実用的な判断基準はシンプルです。承認ゲートを撤去することで、チームが問題を検知してロールバックする前にユーザーが影響を受ける可能性があるなら、ゲートを維持し、まずパイプラインを改善してください。
Progressive Deliveryのパターン
ステージングだけを、ユーザーが変更を目にする前の唯一のゲートにすべきではありません。成熟したチームは、デプロイ自動化と、トラフィックが拡大する前に影響範囲を限定し、プロモーションルールを定義する本番側の制御を組み合わせています。
| パターン | 仕組み | ロールバックの速度 | 最適なユースケース |
|---|---|---|---|
| カナリアリリース | 本格的な展開の前に、限定的なトラフィックやインフラに対して新バージョンを公開する手法 | ヘルスシグナルと自動切り戻しが連携していれば高速 | インフラの変更や、実際の動作を検証する必要がある変更 |
| ブルーグリーンデプロイ | 本番環境に近い2つの環境間でトラフィックを切り替える手法 | ルーティングの切り戻しがスムーズに行える場合、極めて高速 | コンプライアンスが重視される切り替えや、事前にフォールバックを準備する必要があるリリース |
| フィーチャーフラグ | ユーザーがその挙動にアクセスできるかどうかを制御しながら code をリリースする | フラグ管理サービスが稼働していれば、アプリの挙動変更を高速に行える | リスクの高いビジネスロジック、段階的なユーザー公開、マーケティングと連携したリリース |
段階的戦略が機能するのは、チームがデプロイ前に成功基準を定義した場合のみです。パイプラインにはヘルスチェック、有用なテレメトリ、プロモーションルール、テスト済みのロールバック経路が必要です。チームはパターンを組み合わせることが多く、例えば決済ルールにはフラグ、プラットフォーム変更にはカナリアデプロイを使用します。 段階的ロールアウトとフルリリースの比較 で、これらの選択肢を評価する別の方法を確認できます。
モバイルおよびクロスプラットフォームアプリのContinuous Delivery
モバイルチームは、Webチームがしばしば回避するデリバリーの制約を引き継ぎます。Webのデプロイは、本番システムが新しいcodeを配信した時点でユーザーに届きます。一方、ネイティブモバイルの変更は、ストア審査、ユーザーによるアップデート、インストールを経るまで利用できないことがあります。
だからといって、モバイルチームが継続的デリバリーを諦める必要はありません。必要なのは、 ネイティブシェル を Webレイヤー プラットフォームが許す範囲で分離することです。Capacitor や Electron アプリは、JavaScript、CSS、アセットをネイティブ機能とは別にパッケージ化できるため、新しいストアバイナリを必要としない、対象となる変更のデリバリーパスを作れます。
次のようなLive Updateプラットフォームは、 Capgo CapacitorJSやElectronアプリケーション向けに、署名済みのWeb bundleを対象チャンネルへ公開できます。このワークフローでは、チームは引き続きCIでbundleのビルドとテストを行い、品質ゲートを適用し、アーティファクトを記録します。デプロイ段階では、承認されたbundleがstagingやproductionなどのチャンネルに配信され、インストール済みのアプリは次回の起動時にそのアップデートを適用します。
これにより、CDの核となる原則が維持されます。アプリが場当たり的なエンドポイントから未検証のソースをダウンロードすることはありません。チームは、バージョン管理されたアーティファクト、制御された配信対象、アップデートの可視性、そしてリカバリプランを確保できます。
モバイルパイプラインには追加のゲートが必要
実用的なクロスプラットフォームのパイプラインには、アプリの動作以上の検証が必要です：
- プラットフォームの互換性： bundleが、対象のアプリバージョンにすでにインストールされているネイティブランタイムで動作することを確認します。
- 署名と整合性： 公開されるアップデートが署名されており、クライアントが有効なbundleのみを受け入れることを保証します。
- チャンネルターゲティング： 開発からステージング、そして本番環境へ段階的にプロモーションし、対象ユーザーを混在させません。
- 起動時リカバリー: 更新に失敗した場合、拒否またはロールバックが可能であることを確認し、アプリケーションが使用不能な状態にならないようにします。
- ネイティブ境界チェック: ネイティブプラグインや権限の変更を伴うWebレイヤーの変更はブロックします。これらは新しいバイナリリリースに属するものだからです。
差分更新により、変更されたファイルのみを公開することで送信データを削減できます。ターゲット指定ロールアウトにより、チームは広範な採用前に変更を制御されたユーザーに公開できます。これらの制御はテストの代わりにはなりません。また、ストアポリシーやネイティブ互換性要件を迂回する理由にもなりません。
以下の手順では、CDの信頼性を支える検証段階を削除せずに、ライブ更新をCapacitorのデリバリーワークフローに組み込む方法を示します。
重要な設計判断は、Webバンドルとしてリリースできるものと、ネイティブリリースを必要とするものを定義することです。UI変更、コピー、JavaScriptロジック、互換性のあるアセットは、より高速なパスに従うことができます。ネイティブcode、権限、プラグイン、またはプラットフォームエンタイトルメントの変更には、より遅く、ストアを介したパスが必要です。これらを別々のリリースクラスとして扱うことで、モバイルプラットフォームに外部制御がないと装うことなく、パイプラインを高速に保ちます。
規制の厳しい業界におけるスピードと安全性の両立
規制対象のチームでは、リリースの遅さをコンプライアンスのせいにしがちですが、より根本的な問題は通常、手動のコンプライアンス作業、サイロ化したドキュメント、弱い監査証跡です。システム間でエビデンスを手動コピーすることに依存するリリースは、アプリに優れた自動テストがあっても遅いままです。
継続的デリバリーは、チームが要件をパイプラインに組み込むことでコントロールを改善できます。品質ゲートでは、承認済みテスト、署名済みアーティファクト、文書化された変更参照、または昇格前のレビューを必須にできます。パイプラインが結果を自動で保持するため、監査人や運用担当者は記憶やスクリーンショットに頼らず、一貫した記録を確認できます。
ある 50社の金融機関を対象とした2025年の調査レポート 金融機関における継続的デリバリーに関するレポートによると、自動化された継続的デリバリーパイプラインは、安定性を高めながらスループットも向上できることがわかり、継続的デリバリーでは安全性とスピードをトレードオフしなければならないという前提に疑問を投げかけています。
自動化でコントロールを再現可能に
手動のデプロイ手順はばらつきを生みます。あるエンジニアはチェックリストを正しく実行できる一方、別のエンジニアはマイグレーション確認を漏らしたり、誤ったアーティファクトをデプロイしたりするかもしれません。自動化は責任をなくすものではありませんが、あるべき手順を実行可能かつレビュー可能にします。
規制対象のパイプラインでは、これらのコントロールを可視化すべきです：
- 変更の識別: リリースをソースリビジョン、アーティファクト、チケット、承認ロールに紐付けます。
- 品質エビデンス: テスト結果とゲート結果をリリース記録と共に保存します。
- プロモーション境界: 開発・ステージング・本番の権限を分離します。
- ロールバック準備: 直前の正常なバージョンを保持し、復旧をテスト可能にします。
- 運用シグナル: リリース後は、エラー、可用性、更新失敗、デプロイ結果を監視します。
チームが素早くリリースすること自体がリスクなのではありません。リスクなのは、オブザーバビリティ、ロールバック機能、変更追跡なしでリリースすることです。手動の遅いプロセスでも、未テストまたは設定ミスのある変更をリリースしてしまう可能性があります。一方、自動化されたプロセスなら、本番前に一貫してブロックできます。
フィンテックやヘルスケアのモバイルチームにとって、継続的デリバリーとは、文書化された承認ゲートを備えた自動化されたバンドルパイプラインを意味するかもしれません。それでも、組織にリスクモデルが求める統制を外させることなく、常にリリース可能な状態という主な利点は得られます。こうした要件に取り組むチームは、 Capacitor アプリのCI/CDでのコンプライアンスチェックを リリース設計の一部として活用できます。
安全性は、証拠、制御された公開、復旧によってもたらされます。すべてのデプロイを手動にすることでは得られません。
実装ステップと避けるべき一般的な落とし穴
チームがすでに踏んでいる手順から始め、手動の引き継ぎを一つずつ減らしていきます。
- アプリケーションのcode、テスト、設定、パイプライン定義をバージョン管理下に置きます。 リリース候補が明確になるブランチングモデルを選びます。
- まずビルドとテストの段階を自動化します。 本番環境へのプロモーションを自動化する前に、クリーンな環境でユニット、統合、受け入れチェックを実行します。
- 明確な品質ゲートを定義します。 どのチェックが必須で、どの失敗がパイプラインを停止させるかを文書化します。
- 不変の成果物を保存します。 検証を通過した成果物をプロモーションし、各環境ごとに再ビルドしません。
- デプロイとロールバックを自動化します。 リリース失敗時は、緊急の手動調査ではなく、明確な復旧アクションがトリガーされるべきです。
- 最初からオブザーバビリティとメトリクスを追加します。 デプロイ頻度、リードタイム、変更失敗率、平均サービス復旧時間（MTTR）をトラッキングします。
よくある失敗は予測できます。チームはテストカバレッジの改善より先にリリーススケジュールを自動化し、承認キューを常に開いたままにし、本番と似ていない環境にデプロイし、リリース頻度だけを測定しがちです。Feature flags はデプロイとユーザーへの公開を分離できますが、未テストの code やフラグのクリーンアップ忘れを正当化するものではありません。
モバイルおよびクロスプラットフォームアプリでは、ライブアップデートの経路を選ぶ前に、ネイティブとWebのリリース境界を定義してください。bundle パイプラインはネイティブ機能が必要な変更を拒否し、互換性のある JavaScript、CSS、コピー、設定、アセットは自動化されたルートに乗せられます。
Capgo は、CapacitorJS および Electron アプリ向けに、署名付きライブアップデート、ターゲットチャネル、CI/CD 統合、差分バンドル、オブザーバビリティ、ロールバック保護を提供し、ストアレビューだけを配信パスとすることなく、対象となるモバイル変更をリリース可能な状態に保てるよう支援します。詳しくは Capgo をご覧いただき、そのアップデートワークフローが既存の継続的デリバリーパイプラインにどう適合するかを評価してください。
