プロジェクトを開いてみると、 build:ios:dev, build:android:qa, build:staging, build:release, build:prod、いくつかのシェルスクリプトが誰も触りたくない。すると誰かが言う «この日までにクライアント用のステージングビルドを作ってください» と言うのであれば、ミドルレベルなモバイル開発者にとっては、よくわからない要求になります。どの設定を使用するか、どの署名IDを使用するか、どのバックエンドを使用するか、どの配布パスを使用するか
その混乱は、ビルドタイプを平坦なリストとして扱うことから生じることが多い。そうではない。ワークフローである。
ビルドは単にコンパイルされたアプリだけではない。目的、対象者、環境に応じてアプリを組み立てたバージョンである。デバッグを助けるビルドもある。QAが安全に壊すことができるビルドもある。リリースエンジニアが信頼できるアーティファクトを生成できるビルドもある。製品チームがリスクが少ない変更を配信できるビルドもある。
ローカル環境設定がまだ不安定な感じがする場合は、まず適切な Capacitorローカル環境設定
を整えることから始めてください。基盤ツールが予測可能になるまで、ビルドの複雑さを論理的に理解するのは容易になります。
- 目次
- ソフトウェアビルドの世界を整理する
- CI ビルド
- ビルドを配布環境にマッピング
- Code署名の重要性
- CI/CDとアップデートチャンネルを用いたリリースのオーケストレーション
- モダンなビルドワークフローのためのベストプラクティス
ソフトウェアビルドの世界を整理する
最もよく見る間違いはビルド名が全てを説明することを想定していることです。そうではありません。 staging __CAPGO_KEEP_0__は「リリースの味付けがステージングのAPIに向けられている」という意味になるかもしれません。別のリポジトリでは「デバッグ可能なQAアーティファクトにモックされた決済」という意味になるかもしれません。3つ目では「プライベートに配布されるプロダクション署名のビルド」という意味になるかもしれません。
そのため、チームは絡み合いがちになります。ラベルは、ビルドが何を実行しているかを理解している場合にのみ有用です。
ビルドのタイプについて考える有効な方法は次のとおりです:
- ローカルビルド 個々の開発者に迅速に動くのに役立ちます。
- CIビルド チームの共有ソースとなるものを作成します
- デバッグとリリースのフラビア アプリがコンパイルされ、インストルメントされる方法を定義します。
- 配布用ビルド アプリがどのユーザーに配布され、どのように配布されるかを定義します。
- 署名ビルド プラットフォームがアーティファクトを信頼するかどうかを決定します。
- チャネルベースの更新 インストール後に変更がどのように動作するかを決定します。
競合するカテゴリではありません。重ねて使用します。
ステージングビルドはほとんどの場合、単一のものではありません。通常は、フラビア、環境、署名、配布の選択肢の組み合わせです。
2つのチームが「ベータビルドが必要です」と言っても、まったく異なるアーティファクトを指している可能性があります。
これは、モバイルでは特に重要です。各ステップごとにフリクションが増加します。ネイティブコンパイル、シークレット、プロビジョニング、アプリストアのトラッキング、テスターへのアクセス、環境設定、ロールバックなど、すべての要素が一致する必要があります。1つの要素が不整合になると、リリースプロセスはtribal knowledgeになります。すると、1人のエンジニアが休暇を取ると、誰もきれいにリリースできなくなります。
このチームは、スクリプトを覚えるのではなく、ビルドタイプを品質ゲートとして定義します。各ゲートは、異なるリスクを下げます: codeが壊れた、設定が間違った、署名が悪かった、ロールアウトが悪かった、または復旧が悪かった。
ローカルビルド vs CIビルド
ローカルビルドは自分用に作成したバージョンです。CIビルドはチームが信頼できるバージョンです。
それは明らかですが、多くのビルドの痛みは、チームがこれら2つを混同するときに始まります。誰かが「私のマシンでは動作する」と証明すると、ブランチがCIで失敗するのは、ローカル環境が暗黙的にキャッシュされた依存関係、手動で編集されたファイル、または署名アセットが自動化に含まれない場合に起こります。
ローカルビルド
ローカルビルドはプライベート、速い、廃棄可能です。即時の質問に答えるために使用します。画面がレンダリングできるか?ネイティブプラグインが初期化できるか?GradleまたはXcodeの変更がコンパイルを破壊したか?ログを増やして再現できるか?
良いローカルビルドはスピードを優先します。チェックが緩い、ログが詳細、開発者が設定できるスイッチ、そして一時的なインストルメンテーションを含みます。それはいいことです。
その仕事は、速いフィードバックを提供することです。ローカルビルドを、より重要なものに昇格させることは機能しません。ローカルビルドは、コンパイルが成功した1台のノートパソコンでしか動作しないので、リリースアーティファクトにはなり得ません。
CIビルド
CIビルドは、チームが信頼できるバージョンです。CIビルドは、ローカルビルドとは異なる目的を持つべきです。CIビルドは、ローカルビルドのフィードバックを提供するのではなく、信頼できるビルドを提供するべきです。
CI ビルドは、より速い理由がある。CIは、個人のマシン状態を方程式から除去し、ビルドプロセスを繰り返し実行するからです。
CIが健康である場合、3つのことをよく行います:
- リビルドから始める: プロジェクトがコンパイルできることを証明し、隠れたローカル仮定を排除します。
- チームレベルのチェックを実行します: ユニットテスト、linting、パッケージングルールは、同じ場所で毎回実行されます。
- トレース可能なアーティファクトを生成します: チームはビルドをコミット、ブランチ、パイプライン実行とつなげることができます。
なぜ私はワークショップ対ファクトリーのアナロジーを好きかというと、以下の理由があります。
あなたのラップトップは、開発のベンチです。CIは、プロセスが実際に機能することを証明する製造ラインです。 managing dev and prod builds with GitHub Actions.
__CAPGO_KEEP_0__ Actionsを使用した開発とプロダクションビルドの管理に関するガイドです。 QA、製品、またはサポートがアーティファクトを必要とする場合、それはCIからではなく、開発者のマシンから来るべきです。
それを認識した後、ビルドライフサイクル全体が簡単になります。フラビアの選択、署名、環境のインジェクション、配布は、チームの誰もが検査できるPipelineに属するべきです。
Core Build Flavors Debug vs Release
ビルドには多くのラベルが使用されますが、その名前の下に、2つのフラビアが最も重要です。 debug と release.
開発者とエンドユーザーは異なるものを必要とします。
デバッグ ビルドは、人間が動作を検査することを目的としています。通常、より多くのメタデータを保持し、トラブルシューティングを容易にし、問題を隠すことができる厳しい最適化を避けます。
There’s a useful analogy from construction specs. Specifications commonly fall into
Specifications 指示的, 性能, 専有、および 基準 型、およびデバッグ ビルドは、適切なツールと方法を指示するため、指示的アプローチに適しています。 一方、リリース ビルドは、構築仕様の分解で説明されているように、必要な結果に焦点を当てた性能アプローチにマップされます。 実際には、デバッグ ビルドは、以下のようなものが含まれます: 指示的 性能 専有 、および.
基準
- 診断可能な出力: エラーログ、コンソール出力、シンボルが故障の原因を特定するのに役立つ。
- 開発者用機能: モックの切り替え、テストメニュー、機能切り替えがエンドユーザーにとって不適切なものです。
- 低抵抗力の繰り返し: インストールと実行のサイクルが速くなれば、パッケージの美観よりも重要になります。
デバッグビルドは「悪い」ものではありません。目的を果たすものです。
リリースビルド
リリースビルドは、実際に使用されているデバイス用に作成されます。そのため、優先事項は即座に変わります。
今度はパッケージの完全性、起動動作、セキュリティポジションの強化、パケットサイズの小ささ、実行時間の予測可能性などに注目します。また、検査または不正使用のための不必要なエントリポイントの数を減らしたいと思います。
トレードオフは単純です。デバッグビルドを簡単に検査できるものは、リリースビルドが生産環境で適切ではない傾向があります。
ここでは、チームと一緒に使用する境界線を示します:
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_1__ | __CAPGO_KEEP_2__ |
|---|---|---|
| Debug | 開発、ローカルテスト、問題の再現 | 速度と反復 |
| リリース | ベータ配布、ストアの提出、生産のロールアウト | 安定性、パフォーマンス、信頼 |
チームがこれを間違えている理由
混同するのは「環境」と「フレーバー」です。
ビルドは__CAPGO_KEEP_3__ リリース用のフラビアがステージング用サービスの指向. それは、QAの一般的なことです。非生産的なデータで生産的な動作を実現したいからです。ビルドはまた デバッグ用のフラビアが開発用サービスの指向 日常の開発のために。 それは異なる軸です。
スクリプトのスプレッドが多く発生するのは、チームがパッケージ名にすべての可能な組み合わせをエンコードするのではなく、ドキュメントでマトリックスを記述しないことからです。
非エンジニアがユーザーフェイスの動作をテストするときは、リリース用フラビアを配信してください。エンジニアリングの作業や意図的なトラブルシューティングのために、デバッグ用フラビアを保ちましょう。
その1つのルールが、多くの偶然の複雑さを排除します。
ビルドを配信環境にマッピングする
ビルドの種類についての議論は、よく早く止まります。ローカル、デバッグ、リリースについて説明し、より難しい質問を無視します: このビルドはどこに行くのか?
その目的地は、ビルドが何を含むべきか、署名するべきか、誰が受け取るべきかを決めます。
実用的ビルドワークフローは、リスク耐性の異なる各環境を通過することが多く、各環境には異なる受け手と聴衆がいます。 Capacitor アプリを開発している場合、 Capacitor アプリの開発と生産アプリの動作を清潔に分離することも役立ちます。 開発と生産アプリの動作を Capacitor で清潔に分離することも役立ちます。環境マッピングミスが多くの場合、実際には「ビルドのバグ」です。
Nightlyとcanary
これらは、エンジニア、QA、または小規模な内部グループが粗いエッジを許容することを望む場合にのみ使用することを目的とした、早期警告ビルドです。
通常、Nightlyビルドはスケジュールに基づいて生成されますか、または最新のメインブランチの状態から生成されます。Canaryビルドは、より広範なロールアウト前に、狭いアウディエンスに意図的に公開されます。私は、これらを安定性の約束として扱うのではなく、学習ツールとして扱います。
これらは、次のような質問に答えるために役立ちます。
- モジュール間でブランチが綺麗に統合されるかどうか。
- 特定のデバイスファミリーのネイティブ依存性のアップグレードが、特定のデバイスファミリーを破壊したかどうか。
- 内部テスターが、より広範なベータ公開前に、リグレッションを検出できるかどうか。
何が機能しないのは、canaryビルドを、ソフトウェアが磨かれていないことを期待する人に与えることです。そうすると、ノイズの多いフィードバックが得られ、間違ったアウディエンスが通常のチョーンをリリース問題として呼び出すことになります。
Stagingとbeta
この時点で、製品の品質がエンジニアリングの便宜よりも重要になります。
Stagingまたはbetaビルドは、実際のユーザーが受け取るものに近いものでなければなりません。通常、これはリリースの味、可能な限り生産的な構成、プラットフォームツールであるTestFlightまたはGoogle Playテストトラックを通じて制御された配布を意味します。
The audience shifts here:
- QAはバグの再発生、ワークフロー、受容基準を検証します。
- 製品マネージャーは、実際のシェル内で動作を確認します。
- 外部テスターは、ユーザビリティ、デバイスカバー、エッジケースを検証します。
- サポートまたは成功チームは、近日公開予定の変更をプレビューします。
ここでの間違いは、「ベータ版は「デバッグ用の別のビルド」だけ」と考えることです。テスターが実際のユーザーフローを評価している場合、リリースに似た条件が必要です。
プライベート配布ビルド
あるアプリは、全く公表されないビルドや、より狭いグループに先に到達する必要があるビルドが必要です。
これには、クライアント固有のビルド、内部従業員用アプリ、規制されたワークフロー、フィールドオペレーションツール、企業のみの配布が含まれます。これらは、インストールできるユーザーとバックエンドにアクセスできるユーザーを制御する必要があるため、厳格な制御が必要です。
ここでも名前付けが危険です。チームは「企業用ビルド」と言っている場合、実際には何らかの異なることを意味しています。
- プライベート署名の内部アプリ
- ストアで配布されたアプリに内部のみのアクセス制御を設定したもの
- 顧客固有のブランド化されたアーティファクト
- ステークホルダーへのレビュー用のプレプロダクションリリース候補
それらは異なる運用モデルです。パイプラインと名前付けにおいて、それらを分離してください。
本番
本番ビルドは、ユーザーに配布される公約です。App Store、Play Store、またはあなたのユーザーに配布される同等の承認済みチャネルに送られます。
この時点で、ビルドは面白くないはずです。それは賛辞です。
本番ビルドは、再現可能で正しく署名され、リリース条件でテストされ、ロールバック計画と結びついているものになりたいのです。最後の手段の手動編集、機械依存のハック、または「次のビルドで修正する」という妥協は望みません。
ここに、目次版があります。
ソフトウェアビルドの種類とその特徴
| ビルドの種類 | 対象 | 構成 | Distribution Method |
|---|---|---|---|
| ローカル開発者 | 個人開発者 | 通常デバッグ、高速反復、ローカル環境設定 | ローカルマシンから直接インストール |
| CI検証 | エンジニアリングチーム | 繰り返し自動ビルド、共有チェック | CIアーティファクトストレージ |
| 毎晩またはキャニャリ | 内部テスター、選択されたチームメンバー | 早期統合状態、限定的なロールアウト | 内部配布ツール |
| ステージングまたはベータ | QA、製品、外部テスター | 通常リリースのような非公開環境マッピング | TestFlight、Playテストトラック、プライベートリンク |
| アドホックまたはエンタープライズ | 内部従業員、クライアント、制限グループ | 制御された構成、目的地固有の署名 | プライベート配布チャネル |
| 本番 | 一般ユーザー | 最終リリース構成、ストア用の署名 | App Store or Google Play |
__CAPGO_KEEP_0__のビルドタイプは、リスク耐性の高いターゲットユーザーに適したものです。多くのリリースミスは、チームがその一致をスキップしたときに発生します。
Codeの署名
モバイルでは、ビルドファイル単体では何も意味しません。プラットフォームは、信頼できるソースから来て、作成後誰もが変更しなかったことを証明する必要があります。その証明は code署名.
コンパイルが完璧なビルドが、インストール、アップロード、または起動が正しく行えない場合、署名が問題だったことがあります。
__CAPGO_KEEP_0__署名が実際に証明すること
モバイルチームにとって、code署名は3つの役割を果たします。
- 正当性: __CAPGO_KEEP_0__署名はアプリを開発した開発者または組織と紐付けます。
- 完全性: 署名が行われていないかどうかを証明するのに役立ちます。
- Authorization: Appleプラットフォームでは特に、実行する場所や方法を制御します。
多くの開発者が混乱するのは、3番目の点です。署名は単にアイデンティティだけではありません。許可も含まれます。
同じアプリcodeは、ローカルで実行したい場合、テスターに配布したい場合、内部に配布したい場合、またはストアに提出したい場合に、異なる署名資材を必要とする可能性があります。
目的地によって署名がどのように変化するか
このメンタルモデルは、プロセスを常に保つのに役立ちます。 署名は配布に従います。.
ローカル開発者インストールでは、1つのアイデンティティと許可セットが使用されます。テストフライトを通じて送信されたベータビルドでは別のものが使用されます。内部配布パスでは別のプロファイルが必要になることもあります。パブリックストアのリリースには独自の署名の期待値とレビュー互換のパッケージングが必要です。
署名が変更されると、許可された目的地も変更される可能性があるため、「ビルドを再署名するだけ」はほとんどの場合小さな要求ではありません。
規則正しいセットアップでは、通常、CIで署名資産を保存します。
- CIで署名資産を保存することで、署名資産を管理し、署名プロセスを簡素化し、署名プロセスを自動化することができます。 __CAPGO_KEEP_0__
- 開発環境、プライベートテスト、企業向け、ストアリリース. __CAPGO_KEEP_0__、__CAPGO_KEEP_1__のアップデート用サイン
- __CAPGO_KEEP_0__のアップデート用サインの信頼性とアップデートパッケージの信頼性を分離するためによく使われる. __CAPGO_KEEP_0__のアップデート用サインの信頼性とアップデートパッケージの信頼性を分離するためによく使われる。
- __CAPGO_KEEP_0__のアップデート用サインの信頼性とアップデートパッケージの信頼性を分離するためによく使われる。 __CAPGO_KEEP_0__のアップデート用サインの信頼性とアップデートパッケージの信頼性を分離するためによく使われる。
Capacitorのアップデート用サインの信頼性とアップデートパッケージの信頼性を分離するためによく使われる。 end-to-end security for Capacitor updater code signing __CAPGO_KEEP_0__のアップデート用サインの信頼性とアップデートパッケージの信頼性を分離するためによく使われる。
__CAPGO_KEEP_0__のアップデート用サインの信頼性とアップデートパッケージの信頼性を分離するためによく使われる。
__CAPGO_KEEP_0__のアップデート用サインの信頼性とアップデートパッケージの信頼性を分離するためによく使われる。
CI/CDとアップデートチャンネルとともにリリースを調整する
チームが成熟した段階で、ビルドの種類を知るという課題はもうありません。人間の推測なしに、それらを調整することです。
CI/CDで調整するのはその役割です。
パイプラインはビルド契約です。
信頼できるパイプラインは、毎回同じ質問に答えるべきです:
- このビルドは何のために
- どのフラビアを使用する
- どの環境値を受け取る
- どのテストを通過する
- どの署名のアイデンティティが適用される
- アーティファクトはどこに配信される
That structure mirrors a good technical specification. A well-formed spec should include 目的と範囲、機能要件、設計要件、技術基準、テスト要件、納品要件、サポートまたはメンテナンス要件, として説明されている この技術仕様ガイド. その同じ規範性により、CI/CD が論理的に考えることが容易になる。Pipeline は、スクリプトの袋から、実行可能なリリースポリシーに変化する。
実際には、Pipeline は、エンジニアが手動で実行しているのではなく、決定を下すべきである。
Branch rules、tags、承認ステップ、署名コンテキスト、およびデプロイメントターゲットはすべて、エンコードされるべきである。
- どれが機能するか: Branch-driven intent:
- main、リリースブランチ、およびタグは、異なるワークフローをトリガーする。 Explicit artifact naming:
- flavor、環境、およびターゲットは、出力に表示されるべきである。 検証済みアーティファクトを前方に進めるのではなく、適時再作成するのではなく。
一貫性のあるスクリプトアプローチが失敗するのは、常にストアやテスターが必要とするものと一致することを期待して、カスタムフラグをパスすることです。
チャンネルはバイナリが配信された後、制御を追加します。
ネイティブビルドは依然として粗粒です。リリースがストアに配置された後、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 つのオプションは、署名済みウェブバンドルをターゲットチャンネルに公開することです。JavaScript、CSS、コピー、構成、資産の変更を推し、ネイティブシェルを毎回再構築する必要がなくなります。実用的パターンは次のようになります。
CI/CD でバイナリビルド:
- ネイティブアプリの作成、署名、配布 チャンネル割り当て:
- ユーザーまたは環境をベータ、ステージング、プロダクション、またはカスタマー固有のストリームにマップします。 __CAPGO_KEEP_0__
- 選択的なロールアウト: ウェブの変更を一部のグループに送信して、より広範な公開を待たずに。
- ロールバックパス: 悪いアップデートを待たずにストアのレビューを待たずに無効または元に戻す。
まだそのモデルを設定していない場合は、この__CAPGO_KEEP_0__で更新チャンネルの作成と削除についてのウォークスルーを参照してください。 creating and deleting update channels in Capacitor 動作を確認していない場合は、短いデモが役立ちます。
モバイルチームにとって、戦略的なシフトです。ビルドタイプは単なるアーティファクトではありません。CI/CDはバイナリの生成を制御します。チャンネルは、インストール後に変更を公開する方法を制御します。
モダンなビルドワークフローのためのベストプラクティス
健全なビルドシステムは、意見を持っています。開発者全員がリリースの動作を改造することを許可しません。
最も強力なセットアップは、以下の習慣を共有しています:
最も強力なセットアップは、以下の習慣を共有しています:
- __CAPGO_KEEP_0__ 軸を明確に分離する:
- 味、環境、署名対象、配布対象を一つの曖昧なラベルに混ぜないでください。 CIがチーム向けのアーティファクトを生成するようにする:
- ローカルビルドは開発用であり、株主の信頼を得るものではありません。 リリースのような条件でテストする:
- QAやベータテスターは、実際のアプリとできる限り近い動作を確認するべきです。 署名アセットをラップトップから外す:
- シークレットは制御されたインフラストラクチャに、狭いアクセス権限で保存するべきです。 アーティファクトの名前を人間が読めるようにする:
- ファイルの目的を数秒以内に理解できない場合は、名前付けが悪いです。 プロモーションを優先する:「アーティファクトが検証されたら、ワークフローを進めるのではなく、手動で再構築するのではなく、移動することです。
- リリース前に設計を戻す: ストアの戻しは遅く、運用上の負担が大きい。ウェブ層の戻しは、Capacitor の更新がはるかに速くなる可能性があるが、チャンネルやポリシーを事前に計画しないとできない。
最大の考え方の変化は、このことだ: 「どのビルドスクリプトを実行するか」というのではなく、「この段階でどのようなリスクを管理しているか」というのを尋ねる。そうすることで、より良いビルドシステムが作られる。
あなたのワークフローがその質問に明確に答えれば、リリースプロセスはより簡単に運用でき、より簡単に監査でき、そして、1人の上級エンジニアが正しい呪文を思い出す必要がなくなる。
あなたのチームが Capacitor アプリをリリースし、リリースワークフローの制御をより強くしたい場合、 Capgo is worth evaluating as part of that stack. It handles targeted live updates for web assets inside Capacitor apps, supports signed bundles, channel-based rollouts, and rollback controls, which makes it useful when you need faster fixes without replacing your native build pipeline.
