あなたはアプリを完成させました。 ブラウザで動作するようになり、UIが正しく感じられ、コアフローが安定している。 すると、デプロイが現れ、イオニックプロジェクトを3つの異なるリリーストラックに変えて、各トラックごとに独自のツール、署名ルール、レビュープロセス、およびアップデート戦略が必要になります。
あなたはアプリを完成させました。 ブラウザで動作するようになり、UIが正しく感じられ、コアフローが安定している。 すると、デプロイが現れ、イオニックプロジェクトを3つの異なるリリーストラックに変えて、各トラックごとに独自のツール、署名ルール、レビュープロセス、およびアップデート戦略が必要になります。 そのような時間は、機能を書くことではなく、ネイティブビルド、ウェブホスティング、リリースの自動化、およびリリース後の修正を組み合わせて、繰り返すことができるプロセスを作成することです。 イオニックアプリのデプロイ iOS、Android、PWAの配信を別々のプロジェクトとして扱うのではなく、1つのリリースシステムとして扱うことで、最も効果的な結果が得られます。
目次
- あなたのイオニックアプリは完成しました。次は?
- 本番用にプロジェクトを準備する
- iOSとAndroid向けのネイティブデプロイ
- IonicアプリのPWAとしての展開
- CI/CD Pipelinesを使用したビルドの自動化
- Capgoを使用した即時更新の配信
- 一般的な展開問題とベストプラクティス
あなたのイオニックアプリは作成されました。なぜか?
ほとんどの開発者は同じポイントに到達します。 ionic serve 見た目は素晴らしい、ローカルAPI呼び出しは正常に動作し、アプリは完了したように感じます。完了していません。ブラウザでしかテストされていません、署名されていません、App Storeのレビュー、Playの署名、プロダクションのWebホスティングの制約から切り離されています。
プロダクション展開は、質問する内容が変わります。アプリがレンダリングされるかどうかではなく、 バンドルが再現可能かネイティブプロジェクトが同期されているか
環境変数がきれいに分離されているか
リリース後に非ネイティブのバグを修正することができるか、ストアの再提出スキャンダルを生み出さないようにする
- そのシフトは重要です。イオニックはハイブリッドのレーンに位置しています。アプリにはWeb層がありますが、ネイティブシェルはアプリがインストールされる、署名される、レビューされる、更新される方法を決定します。展開をあとから考えるチームは、プラットフォーム間の構成ドリフト、古いネイティブプロジェクト、脆弱な手動リリースステップに終わります。展開をうまく行うチームは、すべてのターゲットに対して一つのリリースパスを定義し、各プラットフォーム固有のステップを明確にします。 Capacitor の設定、アプリ識別子、アイコン、環境値、そしてプロダクション ビルドは一貫している。
- Android と iOS 用のネイティブ リリース アーティファクトを作成 プラットフォーム ツールを使用して Ionic コマンドのみでなく、iOS と Android 用のネイティブ リリース アーティファクトを作成
- PWA ビルドを配信 PWA ビルドを配信して、即時ブラウザ アクセスが必要なユーザーに提供
- 自動化して、開発者がチェックリストを思い出す必要がなくなるようにビルドのルーチン部分を実行 リリース後のアップデートを計画
- ウェブ アセットの修正がアプリ ストアのレビューに待たされる必要がなくなるようにウェブ アセットの修正をリリース後のアップデートに含める 現在のアプリが「スマートフォンシェル内で開くウェブアプリ」に感じられる場合は、その移行を修正することから始めましょう。移行の参考となるガイドは __CAPGO_KEEP_0__ の「ウェブアプリをモバイルアプリに変える方法」です。
初めての成功したストアの提出は、知恵ではなく、 discipline から生まれます。 Capacitor は、ウェブアプリをモバイルアプリに変える方法.
初めての成功したストアの提出は、知恵ではなく、 discipline から生まれます。
プロジェクトを本番環境に準備する
本番用ビルドを生成する前に、プロジェクトをリリース候補として扱う。多くの場合、ローカル開発で無害だった小さな不一致が本番環境では高コストになるのは、リリースの際の小さなミスによるものである。
環境チェックから始める
基本的なものから始める:
ionic doctor
npm ci
npx cap doctorionic doctor catches common CLI and environment issues. npm ci リリース用作業では、より安全なオプションである。 npm install ロックファイルから正確にコミットされた状態でインストールされるため。 npx cap doctor プラグインやプラットフォームの不一致を表面化させるのに役立つ。
可能な限り、リリースビルドをクリーンな状態から使用する。アプリがローカルで修正した後、削除されたフォルダ、または手動で編集されたネイティブファイルの場合、デプロイメントプロセスはまだ安定していない。
毎回行うべきチェックはある:
- アプリIDを検証する. 変更
appId遅延した変更は、ストアと署名の混乱を生み出す可能性があります。 - プラグインの状態を確認. ネイティブ プラグインの変更は通常、最新の同期が必要であり、場合によってはプラットフォームの再起動も必要です。
- 環境のインジェクションを確認. API エンドポイント、キー、機能フラグは、環境固有の構成からではなく、インライン定数から取得するべきです。
リリースターゲット間で異なるべきものの詳細な説明については、この記事 開発と Capacitor アプリの生産環境における違い は、実用的な参考資料です。
Capacitor 構成をロック
Open capacitor.config.ts と、生産インフラと同様に、プロダクションインフラを確認してください。
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 | Native package identifier used by stores and signing | スターター プロジェクトからプレースホルダーを残す |
| appName | Native shell でのユーザー向けアプリ名 | 開発用ラベルを使用し、変更を忘れる |
| webDir | ディレクトリ Capacitor がネイティブプロジェクトにコピーします | ビルドを Capacitor が期待する出力フォルダとは異なるフォルダにします |
開発中のローカル開発サーバーを使用する場合は、生産設定がネイティブビルドをそのサーバーに指すことを確認してください。 その単一のミスは、開発で正常に動作し、リリースで白い画面が表示されるという事故が多く発生します。
実践的なルール: リリースビルドがライブのローカルサーバー設定に依存している場合、それはリリースビルドではありません。
アセットを一度生成します
アイコンとスプラッシュスクリーンを手動でサイズ変更しないでください。高品質のソースアセットを1つ使用し、それを各プラットフォームの出力に生成します。
現在の Capacitor ワークフローでは、多くのチームが CLI エコシステムを通じて公式のアセットツールを使用しています。パッケージのバージョンによっては異なる場合がありますが、ディスクiplineは同じです: バージョン管理下で1つの標準的なアイコンと1つの標準的なスプラッシュソースを保管し、出力を生成し、XcodeとAndroid Studioで結果を確認することです。
これにより、PWAアイコンが最新の状態であるのに対し、Androidが古い前景アセットを使用し、iOSが古い起動画像を表示するという、フォルダが更新されなかったことで発生するよく知られたエラーを回避できます。
堅固な生産パスには次のことが含まれます:
- Webアセットを生産モードでビルドします
- ネイティブプロジェクトを同期します
- 各のネイティブIDEを開いて、アプリ名、アイコン、パーミッション、署名設定を手動で確認してください。
- ストアにパッケージする前に、実機でテストしてください。
iOSとAndroid向けのネイティブデプロイ
ネイティブデプロイは、Ionicアプリが「ただのウェブ」からプラットフォームの規則に応えるようになる場所です。ウェブバンドルは共有できますが、署名、パッケージング、ストアの要件がプロセスに入ると、AndroidとiOSはすぐに分岐します。
ウェブ層を最初にビルドしてください。
ネイティブパッケージングに触れる前に、常に最新のウェブアセットを生成してください:
ionic build
npx cap sync古い慣習から来ています。 ionic build --prod 現代のプロジェクトでは、フレームワークのツールによって実行時の動作は異なりますが、原則は変わりません: 最適化されたリリースビルドを生成し、それをネイティブプラットフォームにSyncしてください。
Sync後、ネイティブプロジェクトを開いてください:
npx cap open android
npx cap open iosこの時点で、Androidの設定を確認することもおすすめです。 AndroidのCapacitorアプリの設定 プロジェクトが不安定なネイティブ設定を持っている場合。
Android リリース ワークフロー
Android のリリース パスは通常 iOS よりも予測可能ですが、署名設定が適切に設定されていないと破綻します。
アップロード キーストアを 1 回生成し、安全に保存してください:
keytool -genkeypair -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias uploadキーストア ファイル、エイリアス、パスワードを安全なシークレット ストアに保存してください。コミットしないでください。チーム チャットに残さないでください。誰かが保存したと仮定しないでください。
次に、Gradle に署名を組み込んでください。チームは、このプロセスをファイルに設定するか、Android Studio の署名 UI を使用するか、どちらかを選択することができます。プロセスをスクリプト化したい場合は、どちらかを選択することができます。一般的なセットアップには、ブロックとリリース ビルド タイプが含まれます。リリース タイプはブロックに指示します。 build.gradle Play Store への提出用のリリース アーティファクトは、通常、AAB です。デバッグ APK ではありません。Android Studio を使用して、メニュー パスから署名されたバンドルを生成し、リリース バリアントを選択し、アプリ バンドルをエクスポートしてください。コマンド ライン ビルドを好みます。Gradle は署名が設定された場合にそれを処理できます。 signingConfigs Android の一般的な落とし穴は、熟知された方法で現れます:
__CAPGO_KEEP_0__ __CAPGO_KEEP_0____CAPGO_KEEP_0__
__CAPGO_KEEP_0__
- 不正のキーストアパスワード 不正のキーストアパスワードは、より劇的な失敗に見えるが実際にはそれほど深刻な問題ではありません。
- デバッグの署名残り物 ローカルにインストールできるビルドを作成しますが、ストアのリリースには有効ではありません。
- プラグインの不整合 プラグインのネイティブ依存関係を変更し、スキップした場合に発生します。
npx cap sync. - 機能するパターンは次のとおりです: コミット __CAPGO_KEEP_0__、ウェブ層をビルドし、ネイティブを同期し、ネイティブプロジェクトからリリースアーティファクトをビルドし、生成されたバンドルに精確なコミットハッシュをアーカイブします。 iOS リリースワークフロー
iOS は厳格で、署名識別子混乱による問題が code 問題よりも多くのトラブルを引き起こします。
Xcode でプロジェクトを開き、直接
iOS is stricter, and most deployment trouble comes from signing identity confusion rather than code problems.
Open the project in Xcode and go straight to 署名 & 能力. 選択したチームが正しいことを確認し、バンドル識別子が送信するアプリレコードと一致し、自動署名が期待どおりに機能しているか、または意図的に手動プロビジョニングに置き換えられていることを確認してください。
通常、これらの動的要素と対処します:
| アイテム | 機能 | 人が足りないところ |
|---|---|---|
| バンドル識別子 | アプリをApp Storeレコードとプロビジョニングと結びつける | Appleが期待しているものと一致しない |
| 証明書 | 署名者を特定する | 誤った証明書がインストールされているか、期限切れである |
| Capgoビルダー | 特定のアプリとコンテキストに対してビルドを承認 | プロファイルはアプリIDまたはチームと一致しません |
ローカルリリース用の作業の場合、Xcodeでアプリをビルドし、物理デバイスまたは汎用iOSデバイスのターゲットを選択し、次に アーカイブ.アーカイブが完了したら、オーガナイザー画面で検証し、App Store Connectに配布します。
Xcodeが署名が破綻している場合、正確にバンドルID、チーム名、プロファイル名を読み、変更する前に
何も変更しないでください。ランダムに証明書を再生成すると問題が悪化することがよくあります。
Macを持っていない場合でも、実際のiOSリリースアーティファクトを生成するにはmacOS環境が必要です。実際には、チームはローカルMac、レンタルクラウドMac、またはmacOSビルドを実行するモバイルCI/CDサービスを使用して問題を解決しています。
このウォークスルーは、最初のアーカイブと提出のための便利なプリマーです:
もう一つの難い教訓:生成されたネイティブファイルを気軽に編集しないでください。繰り返し設定をプロジェクト設定、プラグイン設定、ビルドスクリプトに置きましょう。誰もドキュメントを残さない手作業の編集は、リリースが一度成功した後、次回の開発者がプロジェクトを同期したときに失敗する原因になります。
IonicアプリをPWAとして展開する
nativeアプリが主なチャネルである場合でも、そのスピードは有用です。多くのチームは、内部ツール、ログイン前エクスペリエンス、管理パネル、またはストアのインストールが必要な市場など、パラレルな配布面としてPWAを使用しています。
ウェブに意図的に作ります。
あなたのPWAは、プロダクションウェブビルドから始まります。
ionic build重要なのは、コマンド自体ではなく、出力が最適化されているかどうか、プロダクションサービスに指示されているかどうか、そして、出荷する最終的なアセットとマニフェストが含まれているかどうかです。
配布する前に、これらのファイルを確認してください。
index.html正しいコンパイルされたアセットを参照していることを確認してください。manifest.webmanifestプロダクション名、アイコン、表示設定が必要なものが含まれていることを確認してください。- サービスワーカーファイル オフラインキャッシュを使用する場合にのみ存在するようにしてください。
- 環境出力 ライブエンドポイントを参照していることを確認してください。ローカルまたはステージングサービスは含めないでください。
オフライン動作を慎重に有効にしてください
Angularサービスワーカーは、オフラインサポートとキャッシュの通常のパスです。強力ですが、誤設定しやすい。
データが古くなってユーザーがストックされるのを防ぐためにキャッシュを過度に積極的に設定すると、逆にユーザーが古いデータにストックされることになる。キャッシュを少なすぎると、接続が不安定になってもアプリが頑丈に感じられない。
オフラインサポートは製品の決定事項であり、チェックボックスではありません。ある画面はキャッシュする必要がありますが、他の画面は常に最新のデータを取得する必要があります。
実際のシナリオをテストするのではなく、仮定に基づいてテストするのを避けましょう。アプリを開き、デバイスを切断し、再起動し、まだ機能しているものを確認します。次に、デバイスを再接続し、サービスワーカーが古いUIにユーザーを閉じ込めないように更新されることを確認します。
Ionic PWAのホスティングはワークフローに基づいて選択します。
Ionic PWAの場合、静的ホスティングプラットフォームは通常十分です。チームが最もよく利用するのはNetlify、Vercel、Firebase Hostingです。
実用的なトレードオフの視点です。
| プラットフォーム | ベストフィット | 注意してください |
|---|---|---|
| Netlify | シンプルな静的デプロイとプレビュー | Redirect の動作は明示的な確認が必要です。 |
| Vercel | Gitベースのワークフローを使用しているフロントエンド重視のチーム | あるいは、ルーティング設定が調整が必要なアプリ |
| Firebase Hosting | Firebase サービスを使用しているチーム | プロジェクト構造が Firebase が多すぎると混雑する可能性があります。 |
どのホスティングサービスでも、リポジトリを接続する、ビルドコマンドを設定する、出力ディレクトリを設定する、環境変数を追加する、リライトルールを検証するという手順は、以下のようになります。
Ionic アプリがルーターを使用してナビゲートしている場合、ホスティング設定では、未一致のパスをアプリのエントリポイントに送信する必要があります。リライトが設定されていないと、ホームページが正常に動作し、深いリンクが失敗することがよくある PWA デプロイミスです。
CI/CD パイプラインを使用したビルドの自動化
リリース作業を手動で行うことは、最初は許容できます。ただし、2 回目以降はリスクとなります。誰かが Sync ステップを忘れる、誰かが汚れたブランチからビルドする、誰かが誤った構成で署名するなど、生成されたアーティファクトの信頼性が損なわれる可能性があります。
CI/CD は、これを解決することで、リリースシーケンスを code に変換します。メモリに頼るのではなく、毎回アプリがビルド、Sync、テスト、パッケージ化されるように定義します。
Ionic パイプラインの構成要素
Ionic プロジェクトの場合、有用なパイプラインは、次の順序でこれらの作業を実行します。
- 依存関係をロックファイルからインストールする。
- Web アプリケーションをビルドする。
- Capacitor プラットフォームを同期する。
- テストを実行するか、少なくとも基本的な検証を行う。
- ターゲット プラットフォーム向けのネイティブ アーティファクトを生成する。
- ビルド出力を保存または公開する。
この流れは、良いインフラストラクチャの習慣も重要です。ビルド ランナー、アーティファクト ストレージ、またはデプロイメント ステップが脆弱な場合、このガイド 小規模企業のためのエッセンスクラウド最適化ガイド は読む価値があります。同様のオペレーショナル ディシプリンは、モバイル デリバリー パイプラインにも適用されます。
A practical GitHub Actions shape
GitHub Actions is a good default because many Ionic teams already host code on GitHub. The workflow below shows the overall shape for an Android release build.
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アプリのモバイル向け実装パスについては、この setting up CI/CD for Capacitor apps に関する投稿は直接関連しています。
機密情報と署名の衛生
モバイルCI/CDの難しい部分は、YAMLを書くことではありません。機密情報を扱うことです。
リポジトリまたは組織の機密情報を使用してください:
- キーストアのパスワード
- キーアライアス
- エンコードされたキーストアファイル
- API のトークンをリリース時に使用
- 環境依存のビルド値
Android の一般的なパターンは、キーストアを base64 でエンコードし、エンコードされた文字列をシークレットに格納し、ワークフロー中に再構築し、Gradle に再構築されたファイルを指示することです。同様の原則は、署名材料全般に適用されます: ビルド時に挿入し、リポジトリに格納しないようにします。
CI/CD は人間のエラーを排除する必要がありますが、隠れた部族の知識を集中させないでください。リリースシークレットがどのように組み合わさるかを 1 人の開発者だけが理解している場合、パイプラインは依然として脆弱です。
実用的な推奨事項: 検証とリリースを分離すること。Pull Request はインストール、lint、テスト、Web ビルドを実行し、保護されたブランチまたは手動の承認ゲートが署名されたプロダクションアーティファクトをトリガーするようにしてください。そうすると、正常な開発のためにパイプラインが速くなり、実際の配布のために制御されるようになります。
Capgo のアップデートを即時送信
リリースストアは、ネイティブ code の変更、パーミッションの変更、アプリバイナリを変更するなど、ネイティブの変更が必要な場合にのみ必要です。テキストの修正、スタイリングの修正、JavaScript のバグがすべて Web 層に存在する場合には、良い手段ではありません。
なぜなら OTA のアップデート は、Ionic と Capacitor のプロジェクトで重要です。インストール済みのアプリに更新された Web アセットを送信できるため、ストアのレビューを待たずに、ネイティブシェルがすでにサポートしている範囲内で変更が発生した場合に限ります。
OTA のアップデートが取り扱うべきものは何ですか
OTA更新を使用して、以下のような変更を行う:
- JavaScriptのロジック修正 新しいネイティブプラグインのインストールが必要ない場合
- CSSの調整 レイアウトの問題やブランドの更新
- コピーの変更 文言、ラベル、法的テキストの変更
- 静的アセットの交換 アプリが既に読み込むことができる場合
実際のネイティブの変更を回避するために、OTAを乱用しないでください。新しいネイティブの依存関係を追加したり、権限を変更したり、ストアでレビューされたバイナリに含まれるものを変更したりすると、通常のストアリリースを実行してください。
その境界は重要です。OTAの主な目的は、速度と制御を提供することであり、プラットフォームの規則を無視することではありません。
最初のインシデントが発生する前にチャンネルを設定してください
最良のOTAワークフローは チャンネルを使用します。 製品チャンネルは、安定した更新をユーザーに提供します。 ステージングまたはベータチャンネルは、内部テスターが実際のインストール済みアプリケーションでテストできるように、更新を受け取ります。
そのパターンは、直感的に急いでいるため、直接全員にプッシュすることの最悪のOTAミスを避けるのに役立ちます。 急いでいる修正も、ガードレールが必要です。
通常のセットアップは、プラットフォームのドキュメントに従ってプラグインのインストールとアプリの初期化から始まり、環境ごとにチャンネルの割り当てに続きます。 次の記事 アプリストア安全なOTA更新 は、正しく境界を設定するための基準点として、設定のための良い参考点です。
Push small fixes without touching native code
を触る必要はありません。
アップデータが統合された後、実用的ワークフローは簡単になります。 更新されたWebアセットをビルドし、目的のチャンネルに公開し、更新ポリシーに従ってアプリが起動したときに取得して適用します。
- 実際の例は、モバイルレイアウトのリグレッションのためのホットフィックスです:
- IonicアプリのCSSを調整します。
- ステージングチャンネルに生成されたバンドルを公開する。
- インストール済みのビルドでテストする。
- 同じ修正をプロダクションに公開またはプロモートする。
そのアプローチは、OTAのない場合と比較して、インシデント対応を変える。悪いウェブ層のバグがストアのレビューとユーザーの新しいバイナリの採用を待つことになる。 OTAの場合、影響を受けたファイルを修正し、正しいユーザーに配信し、制御された方法でロールアウトを観察できる。
高速な更新は、安全にターゲットを設定し、必要に応じてロールバックできる場合にのみ有用である。
OTAの利益を受けるチームは、無神経なチームではなく、明確なリリース境界、名前付けされたチャンネル、ウェブ層の修正をネイティブリリースから別のストリームとして扱う習慣を持つ、規律のあるチームである。
一般的な展開問題とベストプラクティス
ほとんどの展開問題は、ユニークではない。チーム間で繰り返されるのは、締切のプレッシャー下で同じ間違いが繰り返されるからである。
繰り返し出現するエラー
Androidの署名エラーは、通常、間違ったパスワード、間違ったエイリアス、または間違ったキーストアファイルがリリース構成で使用されていることによる。そうなる場合は、無理に資格情報を回すのではなく、ファイル、エイリアス、シークレット値を最初に検証すること。
iOSのビルドエラーは、通常、バンドル識別子、チームの選択、証明書、プロビジョニングプロファイルの間の不一致による。Xcodeのエラーメッセージは密集しているかもしれないが、不一致は通常、Literalである。1 つの値は他の値と一致していない。
インストール後に白い画面が表示されるのは、古典的な問題の1つである。原因は次のとおりである。
- 運用環境が開発サーバーに指し示されているアプリ 代わりにバンドルされたアセット
- Web アセットが再構築されていない 前
npx cap sync - HTML のテキスト フラグメント 新機能に取り組む前に議論してください
- 新機能に取り組む前に議論してください プラグインの変更が同期されていない
ネイティブ プロジェクトに
実行環境の値が欠落している
実際のリリース ビルドに
リリースの習慣が再作業を防ぐものであることはよく知られていますが、実際にはそれがどのように機能するかはよく知られていません。
あなたのチームが Capacitor アプリをリリースし、リリース後ウェブ層の修正を安全に提供したい場合は Capgo Capgo にプルリクエストを提出する
