リリース日はよく似たものを見ることが多い。CIログを監視している人がいるし、署名ステップがまだ機能しているかどうか確認している人がいるし、開発者は最後のミニマムマージコンフリクトを解決しようとしているし、製品はバグ修正が今日のビルドに含まれるかどうか尋ねている。モバイルアプリを配信している場合、さらに1層の不安定さが加わる。codeが用意された後でも、ユーザーが修正を確認するまでの時間が数日かかる可能性がある。
そのリリースパターンはスケーラブルではない。エンジニアリング時間を浪費し、計画の信頼性を損ない、そして小さな変更を高リスクのイベントに変える。より多くの英雄的行為は必要ではなく、問題を早期に検出し、メインブランチを健康に保ち、コミットから顧客への影響までの間に起こり得る驚きを減らす配信システムが必要である。
その時、継続的インテグレーションの利点が実践的なものになる。CIは単に自動化のために自動化することだけではなく、チームが毎日どのように働くかを変える。モバイルチームにとって、非ネイティブ変更のlive updateパスと組み合わせると、より価値のあるものになる。
目次
- なぜチームは手動リリースから脱却する必要があるか
- 継続的インテグレーションとは何であるか
- 開発を加速する技術的な主な利点
- CIはビジネスと製品の勝利にどのように翻訳されるか
- 理論から実践へ、Webの展開以外のCI
- CIの旅を始めるための測定と開始
チームがマニュアルリリースから脱出する必要がある理由
手動リリースは、2 つの種類のダメージを生み出します。目に見えるダメージは、深夜のスクラム、共有ドキュメント内のチェックリスト、リリースマネージャーがホットフィックスを含むブランチを思い出すことです。目に見えないダメージは、チーム全体がその痛みに適応することです。開発者は変更を長く保留し、製品は各リリースに多くの作業を組み込むことになります。QAは大きい差分と確実性の低さを感じます。
モバイルチームはこのことをさらに感じます。Webデプロイが破損すると、通常は早く修正できます。ネイティブモバイルリリースが破損すると、サポート、製品、エンジニアはレビューキューに待ち、タイムラインを完全に制御できないことを説明するのに時間を費やします。そのため、リリースプロセス設計はcode品質と同等の重要性があります。
手動リリースは、shippingを遅らせるだけでなく、チームをshippingを恐れるように訓練します。
継続的インテグレーションは、開発者が小さな変更を頻繁にマージする常習化された習慣に変える別の運用モデルを提供します。システムはアプリケーションをビルドし、テストを実行し、チームに迅速に問題が生じたことを伝えます。問題は小さくなるのは、変更が小さいからです。
これにより、リリースに関する会話も変わります。製品は「今すぐどれがリリースできるか」と尋ねることができます。サポートは明確な答えを得ることができます。エンジニアは、変更が何だったかを再構築する時間を減らし、どれをリリースするかを決定する時間を増やすことができます。
モバイルチームが古いワークフローとより現代的なワークフローを比較する場合、このトレードオフは、OTA更新と手動のストアへの提出を対比することで明らかになります。 OTA更新と手動のストアへの提出を比較する。。ポイントはプロセスを削除することではありません。リリース日を主な品質管理機構として使用するのを止めることです。
リリースの痛みは通常、プロセスを遅らせることができます。
- 大量のバッチサイズ: codeが大量に到着するため、障害を特定するのは難しくなります。
- 遅い統合: チームは、締切がすでに厳しいときに、紛争を発見します。
- 人間による検証のみ: 人々は一部の問題を発見しますが、自動チェックの一貫性と一致するものではありません。
- 遅れた回復: 簡単な修正でも、リスクの高いリリースイベントに変わります。
CIは、各の失敗モードに直接対処することで機能する。
CIとは何ですか?
多くの人が協力して大きなLegoセットを組み立てることを考えましょう。1つのオプションは、各人が数日間で大きなセクションを組み立ててから、最後にそれらを強制的に組み合わせることです。その場合、通常、ソフトウェアの統合が失敗するのと同じように失敗します。パーツが揃いません。誰かが間違ったパーツを使いました。誰も、間違いがいつ発生したかを知りません。
CIの方法は異なります。各人が頻繁に小さなパーツを追加し、モデルが成長するにつれて常にチェックを実行します。ビルドは安定しているため、各追加は確認される前に次のものが上に積み重ねられます。
コアループ
実際のレベルでは、CIは繰り返しループです。
- 開発者が共有リポジトリに小さな変更をプッシュします。
- pipelineがアプリケーションをビルドします。
- 自動テストがその変更に対して実行されます。
- チームが迅速にフィードバックを受けます。
- チェックが通過した場合、codeはメインブランチに統合されることが安全です。
That loop sounds simple, but it changes team behavior in important ways. Developers stop sitting on long-lived branches. Reviewers get smaller pull requests. Failures are easier to trace because the amount of changed code is limited. Teams start treating the main branch as something they actively protect, not something they repair after the fact.
CIとCDの境界
ここではチームが混乱することが多い。
継続的インテグレーション 継続的インテグレーションは、codeを頻繁にマージし、自動で検証することです。
継続的デリバリー 検証済みのソフトウェアは常にリリース可能な状態にあることを意味します。
継続的デプロイ これは、合格した変更を自動でユーザーに配信することです。
CIをすべてのDevOpsの短縮形として使用すると混乱が生じることが多い。
計画が粗雑になる。 継続的デプロイとは実際に何を意味するのか は便利である。なぜなら、code検証と実際の配信決定を分離するからだ。
実践のルール: 開発者がメインブランチに信頼を置いていない場合、CIシステムは存在するかもしれないが、CI実践は存在しない。
CIの堅固なセットアップには、以下の重要なコンポーネントが含まれることが多い。
| 実践 | それが何をするか | それが何もしない場合 |
|---|---|---|
| 頻繁なコミット | 変更を小さく保つ | エラーが分離しにくくなる |
| 自動ビルド | アプリケーションがコンパイルできることを確認する | 遅いバグが現れる |
| 自動テスト | バグの再現が早く発見される | チームは遅い手動チェックに頼っている |
| 迅速なフィードバック | 開発者が状況を維持している | バグは勢いが失われた後で修正される |
CIを購入したと考えるのが最大の誤解だ。Jenkins、GitHub Actions、Bitrise、GitLab CI、CircleCIはすべてパイプラインを実行できるが、どれも良い習慣を生み出すことはできない。CIはチームが頻繁にコミットし、チェックが関連性があり、赤いビルドを急いでいる場合にのみ機能する。
開発を加速する技術的な核の利点
CIのエンジニアリング価値は、配達の面倒な部分で現れる。待つ時間が減り、推測が減り、巨大なマージが減り、「私のマシンで動く」という会話が減る。CIをうまく取り入れたチームは、CIが面白いと説明するのではなく、落ち着かすと説明することが多い。
最もよく引用される利点はリリース速度だ。実証研究ではCIを使用しているプロジェクトが リリースをcode 2倍にする CIを実施しないプロジェクトの場合、Hilton et al.によるオープンソースリポジトリの研究によると、 ICSEの連続統合リリース結果に関する論文。 これは重要な理由です。 速いリリースのペースは、より健康的な統合習慣の結果であることが多く、単にカレンダーがより積極的であることだけではありません。
迅速なフィードバックは開発者の行動を変える
迅速なフィードバックは、チームが最初に感じる技術的な勝利です。 コミット後数分で失敗したテストは、複数の無関係な変更が到着した後で発見されたバグレポートよりもはるかに安価です。 開発者はまだ何が触れたかを覚えています。 レビュー者は diff について推論できます。 修正はローカルに残ります。
これにより、コンテキスト切り替えも減ります。 今日書いた code で今日のビルドが失敗した場合、問題が頭の中にまだロードされているときに修正できます。 これは、3日後にブランチを再開してコミット履歴から意図を再構築することよりもはるかに良いでしょう。
また、パフォーマンスも有益です。 CI Pipelines は、ライフサイクル初期に重要なフローをベンチマークすることもできます。 Abstracta によると、早期の連続パフォーマンステストは、チームが変更後にパフォーマンスの偏差を即座に検出し、コンテキスト切り替えを減らすことができます。 国際化されたアプリを開発しているチームは、ワークフローとして Django のローカライズテストを学ぶ を組み合わせて、自動化された検証がコンパイル成功のみをカバーするのではなく、より多くのことをカバーするようにすることができます。
小規模な統合は、隠れた作業を減らす
大きなマージコンフリクトは明らかです。隠れた統合作業は、リリース週まで見えなくなるため、より悪いことです。2つの機能は個別にコンパイルできても、それぞれの仮定を破る可能性があります。CIは、これらの衝突を早期に暴露するために、共有ブランチへの定期統合を強制します。
これは、以下の具体的な改善につながります:
- クリーンなプルリクエスト: レビューアは、意図を意識するのではなく、掘り下げるのではなく、意図を確認できます。
- より安全なリファクタリング: パイプラインは、構造的変更が下流のcodeを破る場合に、即時フィードバックを提供します。
- より良いテストの規律: コミットごとにテストが実行されるようになると、フラッキーテストや遅いテストは無視できなくなります。
- リリース日におけるデバッグの減少: チームは、最悪の時期に基本的な統合問題を発見するのをやめます。
多くのチームは、ビルド、テスト、アーティファクトの生成を共有ワークフローに組み込むことで、これらの利点を実現します。たとえば、自動ビルドとリリースと__CAPGO_KEEP_0__ Actionsを使用します。 自動ビルドとリリースをGitHubアクションで自動化CIの実装方法は異なりますが、パターンは一貫しています。
小さなコミットは、レビューだけでなく、信頼も容易になります。
CIにはトレードオフもあります。設計が悪いパイプラインは遅く、雑音が多く、不安定になります。テストが失敗しても、原因が関係のないものの場合、開発者は注意を払わなくなります。長いパイプラインが毎回コミットをトリガーする場合、チームは回避策を探します。良いCIはスピードについて意見を持っています。コアパスを速くし、重いチェックを適切なステージに押し付けて、パイプラインの信頼性を製品の品質の一部として扱います。
CIとビジネス、製品の勝利の関係
エンジニアリングチームはCIを技術的な用語で説明しますが、製品やリーダーシップは異なる質問に興味があります。リスクを少なくしてリリースできるか? 何かが壊れたときに迅速に回復できるか? 予定された納期に自信を持って計画できるか?
CIはその質問に答えます。なぜならCIは問題を導入してから発見するまでの時間のギャップを短縮するからです。
再作業が少ないことは、納品の摩擦が低下することを意味します。
TierPointがIBMの業界分析の要約をまとめたところによると、CIは 平均的な解決時間を CIは、codeの提出から数分以内にエラーを検出することで、 再作業コストを下げ、クラウドインフラの総コストを所有するコストを削減します。CIは、問題を早期に発見することで、修正のコストを削減することができます。
製品マネージャーは、予測可能性を感じます。スプリントを緊急のクリーンアップに失う可能性が低くなります。サポートは、チームが何が変わり、速く対応できるようになったため、明確なインシデントハンドリングを感じます。財務は、リリース問題が長期的なエンジニアリングの中断に変わり、費用が少なくなります。
CIは、リリースの感情的コストを減らすことにもつながります。パイプラインを信頼するチームは、毎回のリリースが賭けのように感じられないため、より良い決定を下すことができます。
予測可能性は、製品がより良い賭けを下すのに役立ちます。
予測可能な配信システムは、ロードマップの行動を変えることにもつながります。製品は、配信が痛みなくなるため、作業を小さなインクレメントに分割できます。エンジニアは、リスクのあるバンドリングに反対できます。組織は、毎月のイベントに変更を保存する必要がなくなります。ステークホルダーは、段階的なリリース、パッチリリース、または急いで逆転することを要求できますが、パニックを引き起こすことはありません。
成長チームにとって、これはコアエンジニアリングの外でも重要です。マーケティングとプラットフォームチームは、ウェブサイト、オンボーディング、リリースの迅速な反復が必要です。配信速度が重要な場合、隣接するワークフローでも同じ考え方が適用されます。たとえば、繰り返し実行可能で追跡可能な実行方法で、1回のキャンペーンではなく、高権威のバックリンクを獲得することです。 短いビデオでは、このオペレーショナルディスコースが配信結果にどのように影響するかを簡単に理解できます。 CIのビジネス利点は、単に速さだけではありません。リリースごとに起こる驚きの数を減らすことです。
CIは、問題を早期に発見することで、修正のコストを削減することができます。
CIのビジネス上の利点は、速さだけではない。
投資とトレードオフ
理論から実践へ
Webデプロイメントを超えて
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.
CIはアプリの健康性とリリースの品質を向上させる
モバイルCIの最終段階には制約が加わる
- https://__CAPGO_KEEP_0__.app モバイルCIの実現
- モバイルCIのワークフローには多くの要素が含まれる 共有ソース管理
- すべてのメンバーが同じリポジトリとブランチ戦略を通じて統合することになることが多い 各変更ごとに、単体テスト、リンティング、ターゲットされた統合チェックが実行されます。
- 署名およびパッケージングの制御: 重要なリリースステップはスクリプト化、監査、繰り返し実行されます。
- リリースチャンネル規則: チームはベータ、ステージング、プロダクションのパスを分離します。
多くの組織はここで止まりますが、それでも手動リリースよりも改善されています。チームが Capacitor を使用している場合、実用的な Capacitor アプリの CI/CD 設定の参考資料は Capacitor アプリの CI/CD 設定の設定。
アプリストアのボトルネック CI alone で解決しません。
モバイル配信には、ウェブチームが通常直面しない構造的遅延があります。DevOps.com によると、 72% のモバイルチームは 3 から 7 日間のレビューのボトルネックに直面しています。CI とアセットのホットアップデートサービスを組み合わせたチームは 50%のユーザー向け修正が速くなる ネイティブのCIパイプラインのみに頼っているチームよりも CIリテラチャーの95%がこのワークフローを未解決としている分析 CIが今やりがいを増している理由.
そのギャップは重要な理由です。JavaScriptのロジックを修正したり、コピーを更新したり、設定を調整したり、バンドルされたウェブアセットを修正したりするCapacitorアプリでは、ネイティブストアのレビューのパスがプロセスの最も遅い部分になる可能性があります。エンジニアリングの変更自体がリスクが低い場合でも。
したがって、モバイルチームにとっての核心的な質問は、次のようになります:ストアを通じて変更する必要があるものと、安全に別の承認されたパスで配信できるものとは何か?
Live Updateの位置づけ
live updateサービスは、ハイブリッドモバイルアプリのCIループを完了します。CIは基本的な作業を引き続き行います。ビルド、テスト、検証、バンドルを生成します。live updateシステムは、最新のネイティブバイナリのレビューを待たずに、エラブルなウェブアセットを直接デバイスに配信します。
このカテゴリのオプションの1つは Capgo、Capacitorアプリ向けに署名されたウェブバンドルを公開し、ロールアウトチャンネルをサポートし、CI/CDと統合して、チームがJavaScript、CSS、コピー、設定、類似の非ネイティブ変更の自動化されたアセット配信を実行できるようにします。その代わりにネイティブのリリースを置き換えるのではなく、ストアの提出が必要な変更に絞り込むのを狭めます。
実践的なパターンは次のようになります。
- 開発者は小さな変更をメインブランチにマージします。
- CIはビルドと自動チェックを実行します。
- 変更がネイティブ codeに影響を与える場合、チームは通常のアプリストアパスを通して配信します。
- 変更がウェブアセットに限定されている場合、パイプラインは適切なチャンネルにアップデートを公開します。
- チームは採用、失敗、ロールバック信号を監視します。
フィールドノート: モバイルCIは、
needs a binary
と
needs users to get the fix
の区別ができる場合にのみ、より有用になります。
リリースの健康を示すメトリックを追跡する
| メトリック | 何を測定するか | なぜ重要か |
|---|---|---|
| デプロイの頻度 | チームが成功裏にリリースする頻度 | リリースが定期的なものか、バッチベースのものかを示す |
| 変更のリードタイム | コミットが生産環境に到達するまでに要する時間 | レビュー、テスト、承認、リリースの処理の遅延を明らかにする |
| 変更の失敗率 | リリースの頻度によるサービス低下の度合い | 速度と品質の結びつきを維持する |
| 復旧までの時間 | インシデント後の復旧にかかる時間 | 運用の耐性とリリースの安全性を反映する |
CIの場合、パフォーマンスフィードバックという実用的な視点を追加する。Abstractaによると、CIパイプラインは、パフォーマンスベンチマークを早期に有効化し、codeの変更後すぐにパフォーマンスの偏差を検出し、開発者がコンテキストを切り替える回数を減らし、同じスプリントで問題を解決できるため、パフォーマンスチェックを配信ヘルスの一部として扱うべきであると述べている。
小さなステップから始め、パイプラインを有用にし
すべてを自動化するのではなく、始めにチームがすでに嫌がっている一つの痛い手動ステップを削除する
良いスターティングシーケンスは通常
- サービスまたはアプリケーションを選択する 開発が活発で、リリースの痛みが見えるプロジェクトを選択する
- まずビルドを自動化する 毎回のコミットが繰り返し実行可能な環境で同じ結果を生み出すようにします。
- 小さなテストスイートを追加します。 まず、明らかなバグを検出するための高速チェックから始めます。
- メインブランチを保護します。 共有 code に破損した変更を許可しないようにします。
- 基準値を測定します。 現在のリリースサイクル、リターンタイム、失敗パターンを追跡し、改善についての主張を立てる前に、改善の基準を設定します。
- パイプラインの信頼性に関する問題を迅速に解決します。 フラッキーチェックは、チェックが欠けていることよりも採用を遅らせることの方が速くなるため、チェックが欠けていることよりもフラッキーチェックの方が問題です。
モバイルパイプラインが基本的なCIが実装された後でも遅いと感じる場合は、問題はビルド自体ではなく、ビルド外にある可能性があります。このガイドは CI/CDのボトルネック OTAパイプラインの一般的なCI/CDボトルネックについてのガイドです。このガイドは、ボトルネックが統合から配信オーケストレーションにシフトした場合に役立ちます。
CIは成熟度のマークではありません。 それは、チームが変更を小さく、フィードバックを速く、リリースパスの不正確さを正すことで、継続的な統合の利益を得ることができるdisciplineです。
チームがCapacitorアプリをリリースし、CIをユーザーに迅速に到達させたい場合 Capgo 継続的な統合を実現するには、チームが変更を小さくし、フィードバックを速くし、リリースパスの不正確さを正すことが必要です。
