CI/CD統合とは、code リポジトリを自動化されたパイプラインに接続するためのワイヤングです。変更がビルド、テスト、リリースステージを通過するのを手動で行うことなく、すべての変更が進行します。2024年までに 83%の開発者 DevOps関連の活動に携わった場合、CI/CDツールの使用は、展開頻度、リードタイム、変更失敗率、サービス復旧までの時間のすべての分野で、より良い配信パフォーマンスと関連付けられます。 Cloud Native Computing FoundationのCI/CDレポートによると.
モバイルチームを率いている場合、確かに「ビルドが成功した」と「アプリが安全に配信できる」という間違いを感じたことがあるでしょう。Slackではリリースが見栄えが良く見えるとき、11時までに誰かが正しい署名キー、正しいブランチ、正しいストアチェックリスト、正しいロールバックパスが必要になることがあります。その時点でCI/CD統合は単なるブランドから、チームがアプリを配信するためのオペレーティングシステムに変わります。
目次
- 誰もが忘れたいリリースの日
- CIとCDを分解する
- CI/CDパイプラインの解剖学
- CI/CDとモバイルアプリ、デスクトップアプリの違い
- 統合を実現するための基本コンポーネント
- セキュリティとコンプライアンスがパイプラインに組み込まれている
- リリース後、トラブルシューティングとオブザーバビリティ
- CI/CD ジョーンリーの次のステップ
誰もが忘れたリリースの日
火曜日の朝、簡単なホットフィックスが始まりました。金曜日の夜までに同じパッチはまだブランチに座っています。マニュアルQAが1つもう1つの問題を発見し、リリースノートは半分完成し、3人の人がSlackで最新のビルドを持っている人を尋ねています。オンコールエンジニアは午後11時にリリーススクリプトを再実行し、誰も完全に確かめていないのは、ステージングのアーティファクトがソースコントロールのものと一致しているかどうかです。
CI/CD統合はそのような混乱を完全に排除することを目的としています。目的は単にタスクを自動化することだけではありません。ソースコントロール、ビルドサーバー、テストランナー、アーティファクトストア、そしてデプロイターグループを1つのフローに接続することです。そうすれば、毎回のコミットは独自の流れで進むことができます。 ソースコントロール, ビルドサーバー, テストランナー, アーティファクトストアデプロイターグループ Red HatによるCI/CDの概要 CI/CDの概要 CI/CD統合 自動化の DevOps ワークフローを説明する。これには、ビルド、テスト、スキャン、パッケージング、プロモーション、デプロイなどが含まれます。
ワイヤリングが欠けているときに何が壊れるか
CI/CDを単一のツールとして扱うと、通常は部分的な自動化とリスキーなハンドオフが残ります。Codeがマージされるが、誰かがビルドを開始する必要があります。ビルドが完了したが、誰かがアーティファクトをコピーする必要があります。ステージング リリースが正常に動作するが、生産には異なるスクリプト、異なるクレデンシャル、そして誰かが全体がどのように機能するかを覚えている人を必要とします。
実践的なルール: リリースが記憶、サイド チャット、または「スクリプトを知っている人」に依存している場合、パイプラインはまだ統合されていません。
Cloud Native Computing Foundation の 2024 年のレポートも、同じ種類の複数のツールを使用すると、相互運用性が悪くなるため、配信パフォーマンスが損なわれることを警告しています。 CI/CD の現状それは、大規模なチームでは重要です。統合は、より多くのツールを所有することではなく、同じ真実の源に同意することを意味します。
健全な CI/CD 設定では、コミットからユーザーまでの 1 つのパスが得られます。弱いものでは、各自が独自の手動橋を持つ島々の集合体が得られます。差はリリース日に出現し、チームが混乱を最も恐れるときに最も出現します。
CI と CD を分解する
リリースワークフローは、アイデアを分離することで、より論理的に考えられるようになります。 CI 自動的に頻繁に小さな変更をマージし、確認します。 CD 検証済みのcodeをリリース用に準備し、人工の承認ステップを含むか除くか、生産にそのcodeを決定します。
CIは準備室です
継続的インテグレーションは、簡単な習慣から始まります。変更を小さくし、すぐに検証することです。ソフトウェアでは、コミットまたはマージリクエストごとに自動チェックがトリガーされ、破損したcodeが大きなリリースで暴露されるのを待つのではなく、直ちに検出されます。その理由は、繁忙なキッチンでは食材を整理し、サービス開始前にチェックするのと同じです。ただし、ここでは「準備」はビルドとテストの自動化ではなく、切った野菜ではありません。
定義はRed HatのCI/CDガイドから CIは、自動ビルドとテストの分野です。 CI/CDガイド
CIは、早期に統合問題を検出する自動ビルドとテストの分野です。小さな変更は容易に検証でき、問題が発生した場合、チームは問題の原因となるリリースの部分を推測することなく、問題を追跡できます。
CDには2つの意味があり、チームは混同しています。継続的デリバリーは、codeが常に展開可能ですが、生産が行われるのは人によって決まります。継続的デプロイはさらに進んで、自動的にすべてのパッシング変更を展開します。その区別は、法的要件、リスク耐性、通常必要なリリース制御の種類、モバイルとデスクトップチームに影響を与えます。
消費者向けアプリのリリースマネージャーは、店舗のタイミングの調整が必要なため、継続的な配信を好むかもしれません。リスクが低いサービス向けの自動チェックが強いバックエンドチームは、継続的な展開を選択するかもしれません。正しい選択は、スローガンではなく、統治によって決まります。
CI側を強化するためにリリースを自動化する前に試みているチーム向けに このCIに焦点を当てたガイド は、リリースの信頼性の始まりである統合の品質に焦点を当てて、有用な相棒です。
| Web、モバイル、デスクトップのCI/CD ステージの比較 | Webアプリ | CapacitorJSモバイル | Electronデスクトップ |
|---|---|---|---|
| トリガー | プッシュまたはマージリクエストが検証を開始 | プッシュまたはマージリクエストが検証を開始 | プッシュまたはマージリクエストが検証を開始 |
| ビルド | アプリケーションをバンドル | ウェブのcodeをバンドルし、ネイティブシェルで包む | メインとレンダラーのcodeをコンパイルし、デスクトップアプリをパッケージ化 |
| テスト | ユニット、統合、UIテスト | モバイル用のチェックを追加 (ラッパーと実行時動作) | パッケージングとアプリ起動パス用のデスクトップ用チェックを追加 |
| リリース | ホスティングまたはアプリ実行環境にデプロイ | ストアチャネルまたはライブアップデートチャネルに公開 | インストーラまたはライブアップデートチャネルに公開 |
| 承認 | オプションの人間ゲート | ストアとロールバック制御のためによく必要 | 署名と配布制御のためによく必要 |
CI/CD Pipelinesの解剖学
パイプラインは、入力と出力を持つジョブのグラフです。開発者がcodeをプッシュすると、ウェブホックまたはマージイベントが最初のジョブをトリガーし、次のジョブが前のステージからアーティファクトを消費し、リリースが完了するまで続きます。そのため、CI/CD統合は実際にはステージ間の契約であり、不思議なプラットフォーム機能ではありません。
各ステージが何をしているか
ソースコントロールトリガーが流れを開始します。ビルドジョブはcodeをコンパイルし、依存関係を解決します。これが隠れた破損の多くが発生する場所です。テストジョブはユニット、統合、UIチェックを実行し、セキュリティスキャンは脆弱なパッケージや安全でない構成を検索します。
良いパイプラインは早く失敗し、失敗した場所を正確に教えてくれます。
次に、パッケージングは検証された出力を展開可能なものに変換します。たとえば、コンテナイメージ、署名されたAPKまたはIPA、Electron配布可能なもの、またはJavaScriptバンドルなど。 HCL CI/CD採用と実装の概要 はここで役立ちます。チームがパーシャル自動化に止まるのを示しています。多くのチームはpipelineを持っていますが、すべてのステージは完全に接続されていません。
ステージ境界の重要性
ハンドオフの各段階でアーティファクトを名前できなければ、デバッグは推測に頼ることになります。ステージングでリリースが失敗した場合、依存関係の解決、フラッキーテスト、セキュリティポリシー、パッケージングのいずれから問題が生じたかを知る必要があります。そのため、コミットからアーティファクトまで環境まで内部トレースが含まれる良いpipeline設計が必要です。
ビルド部分がより大きなフローにどのようにフィットするかを実践的な視点で見たいチーム向けの ビルドに焦点を当てたガイド ビルドステージが所有するものとリリースオーケストレーションが所有するものを区別するのに役立ちます。
CI/CDとモバイルアプリ、デスクトップアプリの違い
Web pipelineはCI/CDが主にサーバーにバンドルをプッシュすることだけに考えさせてしまいます。 CapacitorJS, you still build web code, but you also package it into a native shell, then manage signing and platform-specific release paths. With Electronでは、デスクトップ環境用にアプリケーションをコンパイルし、サポートするオペレーティングシステム用のインストーラーやディストリビューションを作成します。
What changes once the app ships to devices
モバイルチームは署名キー、App StoreおよびPlay Storeのレビュー、実行時更新チャンネルについて考える必要があります。デスクトップチームはインストーラー、code署名、およびプラットフォーム間で更新動作について考える必要があります。共通のパターンは明らかですが、codeは同じリポジトリとビルドトリガーを通じて移動するかもしれませんが、リリースサーフェイスは異なります。
The GitHubのCI/CDパイプラインの向上に関するガイダンス は段階的なテスト、機能フラグ、ロールバックチェックポイントを指し、この世界ではよく当てはまります。そうした慣行は、ビルドがインストーラーやパッケージのラッパー内に存在する場合に特に重要です。なぜなら、リリースは単に「codeがコンパイルされるかどうか」ではなく、「このパッケージは実機上で安全に動作するかどうか」であるからです。
What mobile and desktop teams add on top
Webリリースはしばしばステージングまたはプロダクションへのデプロイで止まることがあります。モバイルリリースには通常、チャンネル、承認、およびロールバック動作の追加層が必要です。Electronチームには同じ規律が必要ですが、デスクトップパッケージングと更新配布代わりにアプリストアの提出が必要です。
- CapacitorJS mobile: Webバンドル、ネイティブラッパー、署名、ストアレビュー、およびライブ更新チャンネル
- Electron desktop: メインプロセスビルド、レンダラー ビルド、パッケージされたインストーラー、署名、および更新チャンネル制御
- Web app: ビルド、テスト、パッケージ、展開、監視
そのギャップは、CI/CDにライブアップデートシステムを組み込むのではなく、サイドプロジェクトとしてのライブアップデートシステムの場所です。ビルドがバンドルを生成できる場合、リリースシステムは、ユーザーに安全に到達する方法を決定する必要があります。
統合を実現するための基本コンポーネント
トリガー、パイプライン、アーティファクト、環境は、チームが再びハードウェイを学習する4つの部分です。トリガーは、通常、Gitプッシュまたはマージリクエストのイベントです。パイプラインは、順序付きのジョブのセットです。アーティファクトは、検証済みの出力です。環境は、その出力が昇格または遅延される場所です。
4つの部分を簡単に説明します
トリガーは、Gitと自動化のハンドシェイクです。パイプラインは、ルールを定義します。ビルドから始め、テスト、スキャン、パッケージ、リリースの順序です。アーティファクトは、その作業の結果を前方に運びます。そのため、同じバンドルがテストされ、展開される必要があります。
環境は、意図と影響を分離する安全な場所を提供します。Dev、Staging、Beta、Productionは、実際の作業を行っています。チームは、1つの場所で変更を証明することができ、ユーザーがそれを依存する別の場所ではありません。
ルールの thumb: コミットとアーティファクトに遡って追跡できない環境は、リスクではなく、安全ネットではありません。
Capgo はライブアップデートフローにどのようにフィットするか
CapacitorJSとElectronアプリ用に、Capgoはライブアップデート層に位置し、署名されたウェブパッケージをチャネルに公開できるようになり、更新は差分化され、ロールバックはデバイスを最後の知られている良好なパッケージに戻すことができるようになります。これにより、パイプラインは単なるバイナリリリースパスではなく、ネイティブアプリ内にあります。ウェブアセットのリリースコントロールプレーンになります。
Capgoのパイプライン統合は、GitHubアクション、GitLab CI/CD、Azure DevOps、Bitbucket Pipelinesなどのシステムのドキュメント化されており、CIからチャネルベースのリリースに自動化されたビルドとデプロイフローを使用します。リリースツールを比較する場合、ジョブリストやプラットフォームの期待と比較すると、シニアチームはエンジニアがエンドツーエンドの統合について論理的に考えられるのではなく、ビルドスクリプトだけを理解する必要があると考えることがよくあります。実際の組織でリリースのパイプラインがどれだけ重要かを反映しているのは、Coinbaseのブロックチェーンジョブのソフトウェアエンジニア統合ロールです。 シークレットのハンドリング用に__CAPGO_KEEP_0__のCI/CDパイプライン内でのシークレットの管理についてのガイダンス
は環境の部分をより抽象化したものではなく、重要なのはフロー、自動化されたビルド、署名されたパッケージ、ターゲットされたチャネル、制御されたプロモーションです。 Capgo’s guidance on managing secrets in CI/CD pipelines セキュリティはCI/CDのコントロール問題であり、チェックボックスではありません。CI/CD環境の米国防衛ガイドでは、パイプラインを保護されたパスとして扱い、リポジトリ、ビルドシステム、クレデンシャル、アーティファクトルートをエンドツーエンドでセキュリティを確保する必要があります。
__CAPGO_KEEP_1__
__CAPGO_KEEP_0__ CI/CD環境の防御に関するガイドライン. そのフレーミングは、製品チームにとっても有益です。信頼できるパイプラインは、最速のパイプラインです。
フローの内側にあるコントロール
短期間の資格情報は、トークンが漏洩した場合の被害を軽減します。署名されたアーティファクトは、期待どおりのパイプラインからアーティファクトまたはバイナリが来ていることを証明します。SBOMとSCAチェックは、リリース前に依存性のリスクを露呈し、レビュアーが何が変更されたか誰が承認したかを追跡できるようにするAuditログを使用します。
The CI/CDパイプラインの防御に関するCISAとDHSのガイドライン セキュリティスキャン、ログ、署名された構成、クレデンシャルライフタイムの短縮は、パイプライン自体に含まれるべきです。 これは、金融、医療、電子商取引などの規制チームにとって正しい認識です。 合格性は、事後で追加するのではなく、リリースパスの一部です。
リリースは、セキュリティが追加された後でも速くなければなりません
チームは通常、パニックに陥り、手動ゲートの山を想像します。 これは必要ありません。 ポリシーはパイプラインに住み、承認は適切な環境に制限され、スキャンは自動的に実行され、リリースを会議に変える必要はありません。
また、配信チェーンで署名されたバンドルを公開するプラットフォームを選択するチームもあります。これにより、ビルドからデバイスまでのインテグリティチェックが維持されます。 その実践的な側面についてのより深い見方については、 このCI/CDセキュリティガイド セキュリティは、配信システムに属するものであり、周囲にないものです。
稼働後トラブルシューティングと可視化
見えないパイプラインは信頼できないパイプラインです。失敗したビルドは、どこで破れたかという単純な質問を引き起こします。悪いリリースは、パッケージング、環境の変化、または更新自体から失敗が来ているかというより難しい質問をします。つまり、ビルドパスとライブリリースパスをカバーする必要があります。どちらも外部から見ると似たような問題を引き起こす可能性があります。
重要な信号
ビルドログはどのジョブが失敗したかを教えてくれます。テストフレイクパターンは、問題が code 内にあるか、周辺のインフラストラクチャにあるかを示します。デプロイメントヘルスは、リリースがゲートを通過したときに問題がなかったかどうかを教えてくれます。CNCFレポートのDORAレンズ、デプロイメント頻度、リードタイム、変更失敗率、サービス復旧までの時間、はチームに実用的方法でシステムがどのように機能しているかを判断するための手段を提供します。 CI/CDレポートの現状.
ライブアップデートワークフローでは、数分以内に「何が変わり、どこで、どのデバイスで」に答えることができない場合、可視化は浅すぎます。
リリースが横転したときにチェックすること
まず、破れたリリースをコミット履歴と関連付けます。次に、問題を引き起こしたステージのテストとデプロイログを検査します。ライブアップデートでは、デバイスレベルのテレメトリが重要です。同じバンドルは、デバイスクラス、OSバージョン、またはアプリケーション状態によって異なる動作を示す可能性があるからです。
Capgo’s per-device ログ、採用率、バージョン履歴、チャネルガードレールは、インシデントレビュー用に設計されています。アラート用に Capgo’s CI/CD Pipelinesにアラートを追加するためのガイド ユーザーが問題を報告するのを待つのではなく、シグナルを通知に変える方法を示しています。
CI/CDの旅から始める場所
CI/CDの統合は成熟度の旅であり、チェックボックスではありません。信頼してリリースするチームは基本的な部分を組み合わせてからセキュリティ、リリースオーケストレーション、ロールバックの規則を追加します。緊張してリリースするチームは、自動化が散在しているが、連続したフローがなければなりません。
自己チェックが簡単です。トリガーは自動化されていますか? アーティファクトは署名されていますか? デプロイメントをコミットに戻すことができますか? また、プレッシャー下でロールバックポリシーを実行できる人はいませんか? それらの質問に対する答えが曖昧であれば、次の改善は明らかです。
パイプラインを製品として扱い、フィードバックループを絞り、リスクが生まれる場所にポリシーを追加し、必要に応じてアプリケーションアーキテクチャに合わせてライブアップデートチャネルを拡張してください。
CapgoはCapacitorJSおよびElectronアプリケーションにCI/CDをライブアップデート配信に組み込むのに役立ち、署名されたバンドル、ターゲットチャネル、ロールバック保護が同じリリースフローの一部になります。手動リリースから制御されたアップデートシステムに移行しようとしているチームは、 Capgoを訪問してください __CAPGO_KEEP_0__
