アプリが完成しました。ブラウザで動作し、UIが正しく、コアフローが安定しています。すると、デプロイが現れ、直線的なIonicプロジェクトを3つの異なるリリーストラックに変え、各トラックには独自のツール、署名ルール、レビュープロセス、およびアップデート戦略があります。
時間が失われるのは、特に機能を書くことではなく、ネイティブビルド、Webホスティング、リリースの自動化、およびリリース後の修正を1つのプロセスに組み合わせることです。 Ionic アプリのデプロイ iOS、Android、PWA の配信を別々のプロジェクトとして扱うのではなく、1 つのリリースシステムとして扱うことで、最も効果的な結果が得られます。
目次
- あなたの Ionic アプリは完成しました。次は?
- プロダクション用にプロジェクトを準備する
- iOS と Android 用のネイティブ デプロイ
- PWAとしてIonicアプリを展開する
- CI/CD Pipelinesを使用したビルドの自動化
- Capgoを使用した即時更新
- 一般的なデプロイ問題とベストプラクティス
あなたのIonicアプリは完成しました。次は何をしますか。
ほとんどの開発者は同じポイントに到達します。 ionic serve 見た目は良く、ローカルAPI呼び出しは正常に動作し、アプリは完了したように感じます。実際にはまだ完了していません。ブラウザでのみテストされており、署名されていません。また、App Storeのレビュー、Playの署名、プロダクションWebホスティングの制約から切り離されています。
プロダクションデプロイは質問の内容を変える。アプリがレンダリングされるかどうかを尋ねるのではなく、 バンドルが再現可能かどうかネイティブプロジェクトが同期されているかどうか
環境変数がきれいに分離されているかどうか
リリース後に非ネイティブのバグを修正することができるかどうか、そしてそれがストアの再提出スキャンダルを生み出すことなく
- それが重要なのは、Ionicはハイブリッドのレーンに位置しています。アプリにはWeb層がありますが、ネイティブシェルはアプリがインストール、署名、レビュー、更新される方法を決定します。デプロイを後回しに扱うチームは、プラットフォーム間の構成ドリフト、古いネイティブプロジェクト、脆弱な手動リリースステップに陥ることがよくあります。デプロイをうまく行うチームは、すべてのターゲットに共通するリリースパスを定義し、各プラットフォーム固有のステップを明確にします。 Capacitor の設定、アプリ識別子、アイコン、環境値、そしてプロダクション ビルドが一貫しているようにする。
- ネイティブ リリース アーティファクトを作成する Android と iOS に対してプラットフォーム ツールを使用し、Ionic コマンドのみに頼るのではなく。
- PWA ビルドを配信する ブラウザに即座にアクセスできるユーザー向けに。
- 定例作業を自動化する ビルドが 1 人の開発者がチェックリストを思い出すのではなく、依存するのではなく。
- リリース後の更新計画を立てる ウェブ アセットの修正がアプリ ストアのレビューに待たされるのではなく、必要に応じて待たなくする。
現在のアプリが「スマートフォンシェル内で開くウェブアプリ」に思えている場合は、その問題を解決することから始めましょう。参考になるのは、この __CAPGO_KEEP_0__ のガイドです。 turning a web app into a mobile app with Capacitor.
Your first successful store submission usually comes from discipline, not cleverness.
プロダクション用にプロジェクトを準備する
ビルドを生成する前に、プロジェクトをリリース候補として扱ってください。多くの場合、ローカル開発で無害だった小さな不一致が、プロダクションで高価な問題の原因となります。
環境チェックから始める
基本的なものから始めましょう:
ionic doctor
npm ci
npx cap doctorionic doctor 一般的なCLIと環境問題をキャッチします。 npm ci リリース用の作業に適しているのは、ロックファイルから厳密にコミットされたものと同じようにインストールされるためです。 npm install プラグインとプラットフォームの不一致を表面化させるのに役立ちます。XcodeまたはAndroid Studioがそれらを、読みにくいエラーに変換する前に。 npx cap doctor 可能な限り、リリースビルドからクリーンな状態で使用してください。アプリがローカルパッチ、削除されたフォルダ、または手動で編集されたネイティブファイルの存在でしかビルドされない場合、デプロイプロセスはまだ安定していません。
何度も行う価値があるチェックは以下のとおりです:
アプリIDを確認する
- プロダクション用にプロジェクトを準備する. 変更
appId遅延すると、ストアと署名の混乱が生じる可能性があります。 - プラグインの状態を確認. ネイティブ プラグインの変更は通常、最新の Sync が必要であり、場合によってはプラットフォームのリロードも必要です。
- 環境のインジェクションを確認. API エンドポイント、キー、機能フラグは、環境固有の構成からではなく、インライン定数から取得するべきです。
開発と __CAPGO_KEEP_0__ アプリのプロダクションでの違いについての詳細な説明は、この記事 development vs production differences in Capacitor apps __CAPGO_KEEP_0__ 設定をロック
Lock down Capacitor config
そして、プロダクションインフラストラクチャのようにではなく、アプリメタデータのように、レビューしてください。 capacitor.config.ts Open
A typical file looks like this:
import type { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = {
appId: 'com.example.myapp',
appName: 'My App',
webDir: 'www',
bundledWebRuntime: false,
};
export default config;Three fields matter immediately:
| 設定 | なぜ重要 | よくある間違い |
|---|---|---|
| appId | ネイティブストアや署名用に使用されるパッケージ識別子 | スターター プロジェクトからプレースホルダーを残す |
| appName | ネイティブシェル上でのユーザーフェイス用アプリ名 | 開発用ラベルを使用し、変更を忘れる |
| webDir | ディレクトリ Capacitor はネイティブ プロジェクトにコピーします | Capacitor が期待する出力フォルダとは異なる出力フォルダにビルドします |
開発中のローカル開発サーバーを使用する場合は、プロダクション設定がネイティブ ビルドにローカル開発サーバーを指していることを確認してください。 その単一のミスは、開発時は機能するがリリース時は白い画面が表示されるという問題が多発します。
実用的なルール: リリース ビルドが実行中のローカル サーバー設定に依存している場合、それはリリース ビルドではありません。
アセットを一度生成する
アイコンとスプラッシュ画面を手動でサイズを変更しないでください。高品質のソース アセットを 1 つだけ使用し、プラットフォームの出力からそれを生成してください。
現在の Capacitor ワークフローでは、多くのチームは CLI エコシステムを通じて公式のアセット ツールを使用しています。 スタック バージョンによってパッケージが異なるかもしれませんが、規範は同じです: バージョン管理下に 1 つの標準的なアイコンと 1 つの標準的なスプラッシュ ソースを保管し、出力を生成し、Xcode と Android Studio 内で結果を確認することです。 提出前に。
これは、PWA アイコンが最新の状態であるのに対し、Android は古い前景アセットを使用し、iOS は古い起動画像を表示しているというよく知られた失敗モードを回避するためです。
堅固なプロダクション パスには次のことが含まれます。
- Web アセットをプロダクション モードでビルドします。
- ネイティブ プロジェクトを同期します
- 各native IDEでアプリ名、アイコン、パーミッション、署名設定を手動で確認してください。
- 実機でテストする前に、ストアにパッケージするものは何もありません。
iOSとAndroid向けのNative Deployment
Native Deploymentは、Ionicアプリが「ただのWeb」からプラットフォームの規則に応えるようになる場所です。Webバンドルは共有できますが、署名、パッケージング、ストアの要件がプロセスに入ると、AndroidとiOSはすぐに分岐します。
Web層を最初にビルドする
常にWebアセットを最新の状態に保つことから始めて、ネイティブパッケージングに触れるまでは:
ionic build
npx cap sync古い慣習のままなチームもまだあります。 ionic build --prod 現代のプロジェクトでは、フレームワークのツールによって生産時の動作は正確に決まりますが、原則は変わりません: 最適化されたリリースビルドを生成し、次にネイティブプラットフォームにSyncします。
Sync後、ネイティブプロジェクトを開く:
npx cap open android
npx cap open iosこの時点で、ネイティブプロジェクトの設定を確認するのもよいタイミングです。 Capacitorアプリ用のAndroid設定 プロジェクトが不安定なネイティブ設定を持っている場合。
Android リリースワークフロー
Android のリリースパスは通常 iOS より予測可能ですが、署名設定が適切に設定されていないと破綻します。
アップロードキーストアを一度生成し、安全に保存してください。
keytool -genkeypair -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias uploadキーストアファイル、エイリアス、パスワードを安全なシークレットストアに保存してください。コミットしないでください。チームチャットに残してはいけません。誰かが保存したと仮定してはいけません。
次に、Gradle に署名を接続してください。チームは、この設定をファイルまたは Android Studio の署名 UI に依存するか、どの部分をスクリプト化したいかによって設定します。一般的なセットアップには、ブロックとリリースビルドタイプが含まれます。どちらも、署名設定に指示しています。 build.gradle Play Store への提出用に通常使用される Android アーティファクトは AAB です。デバッグ APK ではありません。Android Studio を使用して、メニューのパスを使用して署名されたバンドルを生成し、リリースバリアントを選択し、アプリバンドルをエクスポートしてください。コマンドラインビルドを好みますか? Gradle は署名設定が完了したらそれもできます。 signingConfigs Android の一般的な落とし穴は、熟知した形で現れます。
__CAPGO_KEEP_0__ __CAPGO_KEEP_0____CAPGO_KEEP_0__
__CAPGO_KEEP_0__
- 誤ったキーストアパスワード 正確に言うと、エラーはそれほど深刻ではありません。
- デバッグのために残した署名 ローカルにインストールするビルドを作成しますが、ストアのリリースには有効ではありません。
- プラグインの不整合 プラグインのネイティブ依存関係を変更し、スキップした場合に発生します。
npx cap sync. - 一致しないパッケージ名 Play Consoleアプリのエントリが異なる識別子で作成された場合に問題が生じます。
効果的なパターンは次のとおりです: web code にコミットし、web層をビルドし、ネイティブを同期し、ネイティブプロジェクトからリリースアーティファクトをビルドし、生成されたバンドルと共に精確なコミットハッシュをアーカイブします。
iOSリリースワークフロー
iOSは厳格で、ほとんどのデプロイメントのトラブルは署名識別子混乱によるものではなく、code問題によるものではありません。
Xcodeでプロジェクトを開き、直接 署名 & 能力__CAPGO_KEEP_0__
通常、以下の要素と戦うことになります:
| アイテム | 何をするか | 人が足りないところ |
|---|---|---|
| Bundle identifier | アプリをApp Storeのレコードとプロビジョニングに紐付け | Appleの期待と一致しない |
| 証明書 | 署名者を特定 | 誤った証明書がインストールされているか、期限切れ |
| プロビジョニングプロファイル | 特定のアプリとコンテキストに対してビルドを承認します | プロファイルがアプリIDまたはチームと一致しません |
ローカルリリース用にアプリをXcodeでビルドし、物理デバイスまたはiOSの汎用デバイスのターゲットを選択し、次に アーカイブアーカイブが完了したら、Organizerウィンドウを使用してApp Store Connectに検証および配布します。
Xcodeが署名が破綻している場合、正確なバンドルID、チーム名、プロファイル名を読み、変更する前に何も変更しないでください。ランダムに証明書を再生成すると問題が悪化する可能性があります。
Macを持っていない場合でも、実際のiOSリリースアーティファクトを生成するにはmacOS環境が必要です。実際には、チームはローカルMac、レンタルクラウドMac、またはmacOSビルドを実行するモバイルCI/CDサービスを使用してそれを解決しています。
最初のアーカイブと提出のための便利なプライマーとしてこのウォークスルーを使用してください。
もう１つの難しい教訓：生成されたネイティブファイルを気軽に編集しないでください。繰り返し可能な構成を正しいプロジェクト設定、プラグイン設定、ビルドスクリプトに置きます。誰もドキュメントを残さない手動編集がなぜか一度リリースが成功し、次の開発者がプロジェクトを同期したときに失敗するのはなぜですか。
IonicアプリをPWAとしてデプロイする
PWAパスはIonicアプリにユーザーに最速のルートを提供します。ストアのレビューはありません。署名の式典はありません。インストールの摩擦はありません。ブラウザから即座にアクセスできる必要がある人にとっては、必要なものだけです。
ネイティブアプリが主なチャネルである場合でも、そのスピードは有用です。多くのチームは、内部ツール、ログイン前エクスペリエンス、管理パネル、またはストアのインストールが不要な抵抗を加える市場など、パラレル配布サーフェイスとしてPWAを使用しています。
ウェブに意図的に作ります
PWAは、プロダクションウェブビルドから始まります:
ionic build重要なのはコマンド自体ではなく、出力が最適化されているか、プロダクションサービスに指示されているか、最終的なアセットとマニフェストが含まれているかということです。
配布する前に、これらのファイルを確認してください:
index.html__CAPGO_KEEP_0__は、正しいコンパイルされたアセットを参照していることを確認してください。manifest.webmanifest__CAPGO_KEEP_0__は、プロダクション名、アイコン、表示設定が必要なものだけを含んでいます。- サービスワーカーファイル __CAPGO_KEEP_0__は、オフラインキャッシュを使用する場合にのみ存在する必要があります。
- 環境出力 __CAPGO_KEEP_0__は、ライブエンドポイントを参照していることを確認してください。ローカルまたはステージングサービスは含めないでください。
オフライン動作を慎重に有効にしてください
Ionic スタックが Angular を使用している場合、Angular のサービス ワーカーはオフライン サポートとキャッシュの通常のパスです。強力ですが、誤設定しやすい。
過度にキャッシュすると、ユーザーは古いデータに固定されます。キャッシュが少なすぎると、アプリが不安定なときに接続が不安定になるように感じます。正しい設定はアプリによって異なります。マーケティング向けシェルではキャッシュを重視しますが、迅速に変化する運用データを持つダッシュボードではconservative戦略が必要です。
オフライン サポートを製品の決定として扱い、チェックボックスではありません。ある画面はキャッシュする必要がありますが、常に最新のデータを取得する画面もあります。
実際のシナリオをテストし、Lighthouse-styleの仮定だけではありません。アプリを開き、デバイスを切断し、再起動し、まだ機能するものを調べます。その後、再接続し、サービス ワーカーが古い UI にユーザーを閉じ込めないように更新されることを確認します。
Ionic PWAsのホスティングはワークフローに基づいて選択します。
静的ホスティング プラットフォームは通常、Ionic PWAsのための十分です。チームが最もよく利用するのはNetlify、Vercel、Firebase Hostingです。
実用的なトレードオフの視点は次のとおりです。
| プラットフォーム | ベスト フィット | 注意する |
|---|---|---|
| Netlify | シンプルな静的デプロイとプレビュー | リダイレクトの動作は明示的に確認する必要があります。 |
| Vercel | Gitベースのワークフローを使用しているフロントエンド重視のチーム | あるいは、特定のアプリのルーティング設定が調整が必要 |
| Firebase Hosting | Firebaseサービスを使用しているチーム | プロジェクト構造が複雑になる可能性がある |
どのホスティングサービスでも、リポジトリを接続し、ビルドコマンドを設定し、出力ディレクトリを設定し、環境変数を追加し、リライトルールを確認し、クライアントサイドのルーティングがリフレッシュ時に破綻しないようにするという手順は、以下のようになります。
Ionicアプリがルーターベースのナビゲーションを使用している場合、ホスティング設定では、未一致のパスをアプリのエントリポイントに戻すように設定する必要があります。そうしないと、ホームページが正常に動作し、ディープリンクが失敗することになります。そのようなPWAのデプロイミスは最も一般的なものです。
CI/CDパイプラインを使用したビルドの自動化
手動のリリース作業は一度は許容できますが、その後はリスクとなります。誰かがSyncステップを忘れるか、誰かが汚れたブランチからビルドするか、誰かが誤った設定で署名するなど、突然生成されたアーティファクトが信頼できなくなることがあります。
CI/CDはそれを修正することで、リリースシーケンスをcodeに変換します。記憶に頼るのではなく、毎回アプリがどのようにビルド、Sync、テスト、パッケージ化されるかを明確に定義することで、生成されたアーティファクトの信頼性を確保します。
pipelineに含めるものは?
Ionicプロジェクトの場合、有用なpipelineは、次の順序でこれらの作業を行うことがよくあります:
- ロックファイルから依存関係をインストールする。
- ウェブアプリケーションをビルドする。
- Capacitorプラットフォームを同期する。
- テストを実行するか、少なくとも基本的な検証を行う。
- ターゲットプラットフォーム向けのネイティブアーティファクトを生成する。
- ビルド出力を格納または公開する。
その流れは、良いインフラストラクチャの習慣が重要です。ビルドランナー、アーティファクトストレージ、またはデプロイメントステップが脆弱な場合、この小規模企業向けの クラウド最適化の基本 のガイドを読む価値があります。同様の運用の規範はモバイル配信pipelineにも適用されます。
A practical GitHub Actions の形状
GitHub Actions は、多くの Ionic チームがすでに code を GitHub にホストしているため、良いデフォルトです。以下のワークフローは、Android リリースビルドの全体的な形状を示しています。
name: Android Release Build
on:
push:
branches:
- main
jobs:
build-android:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Build web assets
run: npm run build
- name: Sync Capacitor
run: npx cap sync android
- name: Setup Java
uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
- name: Build Android bundle
run: cd android && ./gradlew bundleReleaseこれは単独ではリリースを署名しないので、キーストアの材料とGradleの署名設定も提供する必要があります。そうするのは意図的なことです。署名は、パブリックワークフロー ファイルから分離されるべきです。
モバイルに焦点を当てた実装パスを求めている場合は、この __CAPGO_KEEP_0__ アプリのための CI/CD の設定方法についてのこの投稿が直接関連しています。 setting up CI/CD for Capacitor apps モバイル CI/CD の最難関は、YAML を書くことではありません。将来のインシデントを引き起こさないようにシークレットを扱うことです。
以下のシークレットをリポジトリまたは組織のシークレットで使用してください。
キーストアのパスワード
キー アリセス
- エンコードされたキーストア ファイル
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_1__
- API のリリース中に使用されるトークン
- 環境依存のビルド値
Android の一般的なパターンは、キーストアを base64 でエンコードし、エンコードされた文字列をシークレットに格納し、ワークフロー中に再構築し、Gradle に再構築されたファイルを指示することです。同様の原則は、署名材料に適用されます: ビルド時に挿入し、リポジトリに格納しないようにします。
CI/CD は人間のエラーを排除するのではなく、隠された部族の知識を集中させるべきではありません。開発者が 1 人だけがリリースシークレットの組み合わせを理解している場合、pipeline は依然として脆弱です。
実践的な推奨事項: 検証とリリースを分離する。Pull Request はインストール、lint、テスト、Web ビルドを実行し、保護されたブランチまたは手動の承認ゲートが署名されたプロダクションアーティファクトをトリガーする。そうすると、正常な開発のためにパイプラインを速くし、実際の配布のために制御することができます。
Capgo を使用して即時配信
リリースストアは、ネイティブ code の変更、許可の変更、またはアプリバイナリを変更するものは必要ですが、テキストの修正、スタイリングの修正、または JavaScript のバグがすべて Web 層に存在するものは、すべてのテキストの修正、スタイリングの修正、または JavaScript のバグには適していません。
なぜなら OTA の更新 Ionic と Capacitor のプロジェクトでは、OTA の更新は重要です。チームは、インストール済みアプリに更新された Web アセットを配信できるようになり、ストアのレビューを待つ必要がなくなります。ただし、ネイティブシェルがすでにサポートしている範囲内に変更が含まれる限りです。
OTA の更新は何を処理するべきか
OTAのアップデートを使用して、以下のような変更を行います。
- JavaScriptのロジック修正 新しいネイティブプラグインのリリースが必要ない修正
- CSSの調整 レイアウトの問題やブランドの更新など
- コピーの変更 文言、ラベル、法的テキストなど
- 静的アセットの交換 アプリが既にロードする方法を知っている場合
実際のネイティブの変更としては使用しないでください。新しいネイティブ依存関係を追加したり、権限を変更したり、ストアでレビューされたバイナリに含まれるものを変更したりすると、通常のストアリリースを出します。
その境界は重要です。OTAの主な目的は、速度と制御です。プラットフォームの規則を無責任に回避するのではなく。
最初のインシデント前にチャンネルを設定してください
The best OTA workflows use __CAPGO_KEEP_0__. では、安定した更新をユーザーに提供する。 では、更新を最初に受け取るので、内部テスターは実際のインストール済みアプリでテストできます。
そのパターンは、直感的に急いでいるため、直ちに全員にプッシュすることの最悪のOTAミスを避けるのに役立ちます。
急いでいる修正も、ガードレールが必要です。 通常のセットアップはプラットフォームのドキュメントに従ってプラグインのインストールとアプリの初期化から始まり、環境ごとにチャンネルの割り当てに続きます。 でのアプリストア安全なOTA更新に関する記事は、正しく境界を設定するための良好な参照点です。
小さな修正をプッシュするには、ネイティブのcodeを触る必要はありません。
アップデータが組み込まれた後、実用的なワークフローは簡単になります。
更新されたWebアセットをビルドし、目的のチャンネルに公開し、更新ポリシーに従ってアプリが起動したときに取得して適用するだけです。
- 実際の例は、モバイルレイアウトのリグレッションのためのホットフィックスです。
- IonicsアプリのCSSを調整します。
- ステージングチャンネルに結果のバンドルを公開します。
- インストール済みのビルドでテストします。
- 同じ修正をプロダクションにプッシュまたは公開します。
そのアプローチは、インシデント対応を変える。OTAがなければ、悪いウェブ層のバグは、ストアレビューとユーザーの新しいバイナリの採用を待たなければなりません。 OTAがあれば、影響を受けたファイルを修正し、正しいユーザーに送信し、制御された方法でロールアウトを観察できます。
迅速な更新は、安全にターゲットを設定し、必要に応じてロールバックできる場合にのみ有用です。
OTAの利益を受けるチームは、無神経なチームではありません。明確なリリース境界、名前の付いたチャンネル、ウェブ層の修正をネイティブリリースから別のストリームとして扱う習慣を持つ、規律のあるチームです。
一般的なデプロイ問題とベストプラクティス
ほとんどのデプロイ問題は、ユニークではない。同じミスが、締切の圧力下で繰り返される。
繰り返し現れる失敗
Androidの署名エラーは、通常、間違ったパスワード、間違ったエイリアス、または間違ったキーストアーファイルがリリース構成で使用されていることです。そうすると、暗号化を無理に回すのではなく、ファイル、エイリアス、シークレット値を最初に検証してください。
iOSのビルドエラーは、通常、バンドル識別子、チームの選択、証明書、プロビジョニングプロファイルの間の不一致に戻ります。 Xcodeのエラーメッセージは密集しているかもしれませんが、不一致は通常、Literalです。 1 つの値は、他の値と一致しません。
インストール後に白い画面が表示されることは、クラシックのもう１つの例です。一般的な原因には、次のものがあります:
- 開発サーバーにアプリを指す __CAPGO_KEEP_0__
- バンドルされた資産が更新されない 前
npx cap sync - プラグインの変更が同期されない ネイティブプロジェクトに
- 実行環境の値が欠落している 実際のリリースビルド
リリースの習慣が再作業を防ぐ
ベストプラクティスは面白くないが、それが機能する理由
環境設定の真実の１つを保つ。クリーンなブランチからビルドする。リリースコミットをタグする。署名材料をリポジトリ外に保つ。実機でインストールしたビルドをテストする。シミュレータやブラウザタブだけでは十分ではない。ストアメタデータを早期に準備する。デプロイメントがスクリンショット、プライバシーアンサー、または欠落しているコピーに遅れるのを防ぐ。
１つの習慣が多くの痛みを救う：自動化が実行された後でも、書き留めたリリースチェックリストを保つ。パイプラインはアーティファクトをビルドする。アプリの説明が最新か、サポートURLが正しいか、最新のネイティブパーミッション文字列がアプリの動作と一致しているかを確認するのではない。
あなたのチームが Capacitor アプリをリリースし、リリース後ウェブ層の修正を安全に提供したい場合 Capgo は評価する価値がある。チャンネル、制御されたロールアウト、ロールバック機能を備えた構造化されたOTAワークフローを提供するため、JavaScript、CSS、コピー、資産の更新を実行できます。小さな修正をアプリストアの再提出に変えるのではなく。
