生産修正が完了し、Webビルドは正常で、チームは数分でデプロイすることができます。ただし、誰かがモバイルリリースがアプリストアのレビュー、コンプライアンスチェックリスト、またはリリースマネージャーがオフラインであることを思い出すと、codeは完了していますが、製品は動きません。
そのギャップは 継続的デリバリー が重要です。
これは、チームが毎回、すべての変更をテスト、パッケージ、追跡、リリース用に準備できる方法を提供します。最終ステップは、自動化された生産デプロイ、人間の承認、またはインストール済みアプリに配信されるモバイルアップデートに至ります。
- 目次
- 手動の決定は意図的です
- パイプラインの健康度を測るDORAメトリクス
- 継続的デリバリーと継続的デプロイ
- モバイルとクロスプラットフォームアプリ用の継続的デリバリー
- 規制業界でスピードと安全性をバランスさせる
- 実装ステップと回避すべき一般的なミス
現代ソフトウェアチームにおける継続的配信の理解
1つのチームは、製品マネージャーが問題を確認する前に、修正が小さく、リリース用に検証されたビルドが用意されている。もう1つのグループは、変更を大きなモバイルリリースにグループ化し、バイナリレビューサイクルを待ち、リリースウィンドウが狭いときに何も破れないように願っている。両チームは、継続的統合を使用しているが、最初のチームだけが、ソフトウェアを常にリリース用に準備できる配信プロセスを構築している。
継続的配信とは、自動ビルド、テスト、パッケージング、リリース準備を通じて、ソフトウェアを常にリリース可能な状態に保つことである。 ジェズ・ハンブルトンとデイビッド・ファーレイは、2010年に 継続的配信: ビルド、テスト、展開自動化を通じた信頼できるソフトウェアリリースを通じてこの実践を正式に広めた。
彼らの定義は、ビルド自動化を超えて、テストと展開に必要なより広いワークフローを継続的統合に拡張した。
手動の決定は意図的です。
継続的配信と継続的展開は入れ替えられません。
継続的配信では、パイプラインはすべてのステージを自動化し、生産性に到達します。リリースマネージャー、プロダクトオーナー、またはエンジニアは、変更がライブユーザーに到達するタイミングを決定することができます。継続的展開では、その決定を取り消し、パイプラインが通過した変更をすべて直接生産に送信します。
工場の組み立てラインは、有用な比較です。各ステーションは製品をチェックし、結果を記録し、不良品を進めるのを防ぎます。出荷ドックでは、管理者はまだどのトラックが出発し、いつ出発するかを決定します。継続的配信は同様に機能します。 繰り返し検証は自動化され、ビジネスタイミングとリスクは人によって制御されます。
モバイルチームにとって、その区別は特に重要です。ネイティブバイナリは、ストアのレビュー、調整されたコミュニケーション、または規制されたビジネスユニットからの承認が必要になる場合があります。パイプラインは、自動的にバイナリをビルド、テスト、署名、準備することができます。ただし、最終リリースは人間によって制御されます。
実用的なルール: チームが要求に応じてテストされた、識別可能なリリース候補を生成できない場合、まだ継続的配信を実現していません。
有効な出発点は、 継続的配信パイプラインの概要です。重要な質問は、チームが定期的にリリースするかどうかではなく、次のリリースが予測可能、繰り返し、生産に送信できる安全かどうかです。
継続的配信パイプラインの基本コンポーネント
継続的デリバリーのパイプラインは、ソースの変更を制御されたリリース候補に変換します。実装は、Webサービス、Capacitor アプリケーション、またはElectronデスクトップアプリケーションなど、さまざまなアプリケーション間で異なりますが、責任は一貫しています。
ソース管理は入力定義です。
ソースコードや設定、テスト、パイプラインの定義はすべてバージョン管理システムにコミットする必要があります。 (Translation note: "ソースコードや設定、テスト、パイプラインの定義" is a natural translation of "application code, configuration, tests, and pipeline definitions" in the context of a blog post about continuous delivery.)
ブランチ戦略は明確さよりも重要ではない。チームは短期間のブランチ、トランクベース開発、または別のモデルを使用できますが、pipelineはどのリビジョンがビルドされているか、どのリビジョンがリリースに適しているか明確に示す必要があります。
ビルドは再現可能なアーティファクトを作成します。
The build stage transforms source code into something deployable. For a cross-platform application, that might include a web bundle, native project output, an Electron package, or a signed mobile binary. The build should run in a clean, consistent environment and capture its dependencies rather than relying on a developer’s machine.
ローカルでビルドが成功したもののCIで失敗することは、継続的デリバリーのプロセスではない。実際はリリースのズレを招くようになる。
テストは層化された証拠を提供します。
リリースの信頼性を確立するには、単一のテストスイートではありません。効果的なパイプラインは、異なるスコープのチェックを組み合わせることで、リリースの信頼性を確立します。
- 単位テスト 機能やコンポーネントを孤立したところで、欠陥を早期に検出することができる。
- Integration tests サービス、プラグイン、ストレージ、プラットフォームAPIとの通信を確認する。
- 受容テスト ユーザーフローの実行、例えば認証、チェックアウト、同期、オフラインリカバリ
- 静的チェックとポリシー プロジェクトの標準、フォーマット、依存関係、セキュリティ要件を強制する
モバイルおよびクロスプラットフォームアプリケーションでは、ステージング環境と同じプロダクション設定を模した環境でエンドツーエンドテストを実行します。簡略化されたモックでテストが通った場合、プラットフォームパーミッションの問題、APIバージョン不一致、または更新ハンドリングの失敗を露呈しない可能性があります。
アーティファクトはリリースの特性を保持する
pipelineは検証に通ったアーティファクトを正確に保存する。同じソースから再構築すると、依存関係、ツール、または構成が変更された場合に異なる結果が得られる可能性があります。アーティファクトの保存により、チームは安定したオブジェクトをプロモート、検査、比較、ロールバックすることができます。
承認されたアーティファクトを移動する自動展開
自動展開は検証済みのアーティファクトを目的の環境に公開します。構成を一貫して適用し、誰かまたは何かがアクションを開始したことを記録し、ステージが失敗した場合に明確なステータスを表示する必要があります。チームは展開サービス、CIワークフロー、またはプラットフォーム固有のリリースシステムを使用できますが、プロセスは手動コマンドのシーケンスに依存してはなりません。
自動展開の Capacitorチーム向けの展開自動化ガイド 継続的デリバリーとは
継続的デリバリーPipelineの5つの段階を示す図、ビルド、テスト、デプロイを含む
品質ゲートとロールバックは設計の一部
品質ゲートとは、Pipelineが進む前に通過する必要がある明示的な条件のこと。成功したテスト、有効な署名、承認された依存関係スキャン、環境構成の照合、または必要なレビューなどが例です。ゲートは、チームが保護するものと誰がそれをオーバーライドできるかを文書化することで最も効果的です。
技術的 技術的な 継続的デリバリーの定義と自動化されたPipelineメカニズム
DORA指標を使用したパイプラインの健康度の測定
Pipelineの健康度を測るDORAメトリクス
DORAは、4つの基本的なフロー指標を定義しています。
| Metric | これが教えてくれること |
|---|---|
| 展開頻度 | チームが変更を展開する頻度 |
| 変更のリードタイム | 変更がコミットから生産環境に移動するのにかかる時間 |
| 展開が失敗、ロールバック、ホットフィックス、または他の復旧イベントを引き起こす頻度 | サービス復旧までの平均時間 |
| チームが失敗後にサービスを正常な状態に戻すスピード | DORAパフォーマンスバンドは、エリートチームが |
1日複数回展開する リードタイムを達成する 1時間以内, 失敗率を 0%から15%. 低パフォーマンスのチームは 6か月に1回以下 待つ 6か月以上 の Octopus の継続的デリバリー メトリクス ペーパー.
これらの数字は、コンテキストなしでコピーするべきではない。デリバリーを制御システムとして扱う必要があることを示している。小さなバッチはリリースの表面積を減らし、短いフィードバックループはチームが問題を変更が導入した近くで検出できるようにする。
スピードだけは罠
デプロイ頻度は、簡単に祝うことができ、簡単に誤用されることができる。モバイルチームは、繰り返しロールバックした失敗した変更に対して多くのリスクが低いパッケージを公開するかもしれない。バックエンドチームは、頻繁にデプロイするが、インシデントの後、サービスを復元するのに長い時間を費やすかもしれない。どちらの場合も、スピードだけは、運用上の弱点を隠している。
4つの指標を一緒に追跡する。リードタイムが下がりながら変更失敗率が上昇すると、pipelineは安全対策よりも速く動いている。デプロイ頻度が低く、ビルドが承認待ちになっている場合、ボトルネックはエンジニアリングではなく、統治である可能性がある。
現在のDORAガイドラインでは、コアフロー指標の他に 変更失敗率、デプロイ再作業率、失敗したデプロイの復旧時間、pipelineの安定性を考慮することを推奨している。詳細は DORA指標ガイドラインを参照のこと。特にモバイルpipelineの場合、失敗したストアの提出、却下されたバイナリ、または問題のあるlive updateが単純なデプロイカウントでは明らかにならない再作業を生じることがある。
エンドツーエンドのパスをインストルメントする
コミットからビルド、テスト、アーティファクトの公開、承認、デプロイ、復旧までのタイムスタンプと結果をキャプチャする。リリースを環境とソースリビジョンに接続する。モバイルアップデートの場合、チャネル、バンドルバージョン、採用状況、失敗状況、ロールバックイベントを含める。
チームはよく、最も遅い部分がコンパイラやテストランナーではなく、手動承認キュー、不信頼性のあるステージング環境、署名ステップの欠如、誰も練習していないロールバックプロセスであると発見する。
健全なpipelineは、失敗を早く見つけ、復旧を面白くする。
Use DORA指標ガイドライン 全体の流れを調べるのではなく、1つのステージを孤立して最適化するのではなく。
継続的配信 vs 継続的展開
1つのゲートの差はありますが、そのゲートは運用モデルを変える
継続的配信 すべてのパッシングの変更をリリース用に準備し、最終的な生産決定を人間のコントロール下に保つ 継続的展開 すべてのパッシングの変更がすべての品質ゲートを通過した場合に自動的にプロダクションに昇格する
| Aspect | アスペクト | 継続的配信 |
|---|---|---|
| 継続的展開 | Pipelineスコープの範囲はビルド、テスト、パッケージング、リリースの準備 | ビルド、テスト、パッケージング、リリースの展開 |
| 生産決定 | 人事が承認または展開をトリガーする | pipelineは自動的に生産移行を実行 |
| リスク管理 | 自動化と意図的なリリースゲートの組み合わせ | 自動検出と回復に大きく依存 |
| 適切な選択 | モバイルアプリ、規制ワークフロー、調整が必要な変更 | 強力なテスト、フラグ、監視、ロールバックを持つ成熟したWebサービス |
| 主なトレードオフ | より多くの制御が可能ですが、承認の遅延が発生する可能性があります | 迅速なフィードバックが得られるが、露出前に人間のレビューが少ない |
チームが悪い変更を迅速に検出でき、前の状態に戻すことができる場合、継続的デプロイは意味がある。機能フラグ、カニバリーエクスポージャー、ヘルスチェック、自動ロールバックは、爆発半径を減らすが、弱いテストや観察性の欠如を補うものではない。
モバイルアプリケーションでは、継続的デリバリーがより正直な選択肢である。ストアレビュー、ネイティブバージョン調整、顧客コミュニケーション、プラットフォーム制約により、完全自動のプロダクションデプロイは現実的ではない。チームはほぼすべてのことを自動化し、ビジネスリスクまたはプラットフォームリスクを伴うステップに意図的に決定を残すことができる。
2017年の実証研究は、 11の要因 が組織が自動的にプロダクションに変更をプッシュすることを制限したことを支持している。包括的な自動受け入れテストの欠如、手動品質チェック、自動テストカバレッジの不足、官僚的なデプロイプロセスなど、 継続的デリバリーの制限の研究.
に記載されている。
選択は成熟度の競争ではない。チームが制御できる失敗モードに反映されるべきである。 詳細な比較については、継続的デリバリーと継続的デプロイ
モバイルとクロスプラットフォームアプリのための継続的デリバリー
モバイルチームは、ウェブチームが避けることが多いデリバリーの制約を受け継ぐ。ウェブのデプロイは、生産システムが新しいcodeを提供するのと同時にユーザーに到達できる。ネイティブモバイルの変更は、ストアのレビュー、ユーザーの採用、インストールを待たなければならない。しかしながら、それが利用可能になるまでに時間がかかる。
継続的デリバリーを放棄する必要はありません。 https://__CAPGO_KEEP_0__.appからスクリーンショット から ウェブ層 where the platform permits it. Capacitor and Electron applications can package JavaScript, CSS, and assets separately from native functionality, creating a delivery path for eligible changes that doesn’t require a new store binary.
ネイティブシェルとウェブレイヤーを分離する Capgo ライブアップデートプラットフォーム
CapacitorJSとElectronアプリケーション
モバイル パイプラインには追加のゲートが必要です。
アプリケーションの動作を検証するだけでなく、実用的なクロスプラットフォームパイプラインは、以下の要素を検証する必要があります。
- プラットフォーム互換性: バンドルがターゲットアプリのバージョンで既にインストールされているネイティブランタイムと正常に動作することを確認します。
- 署名と完全性: アップデートが公開された場合、署名されたアップデートが確実に検証され、クライアントは有効なバンドルしか受け入れないようにする。
- チャンネル対象: 開発からステージング、そして最終的に生産環境まで、混在するアウディエンスを避けて順次展開する。
- スタートアップの復旧 アップデートが失敗した場合、更新が失敗した場合にアプリケーションが使用できなくなることを防ぐために、更新が拒否されるか、ロールバックされることが確認される。
- Native boundary check: Native プラグインまたはパーミッションの変更が必要な Web 層の変更は、まだ新しいバイナリ リリースに属するため、ブロックします。
差分更新では、変更されたファイルのみを公開することで、送信されるデータの量を削減できます。ターゲットされたロールアウトでは、チームは広範な採用前に、制御されたアウディエンスに変更を公開することができます。 その制御はテストを置き換えるものではなく、ストアポリシーまたはネイティブの互換性要件を回避する理由にはならない。
以下のウォークスルーは、CDの信頼性を確保するために、検証ステージを削除せずに、ライブアップデートがCapacitor配信フローにどのように組み込まれるかを示しています。
重要な設計上の決定は、どのようなものがWebバンドルとして配信できるか、どのようなものがネイティブのリリースが必要なのかを定義することです。UIの変更、コピー、JavaScriptのロジック、互換性のあるアセットは、より速いパスを遂行できます。ネイティブのcode、権限、プラグイン、またはプラットフォームのエンタイトルメントの変更は、より遅い、ストアを介したパスを必要とします。 それらを別のリリースクラスとして扱うことで、パイプラインを速くすることができますが、モバイルプラットフォームには外部の制御がないことを思い出さないようにします。
速度と安全性のバランスを取る
規制チームは、規制が遅いリリースの原因であると非難することがよくありますが、深い問題は通常、人々が証拠をシステム間でコピーする必要があるため、リリースが依存していることです。 アプリケーションが優れた自動テストを持っている場合でも、証拠をシステム間でコピーする必要があるため、リリースは遅いままです。
継続的デリバリーは、チームがパイプラインに要件をエンコードすることで、コントロールを向上させることができます。品質ゲートは、承認されたテスト、署名されたアーティファクト、ドキュメント化された変更の参照、またはレビューの要求を含むことができます。パイプラインは結果を自動的に保持し、記憶とスクリーンショットに頼るのではなく、監査員とオペレーターに一貫したレコードを提供します。
A 2025年の金融機関50社を対象とした調査レポート 自動化はコントロールを繰り返す
オートメーションにより、制御は繰り返し可能になります。
規制されたパイプラインは、次のコントロールを視覚化する必要があります:
変更の特性:
- リリースをソースのリビジョン、アーティファクト、チケット、承認ロールと関連付ける。 品質の証拠:
- リリースレコードとともにテスト結果とゲートの結果を保存する。 昇格の境界:
- ]} ]} 開発、ステージング、生産の権限を分離する。
- ロールバックの準備: 前の知られている良好なバージョンを保持し、回復テストを実行できるようにする。
- 運用信号: リリース後、エラー、利用可能性、更新失敗、デプロイ結果を監視する。
リスクはチームが迅速にリリースすることではありません。リスクは、観察性、ロールバック機能、変更追跡機能がなく、リリースすることです。手動の遅いプロセスでも、未テストまたは不正しく構成された変更をリリースできます。自動プロセスでも、常にリリース前にブロックできます。
金融技術または医療のモバイルチームにとって、継続的な配信は、文書化された承認ゲートを持つ自動化されたバンドルパイプラインを意味する場合があります。組織がリスクモデルで必要とする制御を削除する必要はありません。この利益は、常にリリースが準備されていることを意味します。チームは、 規制要件を考慮してCapacitorアプリケーションを使用する 安全性は証拠、制御された露出、回復から来ます。すべてのデプロイを手動にすることから来るものではありません。
実装ステップと回避すべき一般的な罠
チームがすでにフォローしているパスから始め、手動のハンドオフを一つずつ削除する。
実装ステップと回避すべき一般的な罠
- アプリケーション code、テスト、構成、パイプライン定義をバージョン管理下に置く。 リリース候補が明確になるブランチングモデルを選択する。
- ビルドとテストのステージを自動化する。 クリーンな環境でユニット、統合、受け入れテストを実行し、生産環境への自動昇格を実施する。
- 明確な品質ゲートを定義する。 通過する必要があるチェックと、パイプラインを停止する失敗を記述する。
- 不変のアーティファクトを保存する。 検証を通過したアーティファクトを昇格するのではなく、各環境で再構築するのではなく昇格する。
- 展開とロールバックを自動化する。 失敗したリリースは、緊急の手動調査ではなく、明確な回復アクションをトリガーする。
- 観察性とメトリクスを最初から導入する。 展開頻度、リードタイム、変更失敗率、サービス復旧までの平均時間を追跡する。
予測可能な失敗は予測可能です。チームはテストカバレージを向上させる前にリリースのスケジュールを自動化し、承認キューを常に開放し、生産環境に似た環境に展開せず、またはリリース頻度のみを測定します。機能フラグは展開とユーザーへの露出を分離できますが、未テストのcodeやフラグのクリーンアップを忘れないでください。
モバイルとクロスプラットフォームアプリの場合、ネイティブとウェブのリリース境界を定義する前に、ライブアップデートのパスを選択する必要があります。バンドルパイプラインはネイティブ機能が必要な変更を拒否し、互換性のあるJavaScript、CSS、コピー、構成、資産は自動化されたルートを遵守する必要があります。
CapgoはCapacitorJSとElectronアプリ向けに署名されたライブアップデート、ターゲットチャンネル、CI/CD統合、差分バンドル、観察性、ロールバック保護を提供し、チームがエラブルなモバイル変更をリリース用に保管することができます。ストアレビューを唯一の配信パスとして扱うのではなく、Visit Capgo を評価するには、__CAPGO_KEEP_0__の更新ワークフローが既存の継続的配信パイプラインにどのようにフィットするかを評価する必要があります。
