ハイブリッドアプリチームがビルドプロセスを超えると、通常はそのことを知ることができます。誰かはまだMacにログインし、Xcodeをクリックして、Androidアーティファクトをエクスポートし、Electronパッケージを手動で署名し、そしてアップロードされたビルドのブランチを思い出すために試みています。リリースは成功しましたが、ただし、1人または2人の人がすべてのステップを心に留めており、それがスケールすることを止めるのは、忙しいときにその人たちが忙しくなるからです。
適切な 継続的インテグレーション設定 脆弱な儀式を繰り返す可視化されたパイプラインに置き換える マーティン・フラワーのCIの定義は、チームのメンバーが少なくとも毎日共有コードベースに変更をマージし、自動ビルドによって各統合が検証されるため、エラーが迅速に表面化する. That discipline matters even more for Capacitor and Electron apps, where one build can touch web assets, native wrappers, signing credentials, and live update publishing in the same run.
. その規律は、__CAPGO_KEEP_0__アプリとElectronアプリにとって、より重要なものです。1つのビルドでウェブアセット、ネイティブラッパー、署名資格、ライブアップデートの公開が同じ実行で行われるためです。
- Why Your Capacitor and Electron Apps Need a Real CI Pipeline
- 痛みは、ただ速さだけではない
- パイプライン構成の作成
- Codeの署名とアーティファクト管理
- Capgoのライブアップデートの自動化
- CIパイプラインを現実の脅威から保護する
- CIPipelineの一般的なエラーと修正方法
CapacitorとElectronアプリのために、実際のCIPipelineが必要な理由
通常の開始点は、開発者がローカルでWebビルドを実行し、CapacitorをSyncし、XcodeまたはAndroid Studioを開き、署名されたバイナリをエクスポートし、共有ドライブまたはチャットスレッドにパッケージをドロップすることです。最初のビルドが1台のマシンでしか動作しない、証明書が期限切れのままになっている、またはマニュアルステップが書かれていないため、チームメンバーが古いブランチからリリースするまで待たされるまで、効率的には感じるかもしれません。
痛みは、速度だけではなく、再現性です。
Fowlerのベースラインルールは、まだこのプロセスが崩壊する理由を説明しています。信頼できるCI設定では、すべてのファイルをバージョン管理下に置き、ビルドを自動化し、ビルドを自己テスト化し、メインラインにプッシュされるたびにトリガーし、破損したビルドを即座に修正し、ビルドを高速化します。 FowlerのCIガイドラインそれは「テストを実行すること」より、リリース作業を視覚化し、面白く、間違いを犯すことが難しくすることです。
実用的なルール: リリースが誰かがローカルコマンドを思い出す必要がある場合、それはまだPipelineではありません。
Capacitorチームは、3つの場所で破損を感じます。ネイティブプロジェクトファイルはWebアプリから離れ、署名資格情報は部族の知識になり、更新パスは汚れていくのは誰も信頼できないバンドルバージョンがテスターに到達したかどうかを知らないためです。Electronチームは、パッケージングがローカルOS状態、ネイティブ依存関係、または開発者のアドホック署名設定に依存する壁に当たることと同じです。
Aの実際のパイプラインは、共有された真実の源を提供します。同じチェックを実行し、クリーンなランナーで実行し、変更されたものを示すアーティファクトとログを残します。 ‘私たちはそれを作りました’と ‘私たちは確かにどれだけ作ったかを証明しました’の違いです。
なぜライブアップデートワークフローは自然にここに収まるのか
パイプラインが再現可能になるまでに、ライブアップデートの公開はリリースの同一の規範になり、別のスクリプトを実行する人によって実行される別のスクリプトとは別のものになる。ハイブリッドチームにとって、それは重要です。ウェブアセット、JavaScriptの修正、構成変更は、フルアプリストアサイクルを待たずに待たなくてもいいから。構造化されたCIフローは、1度だけビルドし、1度だけ検証し、そして同じ出力を正しいチャンネルにトレース可能なものに送ることが可能になります。
__CAPGO_KEEP_0__のCIの利点の概要は、ここに収まるように設計されています。価値は抽象的ではありません。手動パッケージングから制御された、繰り返し可能な配信に移行することの能力です。変更されたものの視覚化を失うことなく。 Capgo’s CI benefits overview ハイブリッドアプリの場合、プロバイダーの選択は純ウェブワークの場合よりも重要です。Linuxランナーしか必要としないパイプラインは、少し粗いところを許容できます。iOS署名のためにmacOSが必要なパイプライン、ElectronパッケージングのためにDockerが必要なパイプライン、ログに漏れないように秘密を保持する必要があるパイプラインは、より厳密なランナーコントロール、明確な隔離、安全な許可モデルが必要です。
__CAPGO_KEEP_0__は、
__CAPGO_KEEP_0__のCIの利点の概要は、 npm install __CAPGO_KEEP_0__のCIの利点の概要は、
A good provider also has to fit the release path, not just the build step. Capacitor and Electron teams often end up dealing with native app signing, artifact promotion, and live update publishing in the same pipeline, so the CI system has to keep those steps separate without making the workflow hard to audit. If the runner model is weak, signing material gets copied around too freely. If artifact handling is sloppy, you lose confidence in what was shipped. That is the part generic CI guides usually skip.
GitHub Actions fits teams already living in GitHub
GitHub Actions is the lowest-friction choice if your source already lives in GitHub. Workflows sit beside the app code, which makes review and ownership straightforward, and the platform supports Linux, Windows, and macOS runners in the source-control and runner model described in CI tool comparisons GitHub Actions runner model and SCM couplingCIツールの比較で説明されているソースコントロールとランナー モデルの説明に基づいて、Linux、Windows、macOSランナーをサポートするプラットフォームは、ワークフローがアプリケーションと隣接し、レビューと所有権が容易になります。
GitHub のアクションは、すべてのジョブを同じように扱う場合に、ノイズが増加する可能性があります。 GitHub を使用しているチームにとっては、 code のレビュー、ブランチ保護、リリースの所有権のために機能します。ビルド、レジストリ、デプロイ制御が別の場所にあり、CI システムがリリースプロセスをより多く管理したい場合は、魅力が低くなります。多くのモバイルチームにとっては、コンビネンスが勝ちます。ワークフロー ファイルと code のレビューは同じ場所で発生します。
リポジトリと配信が同居する場合、GitLab CI は強力です。
GitLab CI は、リポジトリ、パイプライン、環境の追跡が 1 つの場所で行えるチームに適しています。共有または自己管理のランナーをサポートし、プラットフォーム モデルにデプロイ ステージを含むため、ビルド、ステージング、リリースのオーケストレーションを同じチームが所有する場合に実用的な設定になります。 GitLab CI プラットフォーム モデルその設定は、署名、パッケージング、リリースの承認を散らばらせることなく、別のシステムに散らばらせることなく、分離する必要がある場合に役立ちます。
__CAPGO_KEEP_0__ のアクションは、すべてのジョブを同じように扱う場合に、ノイズが増加する可能性があります。 __CAPGO_KEEP_1__ を使用しているチームにとっては、 __CAPGO_KEEP_2__ のレビュー、ブランチ保護、リリースの所有権のために機能します。ビルド、レジストリ、デプロイ制御が別の場所にあり、CI システムがリリースプロセスをより多く管理したい場合は、魅力が低くなります。多くのモバイルチームにとっては、コンビネンスが勝ちます。ワークフロー ファイルと __CAPGO_KEEP_3__ のレビューは同じ場所で発生します。 Capgo の GitLab ビルドとリリース ガイド は、ビルドとリリースステップがパイプラインに組み込まれることなく、つながっていることを示すため、参考になるものです。
CircleCIは、ホストされた柔軟性を求めるチームに適しています。
CircleCIは、パッケージングとビルド自動化の強力なエコシステムを持つマネージド実行を求めるチームに適しています。クラウドエクゼキュータとセルフホストオプションにより、GitLab、Bitbucketリポジトリを含むGitHubの柔軟性が高まります。これにより、ハイブリッドチームが顧客やコードベースを移動する際に、ポータビリティが役立ちます。 CircleCIの実行モデル. CapacitorとElectronの利点は、ビルドロジックをコンパクトに保つことができ、プロバイダーの機能を使用してエクゼキュータの選択とジョブの分離を実現できることです。
欠点は、ポータビリティが複雑さを隠すことです。macOS署名、アーティファクトのプロモーション、更新の公開を追加すると、依然として厳格なシークレットの管理と明確なジョブの境界が必要です。CircleCIは、ホストされたランナーを求めるチームにとって適していますが、プロバイダーの特定のワークフロー モデルを学習する必要があるため、少しの学習が必要です。
| 基準 | GitHubアクション | GitLab CI | CircleCI |
|---|---|---|---|
| Capacitor/Electronビルドサポート | macOS、Linux、Windowsランナーを備えたGitHub-ファーストチームに適しています | GitLabで共有または自社管理のランナーを使用しているチーム向けに強力 | 複数のSCMに対応したホストされたサポート |
| 設定の容易さ | 既存のcodeに既存のGitHubが存在する場合、低摩擦 | プラットフォームとの緊密な統合が可能ですが、GitLabの全スタックが存在する場合に最適 | プロバイダーの特定の設定を学ぶ必要があるため、柔軟 |
| 無料枠の制限 | パブリックGitHubリポジトリ向けに最適、特に小規模プロジェクト | GitLabが既存のシステムレコードの場合に最も価値のある選択 | 管理された実行のために選択されることが多いが、最小の設定コスト |
正しい選択肢は、codeがすでに存在し、最も頻繁に必要なランナー種類によって決まります。iOSのshipping圧力のあるCapacitorアプリは、macOSへの容易なアクセスを求めています。予測可能なパッケージングのElectron重視の製品は、Dockerフレンドリーなジョブとアーティファクトハンドリングを優先するのではなく、Dockerフレンドリーなジョブとアーティファクトハンドリングを優先するのではなく、リリースパーミッションと署名ステップを簡単に分離できるプロバイダーを選択します。
A platformを比較する有効な方法は、1つの質問を各プラットフォームに問うことです。 それぞれのプラットフォームが、必要なネイティブジョブを実行できるか、秘密を制御できるか、チームが設定ファイルを読むことができるか、2番目のWikiページを開くことなく、という質問です。
パイプライン構成の作成
ハイブリッドパイプラインは、安価なチェックが失敗したときに最初に実行され、必要に応じて高価なランナーが実行されないようにすることが最も効果的です。 Linting、ユニットテスト、Webビルドは、macOSがiOSをコンパイルしたり、Electronパッケージングが署名されたアーティファクトを生成したりする前に完了するようにします。 これは、破損した変更がランナー時間を消費しないようにし、CIパターンに合致する、早期の高速チェック、後期の重いスイート、最後のステージで同じアーティファクトをビルドすることです。 JetBrains CI/CDのベストプラクティス.
実際に機能するGitHub Actions形状
実用的なレイアウトは、シンプルで予測可能です:
- チェックアウト
- 依存関係のインストール
- Lintingとユニットテスト
- Webアセットのビルド
- ネイティブプロジェクトの同期
- プラットフォームアーティファクトのパッケージング
- アップロードアーティファクト
That sequence keeps broken code away from expensive native jobs. It also makes cache behavior easier to reason about, because npm, Gradle, and package manager caches matter only after the dependency graph is already valid.
A compact GitHub Actions job usually follows this structure, even when the project details change:
- インストールするのは一度: Nodeとパッケージキャッシュを復元する前に
npm ci. - 早期に検証する: ネイティブビルド前にlintとユニットテストを実行する。
- Web出力のビルド: create the asset bundle that Capacitor and Electron both consume.
- プラットフォームジョブに分岐する: iOS、Android、Electronパッケージングは共有ステップが成功した後のみ実行する。
- アーティファクトを公開する: アップロードした署名付きの出力、ログ、メタデータを個別にアップロードすること。
共有チェックが通過した後、ネイティブの作業を遅らせることで、失敗のコストが安くなります。
モバイルとデスクトップの両方のターゲットを出荷するチームの場合、その割合は通常、管理可能なパイプラインとノイズの多いパイプラインを分離します。 Xcode の失敗は、macOS の時間と開発者の注意を消費するため、費用がかかります。一方、Lint ジョブの失敗はほとんどコストがかかりません。すべてのジョブを 1 つの大きなジョブにまとめることは、ビルドが実際の署名、更新の公開、リリースの許可を処理するようになると、時とともに悪化する傾向があります。
GitLab と CircleCI は同じロジックを反映できます。
GitLab CI はステージジョブにマップされ、CircleCI も同様です。シンタックスは異なりますが、ポイントは、すべての 3 つのツールで同じパイプラインの形を維持することです。1 つのソース ビルドは、ダウンストリーム ジョブに流れ込み、各ネイティブ パッケージング ステップは同じ code 状態を消費するのではなく、スクラッチから再構築するのではなく、同じ状態を使用します。
Docker を使用して Electron パッケージングを行う場合、コンテナ イメージを固定して環境を再現可能にします。iOS ビルドの場合、macOS ジョブを分離し、証明書ステップとコンパイルステップを分離して、失敗モードを明確にします。Android ビルドの場合、Gradle キャッシュを安定させ、関連しないパッケージのインストールを同一のシェル ステップに混ぜないようにします。
Capacitor に特化したその設定の場合 Capgo のパイプライン設定ガイド __CAPGO_KEEP_1__ Actions を使用して __CAPGO_KEEP_0__ と Electron アプリケーションをビルドするための 5 つのステップの連続的なインテグレーション パイプラインを示す図
Code 証明書とアーティファクト管理
証明書とアーティファクト管理は、パイプラインの重要なステージです。ビルドが成功し、パッケージが存在する場合でも、リリースが失敗することがあります。証明書が欠如している、キーチェーンが解放されていない、またはアップロードされたアーティファクトが間違っている場合です。対処法は、署名をパッケージングの副産物として扱うのではなく、制御されたステージとして扱うことです。
iOS、Android、および Electron は異なるハンドリングが必要です。
iOS signing usually means certificates, provisioning profiles, and macOS runner state. Android needs keystore management and whatever your Play release path requires. Electron adds code signing certificates and, on macOS, notarization for distributable desktop builds. Each of those should be handled by the pipeline, not by a human copying files onto a runner.
iOS の場合、チームは多くの場合、fastlane match を使用したり、macOS ランナーに証明書を手動でインストールしたりします。重要なのは一貫性であり、特定のヘルパーに依存することではありません。開発者がインタラクティブにキーチェーンにアクセスするワークフローを依存している場合、最悪の時期に破損することになります。
Android の場合、キーストアをリポジトリ外に保管し、ビルド時にシークレットとしてインジェクトします。Electron の場合、署名ステップをパッケージングステップに近づけることで、間違ったアーティファクトを誤って署名するのを防ぎます。
実用的なルール: 予定されているアーティファクトを署名し、署名後のアーティファクトを不変に保つことです。
アーティファクト管理は、追跡可能性を保つべきです
アーティファクト管理は単にストレージだけではありません。どのバイナリがどのコミットから来て、どのチャネルに送られたかを知ることができるからです。それがなぜフォウラーの古いアドバイスであるバージョン情報を明示的に表示することの重要性が、エンタープライズCIシステムにおいても残っているのか、ビルドID、デプロイメントメタデータ、リリーストレースビリティは、後でサポート質問に答えるためにチームが必要とするものだからです。 フォウラーによるバージョン情報の可視化.
ロールバック、監査、サポートの再現のために署名された出力を長く保持する必要がありますが、古いリリースを無関係なコンテキストで残しておくのは避けるべきです。クリーンな命名スキーム、コミットSHA、プラットフォームタグは、長い距離を走ります。TestFlight、Google Playの内部テスト、またはElectronの配布バケットにパイプラインがアップロードする場合、アップロードステップを明示的に行うことで、CIから出たものを検査できます。
Capgoの 証明書管理ガイダンス は、ネイティブ署名と更新の公開に共通する規範です。資格情報は安全に保存し、きれいにローテーションし、ログに反映させないようにする必要があります。
Capgo Live Updatesの自動化
ビルドが安定したら、ライブアップデートの公開は、時間を最も節約する部分のスタックです。ハイブリッドチームは、コピーを修正したり、Webのバグ修正を配信したり、フラグを切り替えたりするために、ストアのレビューを待つ必要はありません。CIドライブのCapgoの公開ステップは、ネイティブのリリースプロセスをボトルネックにしないように、時間を節約し、更新パスをビルドの制御と同じものにします。
チャンネルベースの公開により、リリースの制御が可能
公開先を最も簡潔なパターンとして 開発 開発ブランチへのマージと 生産 only on tagged releases. That keeps testers on a predictable channel while making production pushes deliberate and reviewable. The pipeline should store the Capgo API key as a secret, install the CLI, bundle the latest web assets, and publish the update as part of the job.
テスターは予測可能なチャンネルに留まり、生産ブランチへのプッシュは意図的でレビュー可能なものになる
- pipelineは__CAPGO_KEEP_0____CAPGO_KEEP_1__キーを秘密として保存し、__CAPGO_KEEP_2__をインストールし、最新のWebアセットをバンドルし、更新をジョブの一部として公開する 実践では、単純なポリシーが効果的
- 開発ブランチ ステージングチャンネルにプッシュ
- リリースタグ時は生産チャンネルにプッシュする ロールアウトの意図が確認されるまで、孤立させておく。
CIとライブ更新は相互に補完し合う。パイプラインはすでにどのコミットをビルドしているかを知っているからです。Capgoの公開ステップで、そのメタデータを利用して、更新履歴を読みやすくしておきましょう。特に、特定のネイティブビルドにどのウェブペイロードが付いたかを答える必要がある場合にそうです。
差分更新とロールバックの動作は重要です。
Capgoの更新モデルは、変更されたファイルのみを送信し、何かが破綻した場合に安全にロールバックできるように設計されています。これはCIドライブされたリリースフローに自然に合致するためです。つまり、パイプラインはアセットを配信するだけでなく、そのアセットがどのアウディエンスやチャネルに移動するかを決定することになります。頻繁にリリースするチームにとっては、その制御は一時的な手動の公開スクリプトよりも有用です。
主な間違いは、公開ステップを独立したタスクとして扱うことです。通常、誰かがそれをラップトップから実行することになりますが、パイプラインの目的を損なうことになり、トレース性を弱めることになります。CIに組み込んで、ブランチまたはタグのルールでゲートし、リリースメタデータをビルド出力に残しておきましょう。サポートが後でトレースできるようにします。
正確なGitHubアクションズパターンについては CapgoのGitHubアクションズ統合ガイド は適切な参照点です。
CIパイプラインを実際の脅威から守る方法
CI/CDのセキュリティは、政府のガイドラインからも重要な問題と見なされています。NSAとCISAは、CI/CDのセキュリティを高めるために、セキュリティスキャンを統合する、監査ログを保存する、CI/CDの構成を署名する、SBOMとSCAを使用する、シークレットを平文で渡さないように保護する、災害復旧テストを実行して高可用性のビルドを行うことを推奨しています。 NSAとCISAのCI/CD強化ガイドライン実際のチームでは、問題が発生するパターンに合わせたフレーミングが便利です。 それは、漏洩したトークン、改ざんされた設定、過度に広範なデプロイ権限など、実際のチームで発生する問題に一致しています。
パイプラインの強化はアプリの強化と異なります。
A lot of guides talk about dependency scans, but ignore the CI system itself. That’s a mistake. If a compromised runner can print secrets, alter a signing step, or swap out an artifact before upload, the application code can be perfectly clean and still ship unsafe. Secure pipeline design means treating the runner, config, and credentials as production assets.
実行可能な設定は簡単です。
- パイプライン設定を署名してください。 不正なワークフロー編集を明確に表示する。
- ログから機密情報を除外する: クレデンシャル情報は、シェル出力経由で明示的に渡すべきではない。
- デプロイ権限の制限: production環境では、正しいブランチまたはタグのみが到達するようにする。
- Audit the run history: ログの詳細を十分に保存して、起こったことを再構築できるようにしてください。
- ビルドイメージと依存関係をスキャン: 特にElectronジョブがコンテナ化されたパッケージングを使用する場合。
認証と環境隔離には規律が必要です。
OIDCベースのクラウド認証は、長期間のクレデンシャルが多くの現代のCI設定でより適切な選択です。なぜなら、盗まれたトークンの影響範囲を狭めるからです。分離された環境アカウントと制限されたプロダクションアクセスも、誤ってプロモーションするリスクを減らします。 これらのパターンは、モバイルリリースパイプラインが時間の経過とともに意図せずに許可が増加することが多いハイブリッドチームにとって特に適しています。
依存関係のスキャンとシークレットの管理を含む。
作業中のパイプラインでも、簡単に改ざんできる場合はリスクが高くなります。セキュアなCIは、配布するアプリと同様の設計作業が必要であり、規制環境では必須です。
Most CI failures in Capacitor and Electron projects are symptoms of a few repeat offenders. If npm install is flaky, the runner environment is usually drifting. If Xcode times out, the job is often doing too much before the native build even starts. If Gradle runs out of memory, the packaging step is probably trying to do too much in one executor.
CIパイプラインの多くのエラーは、__CAPGO_KEEP_0__とElectronプロジェクトのいくつかの繰り返し犯行の症状です。__CAPGO_KEEP_1__のインストールが不安定な場合は、ランナー環境が通常漂流していることが多いです。Xcodeのタイムアウトは、ネイティブビルドが始まる前にジョブが多すぎることが多いです。Gradleがメモリを枯渇すると、パッケージングステップが1つのエグゼキュータで多すぎることが多いです。
症状に基づいて診断するのではなく、ツール名に基づいて診断するのではなく。 通常、キャッシュの不正または不安定なロックファイルのワークフローに原因がある。修正するには、クリーンインストールコマンドに依存し、パッケージマネージャーのバージョンを固定し、キャッシュの復元と実際のインストールステップを分離する。
Xcode ビルドエラー よくはランナーセットアップ、シミュレーターの実行環境の欠如、または証明書の状態に原因がある。macOS ジョブを環境の検証から始め、署名ステップを分離して、コンパイル時または認証時でエラーが発生するかを判断できるようにする。
Gradle メモリーアイテム Android と Web タスクが同じジョブを共有する場合、よくメモリーアイテムが発生する。ジョブの重複を減らし、Android ビルドステージを集中させ、同じステップ内に異なるシェルコマンドを埋め込まない。
Electron パッケージングの破損 通常、ネイティブモジュールの不一致またはパッケージング環境内にシステム依存関係の欠如に原因がある。ビルドコンテナを固定し、ネイティブ依存関係のインストールを確認する前にパッケージングし、署名後にアーティファクトを再構築しない。
速い修正は英雄的なデバッグより優れている
Capgo の公開エラーが表示された場合、最初に確認するのは、パイプラインが送信しているバンドルバージョンとチャンネル状態がパイプラインが認識しているものと一致しているかどうかである。マッチしないメタデータは、自動化されたライブアップデートフローにおける混乱の原因となる。公開ステップをパイプラインの最後の方に置き、ビルドが最終アセットを生成した後、部分的な出力をアップロードしないようにする。
時間を節約する習慣がある:
- 早く失敗する: lint とユニットテストをネイティブパッケージングの前に置く。
- 並列化する際に安全性を確保する: iOS、Android、Electronジョブは共有Webビルド後、他のジョブに待たなくてもよい。
- アーティファクトを表示する: 出力が確認できない場合、リリースを信頼できない。
- 各ジョブをトリミングする: 1つのジョブは1つのタスクをうまくこなすべきだ。
Hybridアプリパイプラインがまだ手動署名、非公式アップロード、ドキュメント化されていないステップを知る数人の人によって維持されている場合、それを直すのではなくプロセスを直す時が来た。CapgoはCapacitorとElectronチームに自動署名されたライブアップデート、リリースをチャネルを通じてルーティングする、同じワークフロー内でトレース性を維持する方法を与える。Visit Capgo __CAPGO_KEEP_0__
