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統合の基本コンポーネント
- パイプラインにセキュリティとコンプライアンスを組み込む
- リリース後、トラブルシューティングと監視
- CI/CD ジョブの次のステップ
誰もが忘れたリリースの日
火曜日の朝、簡単なホットフィックスが始まりました。金曜日の夜までに、同じパッチはまだブランチに座っています。マニュアルQAが1つだけの問題を発見し、リリースノートは半分しか完成していません。Slackで3人の人が最新のビルドを持っている人を尋ねています。オンコールエンジニアは午後11時にリリーススクリプトを実行し、誰もが完全に確実にステージングにあるアーティファクトがソースコントロールにあるアーティファクトと一致しているかどうかわかりません。
その混乱は、CI/CD統合が取り除くべきものです。ポイントは、単にタスクを自動化することだけではありません。ソースコントロール、ビルドサーバー、テストランナー、アーティファクトストア、そしてデプロイターゲットを1つのフローに接続することです。 ソースコントロール, ビルドサーバー, テストランナー, アーティファクトストア, デプロイターゲット CI/CDのRed Hat概要 Red Hat overview of CI/CD CI/CD統合を説明すると、自動化されたDevOpsワークフローとして、通常、ビルド、テスト、スキャン、パッケージング、プロモーション、デプロイを含みます。
Whatが壊れるか
CI/CDを単一のツールとして扱うと、通常、部分的な自動化とリスクのあるハンドオフが残ります。Codeがマージされるが、ビルドを開始するのは誰かが必要です。ビルドが完了したが、人間がアーティファクトをコピーする必要があります。ステージングリリースが正常に動作するが、プロダクションには別のスクリプト、別のクレデンシャル、別の人にそれがどのように機能するかを思い出す必要があります。
実践的なルール: リリースが記憶、サイドチャット、または「スクリプトを知っている人」に依存している場合、パイプラインはまだ統合されていません。
Cloud Native Computing Foundationの2024年のレポートも、同じ種類の複数のツールを使用すると、デリバリーパフォーマンスに悪影響を与える可能性があることを警告しています。 CI/CDの現状. これは、大規模なチームにとって重要です。統合とは、ツールを所有することではなく、同じ真実の源に同意させることです。
健全なCI/CD設定では、コミットからユーザーまでの1つのパスが得られます。弱いものでは、各自の手動橋を持つ島々の集まりが得られます。差はリリース日に出現し、チームが混乱を最も恐れるときに最も出現します。
CIとCDの分解
リリースワークフローは、アイデアを分離することで、より簡単に推論できるようになります。 CI CI CD focuses on keeping validated code ready for release, then deciding whether production receives that code with or without a human approval step.
CIは準備室です。
Continuous integration starts with a simple habit, keep changes small and verify them right away. In software terms, every commit or merge request triggers automated checks so broken code does not sit around until a large release tries to expose it. That is the same reason a busy kitchen keeps ingredients sorted and checked before service starts, only here the “prep” is build and test automation instead of chopped vegetables.
Red HatのCI/CDガイドから CIは、自動ビルドとテストの分野で、統合問題を早期に検出します。小さな変更は簡単に検証でき、問題が発生した場合、チームは問題の原因となるリリースの部分を推測することなく、問題を追跡できます。 CDには2つの意味があり、チームは混乱しています。
継続的デリバリーとは、コードが常にデプロイ可能ですが、人によってはプロダクションが実行されるタイミングが決められます。継続的デプロイはさらに進んで、すべてのパッシングチェンジを自動でデプロイします。その区別は、コンプライアンス、リスク承認、通常必要なリリース制御の種類、モバイルとデスクトップチームの場合に重要です。
codeは常にデプロイ可能です。
A release manager on a consumer app may prefer continuous delivery because store timing still needs coordination. A backend team with strong automated checks may choose continuous deployment for low-risk services. The right choice depends on governance, not slogans.
CIを強化するチームがリリースを自動化する前にCI側を強化しようとしている場合 このCIに焦点を当てたガイド CI/CDのステージをWeb、モバイル、デスクトップで比較
| Webアプリ | CapacitorJSモバイル | Electronデスクトップ | トリガー |
|---|---|---|---|
| Pushまたはマージリクエストが検証を開始 | Pushまたはマージリクエストが検証を開始 | Pushまたはマージリクエストが検証を開始 | Pushまたはマージリクエストが検証を開始 |
| ビルド | アプリケーションをパッケージ化する | Bundle web code, then wrap it in a native shell | Compile main and renderer code, then package the desktop app |
| テスト | ユニット、統合、UIテスト | ラッパーとランタイムの動作に関するモバイル固有のチェックを追加する | パッケージングとアプリケーション起動パスのデスクトップ固有のチェックを追加する |
| リリース | ホスティングまたはアプリケーションランタイムにデプロイする | ストアチャネルまたはライブアップデートチャネルに公開する | インストーラーやライブアップデートチャネルに公開する |
| 承認 | オプションの人間ゲート | ストアとロールバックの制御のためによく必要 | 署名と配布の制御のためによく必要 |
CI/CD Pipelinesの解剖学
パイプラインは、入力と出力を持つジョブのグラフです。開発者がcodeをプッシュすると、ウェブフックまたはマージイベントが最初のジョブをトリガーし、次のジョブが前のステージからアーティファクトを消費し、リリースが完了するまで続きます。そのため、CI/CD統合は実際にはステージ間の契約であり、不思議なプラットフォーム機能ではありません。
各ステージが何をしているか
ソースコントロールトリガーが流れを開始します。ビルドジョブはcodeをコンパイルし、依存関係を解決します。これが隠れた破損の多くが見つかる場所です。テストジョブはユニット、統合、UIチェックを実行し、セキュリティスキャンは脆弱なパッケージや安全でない構成を探します。
良いパイプラインは早く失敗し、失敗した場所を正確に教えてくれます。
次に、パッケージングは検証された出力を展開可能なものに変換します。たとえば、コンテナイメージ、署名されたAPKまたはIPA、Electron配布可能なもの、またはJavaScriptバンドルなど。 HCLによるCI/CD採用と実装の概要 はここで役立ちます。なぜなら、チームがしばしば部分的な自動化に止まるのを示しているからです。多くのチームにはパイプラインがありますが、すべてのステージが完全に接続されていない場合があります。
ステージの境界はなぜ重要か
ハンドオフの各アーティファクトを名前できなければ、デバッグは推測に頼ることになります。ステージングでリリースが失敗した場合、依存関係の解決、フラッキーテスト、セキュリティポリシー、パッケージングのいずれから問題が生じたかを知る必要があります。そのため、コミットからアーティファクトまで環境まで内部のトレースが含まれる良いパイプライン設計が必要です。
ビルド部分がより大きなフローにどのようにフィットするかを実践的な視点で見たいチームにとって このビルドに焦点を当てたガイド は見る価値があります。ビルドステージが所有するものとリリースオーケストレーションが所有するものを区別するのに役立ちます。
CI/CDはモバイルアプリとデスクトップアプリでどのように異なるか
ウェブパイプラインは、CI/CDが主にサーバーにバンドルをプッシュすることだけに考えさせることがあります。ネイティブデリバリはルールを急速に変えるのです。CapacitorJSの場合、ウェブをビルドするのと同じですが、ネイティブシェルにパッケージし、署名とプラットフォーム固有のリリースパスを管理する必要があります。 Electronの場合、デスクトップ環境用にアプリケーションをコンパイルし、サポートするオペレーティングシステム用のインストーラーやディストリビューションをパッケージする必要があります。code ElectronElectron
デバイスに配信されたアプリの変更点は何ですか
モバイルチームは署名キー、App StoreおよびPlay Storeのレビュー、および実行時更新チャンネルについて考える必要があります。デスクトップチームはインストーラー、code署名、およびプラットフォーム間で更新動作について考える必要があります。共通のパターンは明らかですが、codeは同じリポジトリとビルドトリガーを通じて移動するかもしれませんが、リリースサーフェイスは異なります。
The GitHub code
CI/CD Pipelinesを向上させるための指針は、段階的なテスト、機能フラグ、およびロールバックチェックポイントを含みます。これは、この世界に合致しています。そうした慣行は、ビルドがラッパーやインストーラー内に存在する場合に特に重要です。なぜなら、リリースは単に「__CAPGO_KEEP_0__がコンパイルされるかどうか」ではなく、「このパッケージが実機上で安全に動作するかどうか」であるからです。
モバイルおよびデスクトップチームが追加するもの
- Webリリースはしばしばステージングまたはプロダクションへのデプロイで止まることがあります。モバイルリリースは通常、チャンネル、承認、およびロールバック動作の追加層が必要です。Electronチームは同じ規律を必要としますが、デスクトップパッケージングおよび更新配布代わりにアプリストアの提出が必要です。 CapacitorJSモバイル:
- Webバンドル、ネイティブラッパー、署名、ストアレビュー、およびライブ更新チャンネル Electronデスクトップ:
- メインプロセスビルド、レンダラー ビルド、パッケージされたインストーラー、署名、および更新チャンネル制御 ビルド、テスト、パッケージ、展開、監視
実行中の更新システムがCI/CDの一部になるのではなく、サイドプロジェクトとして扱われるのは、そのギャップの部分です。ビルドがバンドルを生成できる場合、リリースシステムは安全にユーザーに到達する方法を決定する必要があります。
CI/CD統合を実現するコアコンポーネント
トリガー、パイプライン、アーティファクト、環境は、チームが再びハードウェイで学習する4つの部分です。トリガーは、通常、Gitプッシュまたはマージリクエストが起動するイベントです。パイプラインは、順序付きのジョブのセットです。アーティファクトは、検証済みの出力です。環境は、その出力が昇格または抑制される場所です。
4つの部分を簡単に説明します
トリガーは、Gitと自動化のハンドシェイクです。パイプラインは、ルールを定義し、ビルドからテスト、スキャン、パッケージ、リリースまでの流れを定義します。アーティファクトは、その作業の結果を前方に運びます。そのため、同じバンドルがテストと展開に使用される必要があります。
環境は、意図と影響を安全に分離する安全な場所を提供します。Dev、Staging、Beta、Productionは、実際の作業を行っています。チームは、1つの場所で変更を証明し、他の場所でユーザーが依存する前に、安全に実行できます。
ルールの thumb: コミットとアーティファクトにトレースできない環境は、リスクではなく、安全ネットではありません。
実行中の更新フローでCapgoがどのように機能するか
CapacitorJSとElectronアプリ用のCapgoは、ライブアップデートレイヤーに位置し、署名されたWebバンドルをチャンネルに公開できる、更新が差分化できる、ロールバックがデバイスを最後の知られている良好なバンドルに戻すことができる。 これにより、パイプラインは単なるバイナリリリースパスではなく、ネイティブアプリ内にありWebアセットを制御するリリースコントロールプレーンになる。
Capgoのパイプライン統合は、GitHubアクション、GitLab CI/CD、Azure DevOps、Bitbucket Pipelinesなどのシステムのドキュメントに記載されており、CIからチャンネルベースのリリースに自動化されたビルドとデプロイフローを使用します。 また、リリースツールを比較検討する際に、ジョブリストやプラットフォームの期待を考慮すると、シニアチームはエンジニアがエンドツーエンド統合について論理的に考えることができるのではなく、ビルドスクリプトだけを理解していることを求めることがよくあります。 例としては、ブロックチェーンジョブのCoinbaseソフトウェアエンジニア統合ロールがあります。 ブロックチェーンジョブのCoinbaseソフトウェアエンジニア統合ロール__CAPGO_KEEP_0__のシークレットの管理に関するガイドライン
__CAPGO_KEEP_0__のシークレットの管理に関するガイドラインは、CI/CDパイプラインの環境の部分をより具体的になるような補助的なリファレンスです。 重要なのは、フロー、自動化されたビルド、署名されたバンドル、ターゲットされたチャンネル、制御されたプロモーションです。 Capgo’s guidance on managing secrets in CI/CD pipelines CI/CDにおけるセキュリティは制御問題であり、チェックボックスではありません。 アメリカの防衛ガイドラインでは、CI/CD環境を保護されたパスとして扱い、リポジトリ、ビルドシステム、資格情報、アーティファクトルートをエンドツーエンドで保護する必要があります。
__CAPGO_KEEP_0__
__CAPGO_KEEP_1__ CI/CD環境の防御に関するガイドラインCI/CDパイプラインのセキュリティを確実にするためには、パイプラインの信頼性が高くなるほど、速いパイプラインが必要です。
フロー内に含まれる制御
短期間のクレデンシャルは、トークンが漏洩した場合の被害を軽減します。署名されたアーティファクトは、ビルドまたはバイナリが予想どおりのパイプラインから来ていることを証明します。SBOMとSCAチェックは、リリース前に依存性のリスクを暴き、レビュアーが何が変更されたか誰が承認したかを追跡できるようにするログを生成します。
CI/CDパイプラインのセキュリティに関するCISAとDHSのガイドライン セキュリティスキャン、ログ、署名された構成、クレデンシャルの有効期間の短縮は、パイプライン内に含まれるべきです。金融、医療、ECOMMERCEなどの規制チームにとって、これが正しい認識です。規制は事後的に追加するのではなく、リリースパスの一部です。 セキュリティを追加してもリリースは速くなるべきです。
チームはパニックに陥り、手動ゲートの山を想像しますが、それは必要ありません。ポリシーはパイプライン内に存在し、承認は適切な環境に制限され、スキャンは自動的に実行され、リリースを会議に変えることなく、
また、ビルドからデバイスまでのインテグリティチェックを維持するために、署名されたバンドルを配信するプラットフォームを選択するチームもあります。実践的な側面についてのより深い調査のため、このCI/CDセキュリティガイド
CI/CDセキュリティガイド CI/CDパイプラインのセキュリティは、パイプライン自体に含まれるべきであり、パイプラインの周りに存在するべきではありません。 CI/CDパイプラインのセキュリティを確実にするためには、パイプラインの信頼性が高くなるほど、速いパイプラインが必要です。
トラブルシューティングと可視性
実稼働後も見ることができないパイプラインは、信頼できないパイプラインです。失敗したビルドは、どこで破れたかという単純な質問を引き起こします。悪いリリースは、パッケージング、環境の変化、またはアップデート自体から失敗したかどうかというより難しい質問を引き起こします。つまり、ビルドパスと実稼働リリースパスをカバーする必要があります。どちらも外部から見ると似たような問題を引き起こす可能性があります。
重要な信号
ビルドログは、どのジョブが失敗したかを教えてくれます。テストフレイクパターンは、問題が code 内にあるか、周囲のインフラストラクチャにあるかを示します。デプロイメントヘルスは、リリースがゲートを通過したときに問題が生じたかどうかを教えてくれます。CNCFレポートのDORAレンズ、デプロイメント頻度、リードタイム、変更失敗率、サービス復旧までの時間は、チームがシステムがどのように役立っているかを実際に判断するための実用的方法を提供します。 CI/CDレポートの現状.
実稼働更新フローに対して、数分以内に「何が変わり、どこで、どのデバイスで」が答えられない場合、可視性は浅すぎます。
リリースが横転したときにチェックすること
まず、破れたリリースとコミット履歴を関連付けます。次に、失敗を導入したステージのテストとデプロイログを検査します。ライブアップデートの場合、デバイスレベルのテレメトリは重要です。同じバンドルは、デバイスクラス、OSバージョン、またはアプリケーション状態によって異なる動作を示す可能性があります。
Capgoのデバイスごとのログ、採用メトリクス、バージョン履歴、チャンネルガードレールは、そのようなインシデントレビュー用に設計されています。アラートについては CapgoのCI/CD Pipelinesにアラートを追加するためのガイド は、ユーザーが問題を報告するのを待つのではなく、信号を通知に変える方法を示しています。
CI/CDの旅からここまで
CI/CDの統合は成熟度の旅であり、チェックボックスではありません。信頼して発送するチームは基本的な部分を組み合わせてから、セキュリティ、リリースオーケストレーション、ロールバックの規則を追加します。緊張して発送するチームは、自動化が散在していますが、連続したフローがつながっていません。
CI/CDの成熟度の旅のためのクイックセルフチェックが役立ちます。トリガーは自動的ですか?アーティファクトは署名されていますか?デプロイメントをコミットに戻すことができますか?ロールバックポリシーは、プレッシャー下で実行できるものですか?答えが曖昧な場合は、次の改善は明らかです。
パイプラインを製品として扱い、フィードバックループを絞り、リスクが生まれる場所にポリシーを追加し、必要に応じてアプリケーションアーキテクチャに更新チャネルを拡張してください。
CapgoはCapacitorJSとElectronアプリのCI/CDをライブアップデート配信に組み込むのに役立ち、署名されたバンドル、ターゲットチャンネル、ロールバック保護は同じリリースフローの一部になります。チームがマニュアルリリースから制御されたアップデートシステムに移行しようとしている場合は、 Capgo そして、パイプラインにどのようにフィットするかを確認してください。
