プロジェクトを開いてみると、 build:ios:dev, build:android:qa, build:staging, build:release, build:prod、いくつかのシェルスクリプトが見つかります。誰も触りたくないと思います。すると誰かが言うのです、「クライアント用のステージングビルドを今日までに作ってください」です。中級のモバイル開発者であれば、この要求はよくわかりません。どの設定を使用するか?どの署名識別子を使用するか?どのバックエンドを使用するか?どの配布パスを使用するか?
That confusion usually comes from treating build types as a flat list. They aren’t. They’re a workflow. Each build exists to solve a specific problem at a specific point between your laptop and a user’s device.
A build is not just a compiled app. It’s a version of your app assembled for a purpose, an audience, and an environment. Some builds exist to help you debug. Some exist to help QA break things safely. Some exist so release engineering can produce a trustworthy artifact. Some exist so product teams can ship changes with less risk.
If your local setup still feels shaky before any of that starts, get that under control first with a proper Capacitor local environment setup
. Build complexity becomes much easier to reason about when your base tooling is predictable.
- Table of Contents
- Software Buildsの複雑さを解消する
- ローカルビルド vs CIビルド
- ビルドを配布環境にマッピングする
- The Critical Role of Code Signing
- CI/CDとアップデートチャンネルを利用したリリースのオーケストレーション
- モダンビルドワークフローのためのベストプラクティス
ソフトウェアビルドの世界を整理する
最もよく見る間違いは、ビルド名が全ての物語を伝えることを想定していることです。そうではありません。 staging __CAPGO_KEEP_0__は、リリースのフラバーがステージングのAPIを指す場合、あるリポジトリではデバッグ可能なQAアーティファクトにモックされた決済を指す場合、あるリポジトリでは、プライベートに配布されるプロダクション署名のビルドを指す場合など、異なるリポジトリで異なる意味を表す可能性があります。
そのため、チームはラベルだけでは混乱することになります。ラベルは、ビルドが何を実行しているかを理解している場合にのみ有用です。
ビルドの種類について考える有効な方法は次のとおりです:
- ローカルビルド 個々の開発者が迅速に動くのに役立ちます。
- CIビルド チームの共有ソースとなるものを生成します。
- デバッグとリリースのフラビア __CAPGO_KEEP_0__はアプリがコンパイルおよびインストルメントされる方法を定義します。
- 配布用ビルド __CAPGO_KEEP_0__はアプリを受け取る人と方法を定義します。
- 署名済みビルド __CAPGO_KEEP_0__はプラットフォームがアーティファクトを信頼するかどうかを決定します。
- チャネルベースの更新 __CAPGO_KEEP_0__はインストール後に変更がどのように動作するかを決定します。
これらは競合するカテゴリではありません。層が重なります。
「ステージングビルド」はほとんどの場合、単一のものではありません。通常は、フラビア、環境、署名、配布の選択肢の組み合わせです。
そのため、2つのチームが「ベータビルドが必要」と言っても、まったく異なるアーティファクトを意味することがあります。
これは、モバイルで最も重要です。各ステップが摩擦を増やすからです。ネイティブコンパイル、シークレット、プロビジョニング、アプリストアのトラッキング、テスターへのアクセス、環境設定、ロールバックなど、すべてが一致する必要があります。1つの部分が不整合になると、リリースプロセスはtribal knowledgeになります。すると、1人のエンジニアが休暇を取ってしまって、誰もきれいにリリースできないようになります。
このチームは、スクリプトを覚えるのではなく、ビルドタイプを品質ゲートとして定義します。各ゲートは、異なる種類のリスクを下げます: code が破損した場合、設定が間違っている場合、署名が不正な場合、ロールアウトが不正な場合、または復旧が不正な場合。
ビルド スペクトラム - ローカル vs CI ビルド
ローカル ビルドとCI ビルドの違い
ローカル ビルドは自分用に作成したものです。CI ビルドはチームが信頼できるものです。
ローカル ビルド
ローカル ビルドはプライベート、高速、廃棄可能です。即時の質問に答えるために使用します。
画面がレンダリングできるか?ネイティブ プラグインが初期化できるか?GradleまたはXcodeの変更がコンパイルを破壊したか?ログを増やして再現できるか?
良いローカル ビルドはスピードを優先します。チェックが緩い、ログが詳細、開発者が設定できるスイッチ、そして一時的なインストルメンテーションを含みます。それは問題ありません。迅速なフィードバックが必要です。
しかし、ローカル ビルドを重要なものに昇格することは機能しません。ローカル ビルドは、コンパイルが成功した一台のノートパソコンでしか動作しないので、リリースアーティファクトにはなり得ません。
CI ビルド
CI ビルドは、より速い理由がある。 それらは、個人のマシン状態を方程式から除去し、ビルドプロセスを繰り返し実行する。
CI が健全な場合、3 つのことをよく行う。
- ゼロからビルドする: プロジェクトが非公開のローカル仮定なしでコンパイルできることを証明する。
- チームレベルのチェックを実行する: ユニットテスト、linting、パッケージングルールは、毎回同じ場所で実行される。
- トレース可能なアーティファクトを生成する: チームは、ビルドをコミット、ブランチ、パイプライン実行とつなげることができる。
そのため、ワークショップ対ファクトリーのアナロジーが好きだ。 你的ラップトップは、イテレーションを行うベンチです。 CI は、プロセスが実際に機能していることを証明する組み立てラインです。
あなたのチームがまだ、スクリプトがどこで実行されるかを手動で決定している場合、自動化でそのロジックを統合する。 実用的な参考は、この __CAPGO_KEEP_0__ Actions を使用した開発とプロダクションビルドの管理に関するガイドです。 managing dev and prod builds with GitHub Actions.
__CAPGO_KEEP_0__ If QA, product, or support needs the artifact, it should come from CI, not from a developer’s machine.
CIからアーティファクトを取得するのは、開発者のマシンではなく、QA、製品、またはサポートが必要な場合です。
Once you accept that, the rest of the build lifecycle gets easier.
それを認識することで、ビルドライフサイクルの残りの部分が簡単になります。 Flavor selection, signing, environment injection, and distribution all belong in a pipeline that anyone on the team can inspect. チームの誰でも検査できるPipelineに、Flavorの選択、署名、環境のインジェクション、配布が含まれます。 Core Build Flavors Debug vs Release.
ビルドの基本的なフラビアは、DebugとReleaseです。
ビルド用のラベルは多数ありますが、そのラベルの下で、2つのフラビアが最も重要です。
debug
デバッグ用フラビアです。 指示的, 性能, 独占的、および 参照基準 型、およびデバッグ ビルドは、適切なツールと方法を指示するため、指示的アプローチに適しています。 一方、リリース ビルドは、構築仕様の分解で説明されているように、必要な結果に焦点を当てた性能に重点を置くアプローチに適しています。 実際には、デバッグ ビルドは、以下のようなものが必要です: 指示的 性能 独占の 、および.
参照基準
- 読みやすい診断結果: エラートリース、コンソール出力、シンボルがエラーの原因を探すのに役立つものです。
- 開発者用の機能: モックの切り替え、テストメニュー、機能切り替えがエンドユーザーにとって不適切なものです。
- 低抵抗力の反復: 迅速なインストールと実行サイクルは、綺麗なパッケージよりも重要です。
デバッグビルドは「悪い」ものではありません。目的を立てたものです。
リリースビルド
リリースビルドは、実際に使用されているデバイス用に作成されます。そのことは直ちに優先順位を変えます。
今度はパッケージの完全性、起動動作、セキュリティポジションの厳しさ、小さいパケットサイズ、予測可能な実行特性などに気を配ります。また、検査または不正使用のための不必要なエントリポイントも減らしたいと思います。
トレードオフは単純です。デバッグビルドを簡単に検査できるものは、リリースビルドが生産環境に適さない傾向があります。
チームと一緒に使用する決断境界はこちらです:
| フレーバー | 最適な用途 | 何を最適化するか |
|---|---|---|
| デバッグ | 開発、ローカルテスト、問題の再現 | 可視性と反復速度 |
| リリース | ベータ配布、ストアの提出、生産のロールアウト | 安定性、パフォーマンス、信頼性 |
なぜチームがこれを間違うのか
混乱の最大の原因は、「環境」と「フレーバー」を混同することです。
ビルドは リリース用のフラビアがステージング用サービスの指向. それは、QAの一般的なことです。非生産的なデータで生産的な動作を実現したいからです。ビルドはまた デバッグ用のフラビアが開発用サービスの指向 日常の開発のためにデバッグ用フラビアを使用してください。 それは異なる軸です。
スクリプトのスプレッドがチームがパッケージ名にすべての可能な組み合わせをエンコードするのではなく、ドキュメントでマトリックスを記述するのを避けることから始まることが多い。
非開発者がユーザーフェイスの動作をテストするときは、リリース用フラビアを配信してください。エンジニアリングの作業や意図的なトラブルシューティングのためにデバッグ用フラビアを使用してください。
その1つのルールが、多くの偶発的な複雑さを排除する。
ビルドを配布環境にマッピングする
ビルドのタイプについての議論は、よく早く止まる。ローカル、デバッグ、リリースについて説明し、より難しい質問を無視する。
その目的地は、ビルドが何を含むべきか、署名する方法、そして誰が受け取るべきかを決める。
実用的ビルドワークフローは、リスクに対する耐性が異なる各環境を通過する。 Capacitor アプリケーションを開発している場合、開発と生産アプリケーションの動作を Capacitor で清潔に分離することも役に立つ 開発と生産アプリケーションの動作を Capacitor で清潔に分離するtargetLanguage":"Japanese","protectedTokens":["Cloudflare","Capacitor","GitHub","Capgo","code","API","SDK","CLI","npm","bun"],"texts":["環境マッピングミスが多くあるため、"ビルドエラー"は実際には問題ではありません。",
Nightlyとcanary
"Nightlyとcanaryは、エンジニア、QA、または内部グループの小さなグループが粗いエッジを許容することを願う場合にのみ使用します。",
Nightlyは通常、定期的なスケジュールまたは最新のメインブランチの状態から生成されます。Canaryは、より広範なロールアウト前に狭いアウディエンスに意図的に公開されます。
Nightlyとcanaryは、学習ツールとして扱いますが、安定性の約束ではありません。",
- 質問に答える必要がある場合に便利です。
- ブランチがモジュール間で綺麗に統合されるかどうか?
- 特定のデバイスファミリーのネイティブ依存性のアップグレードが、特定のデバイスファミリーを破壊したかどうか?
内部テスターが、より広範なベータ公開前にレグレッションを発見できるかどうか?
何が機能しないのは、canaryビルドを、ポリッシュされたソフトウェアを期待する人に与えることです。
ノイズフィードバックが得られ、正常なチョーンをリリース問題として呼ぶのは間違った人たちです。",
Stagingとbeta","製品の品質が、エンジニアリングの便利さよりも重要になる時期です。",
The audience shifts here:
- QAはバグの再発生、ワークフロー、受け入れ基準を検証します。
- 製品マネージャーは、実際のシェルで動作を確認します。
- 外部テスターは、ユーザビリティ、デバイスカバー、エッジケースを検証します。
- サポートまたは成功チームは、近日公開予定の変更をプレビューします。
誤りは、ベータ版を「デバッグ用の別のビルド」とみなすことです。テスターが実際のユーザーフローを評価している場合、リリースに似た条件が必要です。
プライベート配布ビルド
あるアプリは、全員に公開されることなく、またはより狭いグループに先に到達する必要がある場合があります。
これには、クライアント固有のビルド、内部従業員アプリ、規制ワークフロー、フィールドオペレーションツール、企業専用の配布が含まれます。これらは、誰がアプリをインストールできるか、どのバックエンドにアクセスできるかを厳密に制御する必要があります。
ここでも、名前が危険です。チームは「企業ビルド」と言っている場合、実際には何らかの異なることを意味しています。
- a: 私有署名の内部アプリ
- b: ストアで配布されたアプリに内部のみのアクセス制御
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
異なる運用モデルが存在します。パイプラインと名前付けにおいて、それらを分離してください。
本番
本番ビルドは、ユーザーに配布される公約です。App Store、Play Store、またはユーザーに配布される同等の承認済みチャネルに送信されます。
この時点でビルドは面白くないはずです。それは褒め言葉です。
本番ビルドは、再現性がある、正しく署名された、リリース条件でテストされた、ロールバック計画に結びついたものになります。最後の手段の手動編集、機械依存のハック、または「次のビルドで修正する」という妥協は望みません。
ここに要点を簡単にまとめました。
ソフトウェアビルドの種類とその特徴
| ビルドの種類 | 対象 | 構成 | 配布方法 |
|---|---|---|---|
| ローカル開発者 | 個人開発者 | 通常デバッグ、高速反復、ローカル環境設定 | ローカルマシンから直接インストール |
| CI検証 | エンジニアリングチーム | 繰り返し自動ビルド、共有チェック | CIアーティファクトストレージ |
| 毎晩またはキャニバリ | 内部テスター、選択されたチームメンバー | 早期統合状態、限定的なロールアウト | 内部配布ツール |
| ステージングまたはベータ | QA、製品、外部テスター | 通常リリースのような非公開環境マッピング | TestFlight、プレイテストトラック、プライベートリンク |
| アドホックまたはエンタープライズ | 内部従業員、クライアント、制限グループ | 制御された構成、目的地固有の署名 | プライベート配布チャネル |
| 本番 | 一般ユーザー | 最終リリース構成、ストア用の署名 | App Store または Google Play |
リスク耐性のマッチングが欠けているチームは、リリースミスを起こすことが多い。
Codeの重要な役割
モバイルでは、ビルドファイル単体では何も意味しない。プラットフォームは、信頼できるソースから来て、作成後誰も変更していないことを証明する必要がある。 code署名.
ビルドがコンパイルできたのに、インストール、アップロード、起動ができなかったことがあることはありませんか。その場合は署名が原因だった可能性があります。
署名が実際に証明すること
モバイルチームにとって、code署名は3つの役割を果たす。
- 正当性: アプリを開発した開発者または組織とアプリを紐付けする。
- 完全性: 署名が行われた後、改ざんされていないことを証明するのに役立ちます。
- Authorization: Appleプラットフォームでは特に、実行される場所や方法を制御することもあります。
多くの開発者が混乱するのは、3番目の点です。署名は単にアイデンティティだけではありません。許可も含まれます。
同じアプリcodeは、ローカルで実行したい場合、テスターに配布したい場合、内部に配布したい場合、またはストアに提出したい場合に、異なる署名資材を必要とする可能性があります。
目的地によって署名がどのように変化するか
この考え方がプロセスを常に管理するには、次のようになります: 署名は配布に従います。.
ローカル開発者インストールでは、1つのアイデンティティと許可セットが使用されます。テストフライトを通じて送信されたベータビルドでは別のものが使用されます。内部配布パスでは別のプロファイルが必要になることもあります。パブリックストアのリリースには独自の署名の期待値とレビュー互換のパッケージングが必要です。
したがって、「ビルドを再署名するだけ」はほとんどの場合、小さな要求ではありません。署名が変化すると、許可された目的地も変化する可能性があります。
規則正しく設定されている場合には、通常、次のことが含まれます:
- CIで署名資産を保存する 個人的ノートブックではないPCにインストールしないでください。
- ターゲットごとに明確な区別: 開発、プライベートテスト、企業、ストアリリース
- 特に、契約者や複数の製品チームがインフラを共有する場合に、ローテーションとアクセス制御: アクセス制御とローテーションは、特に契約者や複数の製品チームがインフラを共有する場合に重要です。
- 監査可能性: チームが __CAPGO_KEEP_0__ アプリ内でウェブ更新を配信する場合、2 つの署名層を考慮する必要があります。
Capacitor アップデーター __CAPGO_KEEP_1__ 署名のエンドツーエンドセキュリティの概要 end-to-end security for Capacitor updater code signing 署名材料を生産インフラと同じように扱うようにしてください。なぜなら、それは実際にそれですから。
署名問題は、暗号化からではなく、不明な所有権、手動の処理、ビルドパイプラインが適用されたアイデンティティを隠すことから生じることが多い。
署名材料を生産インフラと同じように扱うようにしてください。なぜなら、それは実際にそれですから。
CI/CDとアップデートチャンネルを使用したリリースのオーケストレーション
チームが成熟した段階で、ビルドの種類を知ることの課題はありません。人間の推測なしで、それらを調整することです。
その調整はCI/CDに属するものです。
パイプラインはビルド契約です。
信頼できるパイプラインは、毎回同じ質問に答える必要があります。
- このビルドは何のために行われるか
- どのフラビアを使用するか
- どの環境値を受け取るか
- どのテストを通過する必要があるか
- どの署名のIDが適用されるか
- アーティファクトはどこに配信されるか
その構造は、良い技術仕様を反映しています。 良い形式の仕様には、目的と範囲、機能要件、設計要件、技術基準、テスト要件、納品要件、サポートまたはメンテナンス要件が含まれます。 目的と範囲、機能要件、設計要件、技術基準、テスト要件、納品要件、サポートまたはメンテナンス要件、この技術仕様ガイド で説明されているように。同じ規範性は、CI/CDを論理的に考えることが容易になるため、CI/CDが実現されます。Pipelineは、スクリプトのバッグから、実行可能なリリースポリシーに変わります。
実際には、Pipelineは、手動で実行しているエンジニアではなく、決定を下すべきです。Branchルール、タグ、承認ステップ、署名コンテキスト、デプロイターゲットはすべてエンコードされるべきです。
実行可能なリリースポリシー
- Branchドライブされた意図: main、リリースブランチ、タグは異なるワークフローをトリガーします。
- 明示的なアーティファクト名付け: フラバー、環境、ターゲットは出力に表示されます。
- プロモーションではなく、手動で再構築: __CAPGO_KEEP_0__で検証されたアーティファクトを、再作成せずに進めることができます。
一つの柔軟なスクリプトアプローチでは、すべての人がカスタムフラグを渡し、ストアやテスターが必要とするものと一致することを願っていますが、これが常に失敗します。
チャンネルはバイナリが配信された後、制御を追加します
ネイティブビルドはまだ粗粒です。リリースがストアに配置された後、Capacitorアプリ内でウェブコンテンツを変更する必要は、常に新しいバイナリを再構築する必要があるわけではありません。
That’s where update channels become useful. They let teams target web asset updates to a subset of users inside an installed production binary. For Capacitor teams, one option is Capgoのチームにとって、オプションの1つは実践的なパターンは次のようになります。
CI/CDでバイナリビルド:
- ネイティブアプリの作成、署名、配布 チャンネル割り当て:
- ユーザーまたは環境をベータ、ステージング、プロダクション、またはカスタマースペシフィックストリームにマップします。 map users or environments to beta, staging, production, or customer-specific streams.
- 選択的なロールアウト: ウェブの変更を一部のグループに送信して、より広範な公開を待たずに。
- ロールバックパス: 悪いアップデートを待たずにストアのレビューを待たずに、無効または元に戻す。
まだそのモデルを設定していない場合は、この__CAPGO_KEEP_0__で更新チャンネルの作成と削除についてのウォークスルーを参照してください。 creating and deleting update channels in Capacitor 実際の動作を見ていない場合は、短いデモが役立ちます。
モバイルチームにとって、戦略的なシフトです。ビルドタイプは単なるアーティファクトではありません。CI/CDはバイナリの生成を制御します。チャンネルは、インストール後に変更を公開する方法を制御します。
モダンなビルドワークフローのためのベストプラクティス
正常なビルドシステムは、意見を持っています。開発者全員がリリースの動作を改造するのを許可しません。
最も強力なセットアップは、以下の習慣を共有しています:
最も強力なセットアップは、以下の習慣を共有しています:
- 軸を明確に分離する: 味、環境、署名対象、配布対象を一つの曖昧なラベルに混ぜないようにする。
- CIがチーム向けのアーティファクトを生成するようにする: ローカルビルドは開発用であり、株主の信頼を得るためのものではない。
- リリースのような条件でテストすることを早めに: QAとベータテスターは、実際のアプリとできる限り近い動作を確認するべき。
- サインアセットをラップトップから外す: シークレットは制御されたインフラストラクチャに、狭いアクセスを持たせるべき。
- アーティファクトの名前は人間が読めるようにする: 誰かがファイルの目的を数秒以内に理解できない場合、名前付けは悪い。
- プロモーションを好むことよりも再作成を好むこと: アーティファクトが検証されたら、ワークフローを進めるのではなく、手動で再構築するのではなく、移動すること
- 設計リリース前のロールバック: ストアのロールバックは遅く、運用上の負担が大きい。 Web層のロールバックは、Capacitor の更新が速くなる可能性があるが、チャンネルやポリシーを事前に計画する必要がある。
主な認識の変化は、この点だ:「どのビルドスクリプトを実行するか」というのではなく、「この段階でどのようなリスクを管理しているか」というのを尋ねる。
その質問は、より良いビルドシステムを生み出す。
If your team ships Capacitor apps and wants tighter control over release workflows, チームが Capgo アプリをリリースし、リリースワークフローに対するより厳密な制御を求めている場合、 Capacitor
