アプリが完成しました。ブラウザで動作し、UIが正しく、コアフローの安定性が確保されています。すると、デプロイが現れ、直線的なIonicプロジェクトを3つの異なるリリーストラックに変え、各トラックには独自のツール、署名ルール、レビュープロセス、更新戦略が含まれます。
その時点で、多くの場合、時間が失われます。機能を書くことではなく、ネイティブビルド、Webホスティング、リリースの自動化、ポストローンチ修正を組み合わせるプロセスを繰り返すことができるようにするプロセスを組み立てることです。 Ionic アプリのデプロイ iOS、Android、PWA の配信を別々のプロジェクトとして扱うのではなく、1 つのリリースシステムとして扱うことで、最も効果的な結果が得られます。
目次
- あなたの Ionic アプリは完成しました。次は何をしますか?
- プロダクション用にプロジェクトを準備する
- iOS と Android 用のネイティブ デプロイ
- PWAとしてIonicアプリを展開する
- CI/CD Pipelinesを使用したビルドの自動化
- Capgoを使用した即時更新の配信
- 一般的なデプロイ問題とベストプラクティス
あなたのIonicアプリは完成しました。次は何をしますか。
ほとんどの開発者は同じポイントに到達します。 ionic serve 見た目は良く、ローカルAPI呼び出しは正常に動作し、アプリは完了したように感じます。実際にはまだ完了していません。ブラウザでのみテストされており、署名されていません。また、App Storeのレビュー、Playの署名、生産的なWebホスティングの制約から切り離されています。
プロダクションデプロイは質問の内容を変えます。アプリがレンダリングされるかどうかを尋ねるのではなく、 バンドルが再現可能かどうかネイティブプロジェクトが同期されているかどうか
環境変数がきれいに分離されているかどうか
リリース後に非ネイティブのバグを修正することができるかどうか
- ストアの再提出スキャンダルを引き起こさないようにすることができます。 Capacitor の設定、アプリ識別子、アイコン、環境値、そしてプロダクション ビルドが一貫しているようにする。
- Android と iOS 用のネイティブ リリース アーティファクトを作成する Ionic コマンドだけではなく、プラットフォーム ツールを使用して Android と iOS 用のネイティブ リリース アーティファクトを作成する
- PWA ビルドを配信する ブラウザに即座にアクセスできるユーザー向けの PWA ビルドを配信する
- 日常業務を自動化する ビルドが 1 人の開発者がチェックリストを思い出す必要がないようにする
- リリース後の更新計画を立てる ウェブ アセットの修正がアプリ ストアのレビューに待たされる必要がないようにする
現在のアプリが「スマートフォンシェル内で起動するウェブアプリ」に感じる場合は、その問題を解決することから始めましょう。 ウェブアプリをモバイル アプリに変えるための参考となるガイドは、この Capacitor のガイドです。.
最初の成功的なストアの提出は、賢さではなく、 discipline から生まれるものです。
プロダクション用にプロジェクトを準備する
ビルドを生成する前に、プロジェクトをリリース候補として扱ってください。多くの場合、ローカル開発で無害だった小さな不一致が、プロダクションで高価な問題となっています。
環境チェックから始めましょう
基本的なものから始めましょう:
ionic doctor
npm ci
npx cap doctorionic doctor 一般的なCLIと環境問題をキャッチします。 npm ci リリース用の作業では、より良い選択です。ロックファイルから正確にコミットされたものと同じようにインストールします。 npm install プラグインとプラットフォームの不一致を表面化させるのに役立ちます。XcodeまたはAndroid Studioがそれらを読みにくいエラーに変える前に。 npx cap doctor 可能な限り、リリースビルドからクリーンな状態で使用してください。アプリがローカルパッチ、削除されたフォルダ、または手動で編集されたネイティブファイルの存在でしかビルドされない場合、デプロイメントプロセスはまだ安定していません。
毎回行う価値があるチェックがいくつかあります:
アプリIDを確認する
- Preparing Your Project for Production. 変更
appId遅延すると、ストアと署名の混乱を招く可能性があります。 - プラグインの状態を確認. ネイティブ プラグインの変更は通常、最新の Sync が必要であり、場合によってはプラットフォームの再起動も必要です。
- 環境のインジェクションを確認. API エンドポイント、キー、機能フラグは、環境固有の構成からではなく、インライン定数から取得するべきです。
リリースターゲット間で異なるべきである __CAPGO_KEEP_0__ アプリの開発とプロダクションの違いについてのこの記事 development vs production differences in Capacitor apps __CAPGO_KEEP_0__ の構成をロック
Lock down Capacitor config
と、プロダクションインフラストラクチャのようにプロダクション環境でレビューしてください。 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 | ネイティブストアや署名用のパッケージ識別子 | スターターから置き換えられていないプレースホルダー |
| appName | ネイティブシェルでのユーザーフェイス用アプリ名 | 開発用ラベルを使用し、変更を忘れる |
| webDir | ディレクトリ Capacitor はネイティブ プロジェクトにコピーされます。 | Capacitor の期待どおりの出力フォルダとは異なる出力フォルダにビルドします。 |
開発中のローカル開発サーバーを使用する場合は、プロダクション設定がネイティブ ビルドにローカル開発サーバーを指すようにしないようにします。 その単一のミスは、開発時は機能するがリリース時は白い画面が表示されるという多くの「開発時は機能するがリリース時は白い画面が表示される」インシデントを引き起こします。
実用的ルール: リリース ビルドがライブのローカル サーバー設定に依存している場合、それはリリース ビルドではありません。
アセットを 1 回生成する
アイコンとスプラッシュ画面を手動でサイズ変更しないでください。 1 つの高品質のソース アセットを使用し、そこからプラットフォームの出力を生成してください。
現在の Capacitor ワークフローでは、多くのチームは CLI エコシステムを通じて公式のアセット ツールを使用しています。 exact パッケージはスタック バージョンによって異なりますが、規範は同じです: 1 つのカノニカル アイコンと 1 つのカノニカル スプラッシュ ソースをバージョン管理下に保ち、出力を生成し、Xcode と Android Studio 内で結果をレビューすることです。 これは、PWA アイコンが最新の状態であるのに対し、Android は古い前景アセットを使用し、iOS は古い起動画像を表示しているというよく知られた失敗モードを回避するためです。
堅固なプロダクション パスには次のことが含まれます。
プロダクション モードで Web アセットをビルドします。
- ネイティブ プロジェクトを Sync します。
- __CAPGO_KEEP_0__ はネイティブ プロジェクトのディレクトリです。
- Open each native IDE and inspect app name, icons, permissions, and signing settings manually.
- Test on a physical device before you package anything for stores.
iOSとAndroid向けのネイティブデプロイ
ネイティブデプロイは、Ionicアプリが「ただのウェブ」からプラットフォームの規則に応えるようになる場所です。ウェブバンドルは共有できますが、署名、パッケージング、ストアの要件がプロセスに入ると、AndroidとiOSはすぐに分岐します。
ウェブ層を最初にビルドする
常に、ネイティブパッケージングに触れる前に、最新のウェブアセットを生成する
ionic build
npx cap syncいくつかのチームは ionic build --prod 古い慣習のためです。現代のプロジェクトでは、フレームワークツールによって生産の実行時挙動は正確に決まりますが、原則は変わりません: 最適化されたリリースビルドを生成し、次にネイティブプラットフォームにSyncします。
Sync後、ネイティブプロジェクトを開く:
npx cap open android
npx cap open iosこの時点で、Androidの__CAPGO_KEEP_0__アプリの設定を確認することもおすすめです。 この時点で、Capacitorアプリの設定を確認することもおすすめです。 If your project still has shaky native configuration.
Androidのリリースフロー
Androidのリリースパスは通常iOSよりも予測可能ですが、署名設定が簡素に設定されると破綻します。
1回のアップロードキーストアを生成し、安全に保存してください:
keytool -genkeypair -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias uploadキーストアファイル、エイリアス、パスワードを安全なシークレットストアに保存してください。コミットしないでください。チームチャットに残してはいけません。誰かが保存したと仮定してはいけません。
次に、Gradleに署名を接続してください。チームは、この設定を build.gradle ファイルまたはAndroid Studioの署名UIに依存するか、どれだけのプロセスをスクリプト化したいかによって決まります。一般的なセットアップには signingConfigs ブロックとリリースビルドタイプが含まれます。リリースアーティファクトは通常Play Storeへの提出用に使用されるのは
AAB です。デバッグAPKではありません。Android Studioでは、メニューのパスを使用して署名されたバンドルを生成し、リリースバリアントを選択し、アプリバンドルをエクスポートしてください。コマンドラインビルドを好みますか?Gradleは署名が設定された場合にそれを処理できます。Androidの一般的な落とし穴は、熟知した形で現れます:
__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の汎用デバイスのターゲットを選択し、次に アーカイブアーカイブが完了したら、オーガナイザー ウィンドウを使用して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のサービスワーカーはオフラインサポートとキャッシュの通常のパスです。強力ですが、誤って設定するのも簡単です。
データが古くなっていてもユーザーがストックされるようにキャッシュするのは過度に積極的で、キャッシュするのは少しでも少なすぎると、接続が不安定になってもアプリが頑丈に感じられないようにするには、キャッシュする量が適切な設定が必要です。
アプリの種類によっては、キャッシュするべき画面もあるし、常に最新のデータを取得するべき画面もある。
オフラインサポートを製品の決定として考えるのではなく、チェックボックスとして考えるのではなく、実際のシナリオをテストするのではなく、Lighthouseスタイルの仮定だけに頼るのではなく、実際にアプリを開いて、デバイスを切断し、再起動し、まだ機能しているものを調べ、再接続し、サービスワーカーが古いUIにユーザーを閉じ込めないように更新することを確認する。
ホスティングはワークフローに基づいて選択する
IonicのPWAの場合、静的ホスティングプラットフォームは通常十分です。チームが最もよく利用するのはNetlify、Vercel、Firebase Hostingです。
実際的なトレードオフの視点です。
| プラットフォーム | 適切な選択 | 注意する点 |
|---|---|---|
| Netlify | シンプルな静的デプロイとプレビュー | リダイレクトの動作は明示的なレビューが必要です。 |
| Vercel | Gitベースのワークフローを使用しているフロントエンド重視のチーム | あるいは、特定のアプリケーションルーティングの設定が調整が必要 |
| Firebase Hosting | Firebaseサービスを既に使用しているチーム | プロジェクト構造が複雑になる可能性がある |
どのホスティングサービスでも、リポジトリを接続し、ビルドコマンドを設定し、出力ディレクトリを設定し、環境変数を追加し、クライアントサイドルーティングがリフレッシュ時に機能しないようにリライトルールを検証するという手順は、以下のようになります。
ルーターを使用するIonicアプリの場合、ホスティング設定では、未一致のパスをアプリのエントリポイントに戻す必要があります。リライトが設定されていない場合、ホームページは正常に動作し、ディープリンクは失敗します。そのようなPWAのデプロイミスは最も一般的なものです。
CI/CDパイプラインを使用したビルドの自動化
リリース作業を手動で行うことは、一度は許容できますが、その後はリスクとなります。誰かがSyncステップを忘れる、誰かが汚れたブランチからビルドする、誰かが誤った構成で署名するなど、突然生成されたアーティファクトが信頼できなくなることがあります。
CI/CDはそのリスクを解決することで、リリースシーケンスをcodeに変換します。記憶に頼るのではなく、毎回アプリがどのようにビルド、Sync、テスト、パッケージ化されるかを明確に定義します。
パイプラインに含めるものは?
Ionicプロジェクトの場合、便利なパイプラインは、次の順序でこれらのタスクを実行します。
- ロックファイルから依存関係をインストールする。
- ウェブアプリケーションをビルドする。
- Capacitorプラットフォームを同期する。
- テストを実行するか、少なくとも基本的な検証を行う。
- ターゲットプラットフォーム向けのネイティブアーティファクトを生成する。
- ビルド出力を格納または公開する。
その流れは、良いインフラストラクチャの習慣も重要です。ビルドランナー、アーティファクトストレージ、またはデプロイメントステップが脆弱な場合、このガイド 小規模企業向けのエッセンシャルクラウド最適化 は読む価値があります。同様の運用の規律はモバイル配信パイプラインにも適用されます。
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 を書くことではありません。将来のインシデントを起こさないようにシークレットを扱うことです。
Repository または Organization のシークレットを使用してください:
キーストアのパスワード
キー アリセス
- エンコードされたキーストア ファイル
- Keystoreのパスワード
- Keyアリセスの値
- API のリリースに使用されるトークン
- 環境依存のビルド値
Android の一般的なパターンは、キーストアを base64 でエンコードし、エンコードされた文字列をシークレットに格納し、ワークフロー中に再構築し、Gradle に再構築されたファイルを指示することです。同様の原理は、署名材料に適用されます: ビルド時に挿入し、リポジトリに格納しないようにします。
CI/CD は人間のエラーを排除するのではなく、隠された部族の知識を集中させるべきではありません。開発者が 1 人だけがリリースシークレットの組み合わせを理解している場合、pipeline は依然として脆弱です。
実践的な推奨事項: バリデーションをリリースから分離する。Pull Request はインストール、lint、テスト、Web ビルドを実行し、保護されたブランチまたは手動の承認ゲートが署名されたプロダクションアーティファクトをトリガーする。そうすると、正常な開発のためにパイプラインを速くし、実際の配布のために制御することができます。
Capgo を使用して即時配信
リリースストアはネイティブ code の変更、許可の変更、またはアプリバイナリを変更するすべてのものが必要です。テキストの修正、スタイリングの修正、または JavaScript のバグが完全に Web 層に存在する場合、すべてのテキスト修正、スタイリングの修正、または JavaScript のバグには適していません。
なぜなら OTA の更新 Ionic と Capacitor のプロジェクトでは、OTA の更新は重要です。インストール済みのアプリに更新された Web アセットを送信することができます。ストアのレビューを待たずに、ネイティブシェルがすでにサポートしている範囲内に変更が含まれる限り、
OTA の更新は何を処理するべきですか
OTAの更新を使用して、以下の変更を行います。
- __CAPGO_KEEP_0__ プラットフォームのルールを無視せずにスピードと制御を実現するために、OTAの境界は重要です。
- JavaScriptのロジック修正 新しいネイティブプラグインが必要ない修正
- レイアウトの修正 ブランドの更新
- コピーの変更 ラベルや法的テキストなどの文言の変更
静的アセットの交換
アプリが既にロードする方法を知っている場合
正常なストアリリースを出さないでください。新しいネイティブ依存関係を追加したり、権限を変更したり、ストアでレビューされたバイナリに含まれるものを変更したりすると、正常なストアリリースを出してください。
最良のOTAワークフローでは チャンネル. 製品チャンネルは、安定した更新をユーザーに提供します。 ステージングまたはベータチャンネルは、内部テスターが実際のインストール済みアプリケーションで検証できる更新を受け取ります。
そのパターンは、緊急修正が急いでいるように感じても、直接全員にプッシュしないようにするのに役立ちます。 緊急修正も、ガードレールが必要です。
一般的なセットアップは、プラットフォームのドキュメントに従ってプラグインのインストールとアプリの初期化から始まり、環境ごとにチャンネルの割り当てに続きます。 " アプリストア安全なOTA更新 」は、境界を正しく設定するための参照点として、設定のための良いポイントです。
code
小さな修正をプッシュするには、ネイティブ
OTAワークフローは、アップデーターが統合された後、実用的になります。 ビルドされたWebアセットを更新し、目的のチャンネルに公開し、更新ポリシーに従ってアプリが起動したときに取得して適用するだけです。
- 実際の例は、モバイルレイアウトの不具合のホットフィックスです。
- イオニックアプリのCSSを調整します。
- ステージングチャネルに結果のバンドルを公開する。
- インストール済みのビルドでテストする。
- 同じ修正をプロダクションにプロモーションまたは公開する。
そのアプローチは、インシデント対応を変える。OTAがなければ、悪いウェブ層のバグは、ストアレビューとユーザーの新しいバイナリの採用を待つことになる。 OTAでは、影響を受けたファイルを修正し、正しいユーザーに送信し、制御された方法でロールアウトを観察できる。
迅速な更新は、安全にターゲットを設定し、必要に応じてロールバックできる場合にのみ有用である。
OTAの利益を受けるチームは、無神経なチームではない。明確なリリース境界、名前の付いたチャネル、ウェブ層の修正をネイティブのリリースとは別のストリームとして扱う習慣がある、規則正しいチームである。
一般的なデプロイ問題とベストプラクティス
ほとんどのデプロイ問題は、ユニークではない。チーム間で繰り返されるのは、締切のプレッシャー下で同じミスが繰り返されているからである。
繰り返し現れる失敗
Androidの署名エラーは、通常、間違ったパスワード、間違ったエイリアス、または間違ったキーストアーファイルがリリース構成で使用されていることによる。そうなる場合は、無理に資格情報を回すのではなく、ファイル、エイリアス、シークレット値を最初に検証する。
iOSのビルドエラーは、通常、バンドル識別子、チームの選択、証明書、プロビジョニングプロファイルの間の不一致による。Xcodeのエラーメッセージは密集しているが、不一致は通常、Literalである。1 つの値が他の値と一致していない。
インストール後に白い画面が表示されることは、もう１つのクラシックだ。一般的な原因には、次のものが含まれる。
- 開発サーバーに指向している実稼働アプリ バンドルされたアセットの代わりに
- Webアセットが再構築されない 前
npx cap sync - プラグインの変更が同期されない ネイティブプロジェクトに
- 実行時環境の値が欠落している 実際のリリースビルド
リリースの習慣が再作業を防ぐ
ベストプラクティスは面白くないが、それが機能するのはそのためである。
環境設定の真実の１つを保つ。クリーンなブランチからビルドする。リリースコミットをタグする。リポジトリ外の署名材料を保管する。実機でインストールしたビルドをテストする。シミュレータやブラウザタブのみでテストしない。ストアメタデータを早期に準備する。デプロイがスクリンショット、プライバシーの回答、または欠落しているコピーに遅れるのを防ぐ。
１つの習慣が多くの痛みを救う：自動化が実装された後も、書き留めたリリースチェックリストを保つ。Pipelineはアーティファクトをビルドする。アプリの説明が最新か、サポートURLが正しいか、または最新のネイティブパーミッション文字列がアプリの動作と一致しているかを確認するのではない。
あなたのチームが Capacitor アプリをリリースし、リリース後ウェブ層の修正を安全に提供したい場合 Capgo は評価する価値がある。チャンネル、制御されたロールアウト、ロールバック機能を備えた構造化されたOTAワークフローを提供するため、JavaScript、CSS、コピー、資産の更新を実行できます。小さな修正をすべてのアプリストアの提出に変えるのではなく。
