プロジェクトを開いてみると build:ios:dev, build:android:qa, build:staging, build:release, build:prod, さらにいくつかのシェルスクリプトが誰も触りたくない
すると誰かが「クライアントにステージングビルドを終わらせるまでの日までに作ってください」と言うのであれば、ミドルレベルのモバイル開発者にとっては、よくわからないようでした。
どの設定を使用するか、どの署名IDを使用するか、どのバックエンドを使用するか、どの配布パスを使用するか
これらの混乱は、ビルドタイプを平坦なリストとして扱うことによるものです。 Capacitor local environment setup各ビルドは、特定の問題を特定のポイントで解決するために存在します。
ユーザーのデバイスまでの間のポイント
- アプリは単にコンパイルされたアプリではありません。
- 目的、対象者、環境に応じてアプリを組み立てたバージョンです。
- コアビルドフラーバー デバッグ vs リリース
- ビルドを配布環境にマッピングする
- 重要な役割を持つCode署名
- CI/CDとアップデートチャンネルを使用したリリースのオーケストレーション
- モダンなビルドフローにおけるベストプラクティス
ソフトウェアビルドの世界を纏める
ビルド名がすべての物語を語ることを想定するのは最も一般的な間違いです。そうではありません。 staging 別のリポジトリでは、「ステージングAPI向けのリリースフラビア」という意味になるかもしれません。別のリポジトリでは、「モックされた決済を含むデバッグ可能なQAアーティファクト」という意味になるかもしれません。別のリポジトリでは、「プライベートに配信されるプロダクション署名ビルド」という意味になるかもしれません。
そのため、チームは混乱してしまいます。ビルドのラベルは、ビルドが実行するジョブを理解している場合にのみ有用です。
ビルドの種類を考えるための有用な方法は、このように考えることです:
- ローカルビルド 個人の開発者が迅速に動くのに役立ちます。
- CIビルド チームの共有ソースとなるものを作成します。
- デバッグとリリースのフラビア アプリがコンパイルされ、インストルメントされる方法を定義します。
- ディストリビューションビルド アプリが受信される人と方法を定義します。
- 署名ビルド プラットフォームがアーティファクトを信頼するかどうかを決定します。
- チャネルベースのアップデート インストール後に変更がどのように動くかを決定します。
競合するカテゴリではありません。積み重ねます。
「ステージングビルド」は、ほとんどの場合、1 つの単一のものではありません。通常、味、環境、署名、配布方法の組み合わせです。
そのため、2 つのチームが「ベータビルドが必要」と言っても、まったく異なるアーティファクトを指すことがあります。
モバイルでは特に、この点が重要です。各ステップが摩擦を生み出すからです。ネイティブコンパイル、シークレット、プロビジョニング、アプリストアのトラッキング、テスターへのアクセス、環境設定、ロールバックなど、すべてが一致する必要があります。1 つでもずれがあれば、リリースプロセスは tribal knowledge になります。すると、1 人のエンジニアが休暇を取ってしまって、誰もクリーンにリリースできないようになります。
この点をうまく扱うチームは、スクリプトを覚えるのではなく、ビルドタイプを品質ゲートとして定義します。各ゲートは、異なるリスクを下げます: 例えば、壊れた code、間違った設定、悪い署名、悪いロールアウト、または悪いリカバリー。
ビルドスペクトラム - ローカルビルド vs CI ビルド
ローカルビルドとは、自分自身のために作成したものです。CI ビルドとは、チームが信頼できるものです。
それは明らかですが、多くのビルドの痛みは、チームがこれら 2 つを混同するときに始まります。誰かが「私のマシンでは動作する」と証明した後、ブランチが CI で失敗するのは、ローカル環境が暗黙的に依存していたキャッシュされた依存関係、手動で編集されたファイル、署名アセットが自動化に含まれていなかったことなど、ローカル環境が暗黙的に依存していたからです。
ローカルビルド
ローカルビルドはプライベート、速い、廃棄可能です。即時の質問に答えるために使用します。
画面が描画できるか？ネイティブプラグインが初期化できるか？GradleまたはXcodeの変更がコンパイルを破壊したか？ログを増やして再現できるか？
ローカルビルドはスピードを優先する。ローカルビルドは、チェックが緩い、ログが冗長、開発者用のフラグ、臨時インストルメンテーションなどが含まれることが多い。
ローカルビルドを重要なものとして推進することは機能しない。ローカルビルドは、コンパイルが成功した1台のノートパソコンでしか、リリースアーティファクトにはならない。
CIビルド
CIビルドは、CIビルドが遅い理由が何なのか。CIビルドは、個人用マシンの状態を除外し、ビルドプロセスを繰り返し実行できるようにする。
CIが健康である場合、CIは3つのことをうまく行う。
- ビルドからゼロから始める： プロジェクトがコンパイルできるか、隠れたローカルアサムションが存在しないかを証明する。
- チームレベルのチェックを実行する： ユニットテスト、linting、パッケージングルールは、同じ場所で同じように実行される。
- トレース可能なアーティファクトを生成する： チームは、ビルドをコミット、ブランチ、パイプライン実行とつなげることができる。
そのワークショップと工場のアナロジーが好きだからです。
あなたのラップトップは、繰り返し実行するベンチです。CIは、プロセスが実際に機能していることを証明する組み立てラインです。 managing dev and prod builds with GitHub Actions.
このガイドを参照してください。 実践的なルールです。
QA、製品、またはサポートがアーティファクトを必要とする場合、それはCIからではなく、開発者のマシンから来るべきです。
CIを受け入れると、ビルドライフサイクルが簡単になります。
フラビアの選択、署名、環境のインジェクション、配布は、チームの誰でも検査できるpipelineに属するべきです。 Core Build Flavors Debug vs Release ビルドのラベルは多くありますが、すべての名前の下で、2つのフラビアが最も重要です。 debug.
と、release
デバッグビルド
デバッグビルドは、人間が動作を調べるのに役立つように設計されています。通常、より多くのメタデータを保持し、トラブルシューティングを容易にし、問題を隠すことができる厳しい最適化を避けます。
建設規格の有用なアナロジーがあります。規格は一般に 指示的, 性能, 特有、および 基準 のタイプに分類されます。デバッグビルドは 指示的 アプローチに適合し、分析に使用する特定のツールと方法を指定します。一方、リリースビルドは パフォーマンス 目標結果に沿ったアプローチ 構造仕様の種類の分解.
実際には、デバッグ用ビルドは、以下のようなものが必要です。
- 読みやすい診断情報 エラーの原因を探すのに役立つスタックトレース、コンソール出力、シンボル
- 開発者用の利便性 モックの切り替え、テストメニュー、エンドユーザーにとって不適切な機能切り替え
- 低抵抗力の反復 迅速なインストールと実行のサイクルが、パッケージの美観よりも重要です。
デバッグ用ビルドは「悪いもの」ではありません。目的を立てたものです。
リリース用ビルド
リリースビルドは、野外のデバイスに作成されます。 それが直ちに優先順位を変えます。
ここで、パッケージの完全性、起動動作、セキュリティポジションの厳しさ、小さいパイロード、予測可能な実行特性を気にするようになります。 また、検査または不正利用のための意図しないエントリポイントも少なくしたいと思います。
トレードオフは単純です。デバッグビルドを簡単に検査できるものは、リリースビルドが生産環境に適していない傾向があります。
チームと一緒に使用する決断境界はこちらです。
| フラバー | 最適 | 何を最適化するか |
|---|---|---|
| デバッグ | 開発、ローカルテスト、問題の再現 | 可視性と反復速度 |
| リリース | ベータ配布、ストアの提出、生産ロールアウト | 安定性、パフォーマンス、信頼性 |
なぜチームがこれを間違うのか
混乱の最大の原因は、「環境」と「フラーバー」を混同することです。
ビルドは リリースフラーバーがステージングサービスに指向されているです。 これはQAでよく行われることです。 そうすることで、非生産的なデータで生産的な動作を実現できます。 ビルドは デバッグフラーバーが開発サービスに指向されている こともできます。 これは、開発者にとっての日常作業に適しています。 これらは異なる軸です。
スクリプトのスプレッドが多く発生するのは、チームがパッケージ名にすべての可能な組み合わせを暗号化するのではなく、ドキュメントでマトリックスを記述していないためです。
ユーザーフェイスの動作をテストする非エンジニアがいる場合にのみリリースフラーバーを配信してください。 デバッグフラーバーは、エンジニアリングワークや故意のトラブルシューティングに使用してください。
これ一つのルールで、多くの間接的な複雑さが排除されます。
ビルドを配布環境にマッピングする
最も多くの議論は、ビルドの種類について終わりにすぎていません。ローカル、デバッグ、リリースを説明し、より難しい質問を無視します: このビルドはどこに行くのでしょうか?
その目的地は、ビルドが何を含むべきか、署名方法、そして受け取るべき人々を決定します。
A practical build workflow usually moves through several environments, each with a different audience and tolerance for risk. If you’re working on Capacitor apps, it also helps to keep a clean mental separation between development and production app behavior in Capacitor多くの「ビルドのバグ」は実際には環境のマッピングミスです。
ナイトリービルドとキャニバービルド
これらは、エンジニア、QA、または内部グループに粗いエッジを許容する人々向けの早期警告ビルドです。
ナイトリービルドは通常、スケジュールに基づいて生成されます。キャニバービルドは、より広範なロールアウト前に狭いアウディエンスに意図的に公開されます。
私はこれらを安定性の約束ではなく、学習ツールとして扱います。
- これらは、次のような質問に答えるのに役立ちます。
- モジュール間でブランチが綺麗に統合されるか?
- 特定のデバイスファミリーのネイティブ依存性アップグレードが、特定のデバイスファミリーを破壊したか?
__CAPGO_KEEP_0__は、期待されるソフトウェアの完成度の高いものを提供することではありません。ノイズの多いフィードバックが得られ、正しいユーザーが通常のチョーンをリリースの問題として呼ぶことになります。
Stagingとbeta
この時点で、製品の品質がエンジニアリングの便利さよりも重要になります。
Stagingまたはbetaビルドは、実際のユーザーが受け取るものに近いものでなければなりません。通常、リリースの味、可能な限り生産的なように設定された構成、プラットフォームツールであるTestFlightまたはGoogle Playテストトラックを通じて制御された配布が必要です。
この時点で、聴衆は変わります。
- QAはリグレッション、ワークフロー、受容基準を検証します。
- 製品マネージャーは、現実的なシェルで動作を確認します。
- 外部テスターは、ユーザビリティ、デバイスカバー、エッジケースを検証します。
- サポートまたは成功チームは、近日予定される変更をプレビューします。
この間違いは、betaを「もう１つのデバッグビルド」とみなすことです。テスターが実際のユーザーフローを評価している場合、リリースの条件が必要です。
プライベート配布ビルド
あるアプリには、全くパブリックストアのユーザーに届くことなく、またはより狭いグループに先に届く必要があるビルドがあります。
__CAPGO_KEEP_0__には、クライアント固有のビルド、内部従業員アプリ、規制されたワークフロー、フィールドオペレーションツール、企業専用の配布が含まれます。これらは、インストールできるアプリとバックエンドにアクセスできるユーザーを制御する必要があるため、厳格な制御が必要です。
__CAPGO_KEEP_0__はここでも命名が危険です。チームは「企業ビルド」と言いますが、実際には何を意味するかが異なります。
- a 私有署名の内部アプリ
- a ストア配布アプリに内部のみアクセス制御
- a カスタマー固有のブランド化されたアーティファクト
- a ステークホルダーレビュー用のプレプロダクションリリース候補
これらは異なる運用モデルです。パイプラインと命名でそれらを分離してください。
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__は公の約束です。アプリストア、プレイストア、またはユーザーに配布される同等の承認済みチャネルに配布されます。
この時点でビルドは面白くないはずです。それは褒め言葉です。
__CAPGO_KEEP_0__は再現可能で正しく署名され、リリース条件でテストされ、ロールバック計画と紐付けされているものでなければなりません。最後の手段の手動編集、機械固有のハック、または「次のビルドで修正する」という妥協は望みません。
ここに簡単な要約があります。
ソフトウェアビルドタイプとその特性
| ビルドタイプ | 対象者 | 構成 | 配布方法 |
|---|---|---|---|
| ローカル開発者 | 個別開発者 | 通常、デバッグ、高速反復、ローカル環境設定 | ローカルマシンから直接インストール |
| CI検証 | エンジニアリングチーム | 繰り返し自動ビルド、共有チェック | CI アーティファクト ストレージ |
| ナイトリーオアキャニリー | 内部テスター、選択されたチームメンバー | 早期統合状態、制限されたロールアウト | 内部配布ツール |
| ステージングまたはベータ | QA、製品、外部テスター | 通常リリースのような非公開環境マッピング | TestFlight、プレイテストトラック、プライベートリンク |
| アドホックまたはエンタープライズ | 内部従業員、クライアント、制限されたグループ | 制御された構成、目的地固有の署名 | プライベート配布チャネル |
| リリース | パブリックユーザー | 最終リリース設定、ストア用署名 | App StoreまたはGoogle Play |
正しいビルドタイプは、リスク耐性のあるユーザーと一致するものです。多くのリリースミスは、チームがその一致をスキップすることによって発生します。
Code署名の重要性
モバイル用のビルドファイル単体では何も意味しません。プラットフォームは、信頼できるソースから来て、作成後誰もが変更しなかったことを証明する必要があります。その証明は code署名.
ビルドが完全にコンパイルできたものの、インストール、アップロード、または起動が正しく行われなかったことがありましたか? その場合は、署名が問題の原因だった可能性があります。
署名は何を証明するの?
モバイルチームにとって、code署名は3つの役割を果たします。
- 正当性: アプリを開発した開発者または組織とアプリを紐付けます。
- 完全性: 署名後から署名されたアーティファクトが改ざんされていないことを証明します。
- 承認: 特にAppleプラットフォームでは、署名はアプリが実行できる場所や方法を制御します。
多くの開発者が混乱するのは、この3番目の点です。署名は単にアイデンティティではありません。許可も含まれます。
したがって、同じアプリcodeは、ローカルでデバイス上で実行したい場合、テスターに配布したい場合、内部にデプロイしたい場合、またはストアに提出したい場合に異なる署名材料を必要とすることができます。
目的地によって署名がどのように変化するか
このメンタルモデルは、プロセスを常に保つことができます: 署名は配布に従います.
A local developer install uses one set of identities and permissions. A beta build sent through TestFlight uses another. An internal distribution path may require different profiles again. A public store release has its own signing expectations and review-compatible packaging.
That’s why “just resign the build” is rarely a small ask. Once signing changes, the artifact’s allowed destinations can change with it.
A disciplined setup usually includes:
- CIで署名アセットを保存する 個人用ノートパソコンには保存しない
- ターゲットごとに明確な区別 開発、プライベートテスト、エンタープライズ、ストアリリース
- ローテーションとアクセス制御 特に、契約社員や複数の製品チームがインフラを共有する場合
- 監査可能性 チームが__CAPGO_KEEP_0__アプリ内でWeb更新を配信する場合、署名の2層を考慮する必要があります。
If your team ships web updates inside a Capacitor app, there’s a second signing layer to think about as well. This overview of Capacitorのアップデート用のcode署名のためのエンドツーエンドのセキュリティ __CAPGO_KEEP_0__が有用であるのは、ネイティブバイナリの信頼性とアップデートパッケージの信頼性を分離するからである。
署名の問題は、暗号学的問題ではなく、不明瞭な所有権、手動の操作、ビルドパイプラインが適用されたアイデンティティを隠すことによるものである。
署名材料は、実際のインフラストラクチャと同じように扱うべきである。
CI/CDとアップデートチャンネルのオーケストレーション
チームが成熟するまでの時点で、ビルドの種類の種類を知ることの挑戦ではない。人間の推測なしでそれらを調整することの挑戦である。
その調整はCI/CDに属する。
パイプラインはビルド契約である。
信頼性のあるパイプラインは、毎回同じ質問に答えるべきである。
- このビルドは何のために?
- どの種類のビルドを使用する?
- どの環境の値を受け取るか
- どのテストを通過する必要があるか
- どの署名のIDが適用されるか
- アーティファクトが配布される場所
その構造は、良い技術仕様のモデルを表しています。 良く作られた仕様には、目的と範囲、機能要件、設計要件、技術基準、テスト要件、配布要件、サポートまたはメンテナンス要件が含まれます。この技術仕様ガイド で説明されているように。同じ規範性はCI/CDを論理的に考えることを容易にする。pipelineはスクリプトのバッグから、実行可能なリリースポリシーに変化する。
実際、pipelineは、手動で実行しているエンジニアではなく、自分で決定するべきである。
Branchルール、タグ、承認ステップ、署名コンテキスト、デプロイメントターゲットなど、すべての情報はエンコードされるべきである。
- どれが機能するか:「ブランチドライバント」 メイン、リリースブランチ、およびタグは異なるワークフローをトリガーします。
- 明示的なアーティファクト名付け: フラバー、環境、およびターゲットは出力に表示されます。
- プロモーションではなく、手作業で再構築: 検証済みアーティファクトを手作業で再構築するのではなく、必要に応じてアーティファクトを移動してください。
一つの柔軟なスクリプトアプローチが常に失敗するのは、誰もがカスタムフラグを渡し、ストアやテスターが必要とするものと一致することを願っているからです。
チャンネルはバイナリが配信された後、制御を追加します。
ネイティブビルドはまだ粗粒です。一度リリースがストアに配置されると、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、は署名されたウェブバンドルをターゲットチャンネルに公開するため、JavaScript、CSS、コピー、設定、資産の変更を推し、ネイティブシェルを毎回再構築する必要がなくなります。
実用的パターンは次のようになります:
- CI/CDでバイナリビルド: nativeアプリの作成、署名、配布を行います。
- チャネル割り当て: ユーザーや環境をベータ、ステージング、プロダクション、またはカスタマー固有のストリームにマップします。
- セレクティブロールアウト: 1つのグループにウェブ変更を送信して、より広範な露出を待たずに。
- ロールバックパス: 悪いアップデートを無効または復元するために、ストアのレビューを待たずに。
__CAPGO_KEEP_0__でアップデートチャネルを作成して削除する方法についてのこのウォークスルーをまだ設定していない場合は、 creating and deleting update channels in Capacitor チャネルが実際にどのように動作するかを理解するのに役立つ短いデモがあります:
__CAPGO_KEEP_0__でチャネルを作成して削除する方法についてのこのウォークスルーをまだ見たことがない場合は、
この戦略的シフトは、多くのモバイルチームが必要としている。
ビルドタイプは、単なるアーティファクトだけではない。
CI/CDはバイナリの生成方法を制御し、チャンネルはインストール後変更の公開方法を制御する。
現代のビルドワークフローのベストプラクティス
- 正当なビルドシステムは、意見を持っている。 開発者がリリース動作を改造できるのを許さない。
- 最も強力なセットアップは、以下の習慣を共有している。 明確に分離する:
- flavor、環境、署名ターゲット、配布ターゲットは、1つの曖昧なラベルに混ぜない。 CIがチーム向けのアーティファクトを生成する:
- ローカルビルドは開発用であり、ステークホルダーへの信頼にはなり得ない。 リリースのような条件でテストする:「QAとベータテスターは、実際のアプリとできるだけ近い動作を確認する。
- __CAPGO_KEEP_0__ 人間が読めるようにファイル名を設定する:
- 数秒以内にファイルの目的を判断できない場合、ファイル名は不十分です。 再現よりも促進を優先する:
- アーティファクトが検証されたら、ワークフローを進めるのではなく、手動で再構築するのではなく、移動するのを優先する。 store rollback is slow and operationally heavy. Web-layer rollback for Capacitor updates can be much faster, but only if you planned the channels and policies first.
ストレージのロールバックは遅く、運用上重いです。 __CAPGO_KEEP_0__ の更新用の Web 層のロールバックは、チャンネルやポリシーを事前に計画した場合にのみ、速くできます。
大きな心の変化は、この質問を尋ねることです：“この段階で何のリスクを管理しているか？” この質問は、より良いビルドシステムを生み出します。
If your team ships Capacitor apps and wants tighter control over release workflows, チームが Capgo アプリをリリースし、リリースワークフローに対するより厳密な制御を望む場合、 Capacitor
