リリース日はよく似ています。CIログを監視している誰かがいるかもしれません。署名ステップがまだ機能するかどうか確認している誰かがいるかもしれません。開発者が最後のミニマムマージコンフリクトを解決しようとしているかもしれません。製品は、修正が今日のビルドに含まれるかどうか尋ねています。モバイルアプリケーションを配信している場合、さらに1層の不安定さが加わります。codeが用意された後でも、ユーザーが修正を確認するまでの日数を待つ必要があるかもしれません。
そのリリースパターンはスケーラブルではありません。エンジニアリング時間を浪費し、計画の不確実性を生み出し、小さな変更を高リスクのイベントに変えます。より多くの英雄的行動が必要ではなく、問題を早期に検出し、メインブランチを健康に保ち、コミットから顧客への影響までの驚きの数を減らす配信システムが必要です。
その時、継続的統合の利点が実践的なものになるのです。CIは単に自動化のために自動化することではありません。チームが毎日どのように働くかを変えるのです。モバイルチームにとって、非ネイティブ変更のためのlive updateパスと組み合わせると、より多くの価値が生まれます。
目次
- チームがマニュアルリリースから脱出する必要性
- 継続的統合とは何ですか?
- 開発を加速する技術的なベネフィット
- 再作業が少ないことで、配達の摩擦が低下します
- 実行可能なモバイルCIのセットアップの例
- CIの旅を始める
チームがマニュアルリリースから脱出する必要がある理由
マニュアルリリースは2種類のダメージを引き起こします。視覚的なダメージは深夜の混乱、共有ドキュメント内のチェックリスト、リリースマネージャーがホットフィックスを含むブランチを思い出すことです。視覚的なダメージはチーム全体がその痛みに適応することです。開発者は変更を長く保留し、製品は各リリースに多くの作業を組み込む。QAは大きい差分と確信の欠如を経験します。
モバイルチームはこれをより深く感じます。ウェブ展開が破損しても、通常は迅速に修正できます。ネイティブモバイルリリースが破損すると、サポート、製品、エンジニアはレビューキューに待機し、タイムラインを完全に制御できないことを説明するのに苦労します。そのため、リリースプロセス設計はcode品質と同じくらい重要です。
マニュアルリリースは単に配信を遅らせるだけでなく、チームを配信を恐れるように訓練します。
CIは運用モデルを変える。統合をスプリントの終わりに特別なイベントとして扱うのではなく、CIは定期的な習慣に変える。開発者は小さな変更を頻繁にマージし、システムはアプリケーションをビルドし、テストを実行し、チームに迅速に問題が発生したことを伝えます。問題は小さく残ります。なぜなら、変更は小さく残っているからです。
リリース会話も変わります。製品は「今すぐどれがリリースできるか？」と尋ねるのではなく、「次のリリースにどれくらいのものを詰め込めるか？」と尋ねることができます。サポートは明確な答えを得ることができ、エンジニアは変更点を再構築する時間を減らし、どれをリリースするかを決定する時間を増やすことができます。
モバイルチームが古いワークフローとより現代的なワークフローを比較する場合、このトレードオフはOTAアップデートと手動のストアへの提出を対比することで明らかになります。 ポイントはプロセスを削除することではありません。リリース日を主な品質管理機構として使用するのを止めることです。通常、リリースの痛みはプロセスに遡ることができます。
大きなバッチサイズ:
- __CAPGO_KEEP_0__が多く到着するため、エラーを分離するのは難しくなります。 More code が一度に到着するため、エラーの特定が困難になります。
- 期限がすでに厳しい状況でチームが対立を発見することがあります。 人間による検証のみ:
- 人々は一部の問題を発見することができますが、自動チェックの一貫性と一致するものではありません。 遅れた回復:
- 遅延した回復: 連続的なインテグレーションは、リスクのあるリリースイベントに変わり得る単純な修正です。
CIは、各の失敗モードを直接攻撃することで機能します。
連続的なインテグレーションとは何ですか。
想像してみてください。複数の人が大きなレゴセットを組み立てています。1つのオプションは、各人が数日間で大きなセクションを組み立ててから、最後にそれらを強制的に組み合わせることです。その場合、通常はソフトウェアのインテグレーションが失敗する同じ方法で失敗します。パーツが揃いません。誰かが間違ったパーツを使いました。誰も、間違いがいつ発生したかを知りません。
CIの方法は異なります。各人が頻繁に小さなパーツを追加し、モデルが常にチェックされながら成長します。ビルドは安定しています。各追加は、次のものが積み重なる前に検証されます。
コアループ
実際のレベルでは、CIは繰り返しループです。
- 開発者が共有リポジトリに小さな変更をプッシュします。
- パイプラインがアプリケーションをビルドします。
- 自動テストがその変更に対して実行されます。
- チームはすぐにフィードバックを受け取ります。
- チェックが通れば、codeはメインブランチに統合することが安全です。
そのループは単純に見えますが、チームの行動に重要な影響を与えます。開発者は長期間のブランチに座るのを止めます。レビュアーは小さなプルリクエストを受け取ります。エラーは、変更されたcodeの量が限られているため、簡単に追跡できます。チームはメインブランチを積極的に保護するのではなく、事後修正として扱うのを止めます。
CIとCDの境界線
ここではチームが混乱することが多いです。
継続的インテグレーション は頻繁にcodeをマージし、自動で検証することです。
継続的デリバリー は検証済みのソフトウェアが常にリリース可能な状態にあることを意味します。
継続的デプロイ はさらに進んで、合格した変更を自動でユーザーに配信します。
CIをDevOpsのすべての側面で使用することが多く、これが混乱の原因です。計画が雑になります。チームが「CIを持っている」と言っている場合、ビルドが自動で緑になるまで、またはリリースがtribal知識に依存している場合、健康的なCIを持っていない可能性があります。
リリース側の方程式について、清潔なメンタルモデルを得るには、この 継続的デプロイとは実際にどのような意味か は便利である。なぜなら、code検証と実際の配信決定を分離するからだ。
実践的なルール: 開発者がメインブランチに信頼を置いていない場合、CIシステムは存在するかもしれないが、CI実践は存在しない。
CIの堅固なセットアップには、以下の幾つかの基本的なコンポーネントが含まれることが多い。
| 実践 | それが何をするか | それがなければ何が起こるか |
|---|---|---|
| 頻繁なコミット | 変更を小さく保つ | エラーが分離されにくくなる |
| 自動ビルド | コンパイルが一貫して動作することを確認します。 | ビルドの問題は遅く出現します。 |
| 自動テスト | レグレスションを早く検出します。 | チームは遅い手動チェックに頼っています。 |
| 迅速なフィードバック | 開発者が状況を維持する | バグは勢いが失われた後で修正されます。 |
CIを購入したツールとして扱うのが最大の誤解です。Jenkins、GitHub Actions、Bitrise、GitLab CI、CircleCIはすべてパイプラインを実行できますが、良い習慣を独自に作り出すことはできません。CIはチームが頻繁にコミットし、チェックが関連性があり、赤いビルドを急務として扱う場合にのみ効果を発揮します。
開発を加速するための基本的な技術的利点
CIのエンジニアリング価値は、配達の面倒な部分で現れます。待ち時間が減り、推測が減り、巨大なマージが減り、「私のマシンで動作する」という会話が減ります。CIをうまく取り入れたチームは、CIが面白いと説明するのではなく、落ち着かすと説明します。
最もよく引用される利点はリリース速度です。実証研究では、CIを使用するプロジェクト CI を code 2 倍の頻度でリリースします。 CI を実装していないプロジェクトと比較して、オープンソース リポジトリを調査した研究により、Hilton et al. の ICSE 論文で CI リリース結果を分析しました。 . これは重要な理由です。CI の頻度が高いのは、より健康的な統合習慣の結果であり、単にカレンダーがより積極的であることによるものではありません。迅速なフィードバックは開発者の行動を変える
迅速なフィードバックは開発者の行動を変える
これにより、コンテキスト Switching も減ります。__CAPGO_KEEP_0__ を書いた今日のあなたが今日のビルドが失敗した場合、問題が頭の中にまだロードされているときに修正できます。その方が、3 日後にブランチを再開し、コミット履歴から意図を再構築することよりもはるかに良いでしょう。
This also reduces context switching. If a build fails today for code you wrote today, you can fix it while the problem is still loaded in your head. That’s much better than reopening a branch three days later and trying to reconstruct intent from commit history.
小規模な統合は、隠れた作業を減らす CI を __CAPGO_KEEP_0__ 2 倍の頻度でリリースします。 CI を実装していないプロジェクトと比較して、オープンソース リポジトリを調査した研究により、Hilton et al. の ICSE 論文で CI リリース結果を分析しました。
小さな統合は隠された作業を減らします。
CIは、ビルドやテストを共有ブランチに強制することで、互いの仮定を破る2つの機能がコンパイルできるようにすることで、これらの衝突を早期に暴露します。
これは、以下の具体的な改善につながります:
- クリーンなプルリクエスト: レビューアは意図に焦点を当てることができ、掘り下げる必要がなくなります。
- 安全なリファクタリング: パイプラインは、構造的変更が下流のcodeを破壊するときに、即時フィードバックを提供します。
- テストの Disciplineが良くなります: コミットごとにテストが実行されるようになると、フラッキーテストや遅いテストは無視できなくなります。
- リリース日時のデバッグが減ります: チームは、最悪の時期に基本的な統合問題を発見するのをやめます。
多くのチームは、自動ビルドとリリース用の__CAPGO_KEEP_0__ Actionsを共有ワークフローに組み込むことで、これらの利点を実現します。 自動ビルドおよびリリースとGitHubアクションCIの実装方法は異なりますが、パターンは一貫しています。
小さなコミットは、レビューも信頼も容易です。
CIにはトレードオフもあります。設計が悪いパイプラインは遅く、雑音が多く、不安定になります。テストが失敗しても原因が関係ない場合は、開発者は気を取られます。長いパイプラインが毎回コミットをトリガーする場合は、チームは回避策を探します。CIはスピードについて意見を述べる必要があります。
CIとビジネス、製品の勝利の関係
エンジニアチームはCIを技術的な用語で説明しますが、製品やリーダーシップは異なる質問に興味があります。リスクを少なくしたり、何かが壊れたときに迅速に回復したり、納期を予測することができるかどうか。
CIはその質問に答えます。なぜならCIは問題を導入して発見するまでの時間のギャップを短縮するからです。
再作業が少ないことは、納品の摩擦を低下させる
TierPointがIBMの業界分析の要約をまとめたところによると、CIは 平均解決時間を by detecting errors within minutes of code submission, which lowers rework costs and reduces cloud infrastructure total cost of ownership in the CI の継続的実行の利点の概要. そのビジネスケースは一行で表すことができます。 earlier の検出は、より安い修正につながります。
製品マネージャーは、予測可能性を感じます。 予測可能性により、スプリントを緊急のクリーンアップに失う可能性が低くなります。 サポートは、チームが何が変更されたかを特定して、より速く対応できるため、明確なインシデントハンドリングを感じます。 財務は、リリース問題が長期的なエンジニアリング中断に変化することなく、より少ないリリース問題を感じます。
CI は、リリースの感情的コストを減らすこともあります。 チームがパイプラインに信頼を置く場合、毎回のリリースは賭けのように感じられないため、より良い決定を下すことができます。
予測可能性は、製品がより良い賭けを下すのに役立ちます。
予測可能な配信システムは、ロードマップの行動を変えます。 製品は、配信が痛みなくなるため、作業を小さなインクレメントに分割できます。 エンジニアリングは、リスクの高いバンドリングに反対できます。 組織は、月次イベントのために変更を保存する必要がなくなりました。 ステークホルダーは、段階的なリリース、パッチリリース、または急いでリバースすることを要求できますが、パニックを引き起こすことはありません。
成長チームにとって、これはコアエンジニアリングの外側でも重要です。 マーケティングとプラットフォームチームは、ウェブサイト、オンボーディング、リリースの迅速な反復が必要です。 配布速度が重要な場合、同様の思考方法は、隣接するワークフロー、たとえばチームが 高権威のバックリンクを得るために、繰り返し実行可能で追跡可能な実行を実行するのではなく、ワンオフキャンペーンを実行することです。 短いビデオは、このオペレーショナルディスコースが配信結果にどのように影響するかを簡潔に説明しています:
CI のビジネス利点は、速度だけではありません。 リリースごとに起こる驚きの数が少なくなります。
CI は、リリースの感情的コストを減らすこともあります。 チームがパイプラインに信頼を置く場合、毎回のリリースは賭けのように感じられないため、より良い決定を下すことができます。
CIは、最初の投資のトレードオフです。 チームはテストを書き、ビルドスクリプトを維持、フラッキーチェックを管理し、品質ゲートについて同意する必要があります。 それらはすべて無料ではありません。 しかし、代わりに、締切のプレッシャー、インシデント対応、またはユーザーが問題を感じた後、同じコストを支払うことになります。 ほとんどの成熟したチームは、信頼性の高いシステムを設計することに労力を費やす方が、繰り返し改造する方が得意です。
理論から実践へ Webの展開以外のこと
CIは、Webチームにとって主なボトルネック解決策とみなされることがよくあります。 ビルド、テスト、展開、監視、完了。 しかし、モバイルチームは、それが不完全であることを知っています。 DisciplineされたCIパイプラインを構築しても、ユーザーが今必要な変更に対してアプリストアのレビューでブロックされる可能性があります。
That’s why the benefits of continuous integration look different on mobile. CI still improves code health and release quality, but the final leg of delivery has extra constraints.
https://__CAPGO_KEEP_0__.app からスクリーンショット
モバイルCIの実現例
- モバイルCIワークフローは、Webのみのパイプラインよりも多くの要素が動作しています。 共有ソース管理:
- 全員が同じリポジトリとブランチ戦略を通じて統合します。 自動ビルド:
- パイプラインは、iOSとAndroidのアーティファクトを一貫して生成します。 各変更ごとに、単体テスト、linting、ターゲットされた統合チェックが実行されます。
- 署名およびパッケージングの制御: 機密のリリースステップは、検査され、繰り返し実行されるスクリプトです。
- リリースチャンネル規則: チームは、ベータ、ステージング、プロダクションのパスを分離します。
多くの組織はここで止まりますが、それでも手動リリースよりも改善されています。チームが Capacitor を使用している場合、実用的な Capacitor アプリの CI/CD 設定のメカニズムの参考資料は Capacitor アプリの CI/CD 設定の設定。抽象的な CI の議論の際にしばしば省略される運用側の側面をカバーしています。
アプリストアのボトルネック CI alone で解決しません。
モバイル配信には、ウェブチームが通常直面しない構造的遅延があります。DevOps.com によると、 72% のモバイルチームは 3 から 7 日間のレビューのボトルネックに直面しています。CI をアセットのホットアップデートサービスと組み合わせたチームは 50%のユーザー向け修正が速くなる native CI Pipelinesのみに頼っているチームよりも CIリテラチャーの95%はこのワークフローを未解決としている分析 CIの重要性が今よりも大きい理由.
このギャップは重要な理由です。JavaScriptのロジックを修正したり、コピーを更新したり、設定を調整したり、バンドルされたWebアセットを修正したりするCapacitorアプリでは、ネイティブストアのレビューのパスがプロセスの最も遅い部分になる可能性があります。
ネイティブチームにとっての核心的な質問は、ストアを通じて変更する必要があるものと、安全に別の承認されたパスで配信できるものの区別が必要になります。
Live Updateの役割
live updateサービスはハイブリッドモバイルアプリのCIループを完了します。CIは基本的な作業を引き続き行います。ビルド、テスト、検証、バンドルを生成します。live updateシステムは、ネイティブバイナリのレビューを待たずに、エラブルなWebアセットを直接デバイスに配信します。
このカテゴリの1つのオプションは Capgo、Capacitorアプリ用に署名されたWebバンドルを公開し、ロールアウトチャンネルをサポートし、CI/CDと統合して、チームがJavaScript、CSS、コピー、設定、類似の非ネイティブ変更のアセット配信を自動化できるようにします。その代わりにネイティブリリースを置き換えるのではなく、ストアの提出が必要な変更を絞り込むだけです。
実践的なパターンは次のようになります。
- 開発者は小さな変更をメインブランチにマージします。
- CIはビルドと自動チェックを実行します。
- 変更がネイティブcodeに影響を与える場合、チームは通常のアプリストアパスを通して配信します。
- 変更がウェブアセットに限定されている場合、パイプラインは適切なチャンネルにアップデートを公開します。
- チームは採用、失敗、ロールバック信号を監視します。
フィールドノート: モバイルCIは、
needs a binary
needs users to get the fix
の区別ができる場合にのみ、より有用になります。
その区別が、配信が継続的であると感じられるのではなく、単に自動化されていると感じられるのを避けるのです。そうでない場合、モバイルチームは統合品質を向上させますが、まだ顧客向けのすべての意味のある修正に対してレビュー遅延を吸収します。そうでない場合、パイプラインは製品とサポートが必要とするペースに合うようになります。
配信の健康を示すメトリックを追跡する
| メトリック | 何を測定するか | なぜ重要か |
|---|---|---|
| デプロイ頻度 | チームが成功したリリースを何回行うか | 配信が定期的なものか、バッチベースのものかを示す |
| 変更のリードタイム | コミットが生産環境に到達するまでにどれくらいの時間がかかるか | レビュー、テスト、承認、リリースハンドリングの遅延を明らかにする |
| 変更失敗率 | リリースの頻度によるサービス低下の度合い | 速度と品質の結びつきを維持する |
| 復旧までの時間 | インシデント後の復旧にかかる時間 | 運用の耐性とリリースの安全性を表す |
CIの場合、パフォーマンスフィードバックという実用的な視点を追加する。Abstractaによると、CIパイプラインはパフォーマンスベンチマークを早期に有効化し、codeの変更後すぐにパフォーマンスの偏差を検出し、開発者がコンテキストを切り替える回数を減らし、同じスプリントで問題を解決できるため、パフォーマンスチェックはリリース前のみのQAではなく、配信の健康状態の一部として扱うべきである。
小さなステップから始め、パイプラインを有効化する
すべてを自動化するのではなく、始めにチームがすでに嫌がっている一つの痛い手動ステップを削除する
良い開始シーケンスは通常
- サービスまたはアプリケーションを選択する 開発が活発で、リリースの痛みが見えるプロジェクトを選択する
- まずビルドを自動化する 環境が繰り返し可能な場合、毎回のコミットが同じ結果を生み出すようにします。
- 小さなテストスイートを追加します。 まず、明らかなバグを検出するための高速チェックから始めます。
- メインブランチを保護します。 共有 code に破損した変更を流入させないようにします。
- 基準値を測定します。 現在のリリースサイクル、リストア時間、失敗パターンを追跡し、改善についての主張を立てる前に、改善の前提となる基準を確立します。
- パイプラインの信頼性に関する問題を迅速に解決します。 フラッキーチェックは、チェックが欠けている場合よりも、採用を早く殺すことになります。
モバイルパイプラインが基本的なCIが実装された後でも遅いと感じる場合は、問題はビルド自体ではなく、外部にある可能性があります。このガイド CI/CDのボトルネック OTAパイプラインの一般的なCI/CDボトルネックについてのガイド
CIは成熟度のマークではありません。 それは、チームが変更を小さく、フィードバックを速く、リリースパスの誠実さを保つことで、継続的インテグレーションの利点を受けることができます。
IfチームがCapacitorアプリを配信し、CIをユーザーに迅速に到達させたい場合、 Capgo は、ビルド検証を超えて、非ネイティブ変更の制御されたライブアップデートを拡張する方法です。 それは、署名バンドル配信、ロールアウトチャネル、ロールバックコントロール、リリース可視性を必要とするチームに適していますが、アプリストアレビューをすべての修正を通す必要はありません。
