CI/CD統合とは、自動化されたパイプラインにcodeリポジトリを接続するためのワイヤリングです。変更がビルド、テスト、リリースの段階を通過するのを手動で行うことなく、すべての変更が流れます。2024年までに、 83%の開発者 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統合が取り除くべきものです。目的は単にタスクを自動化することだけではなく、ソースコントロール、ビルドサーバー、テストランナー、アーティファクトストア、デプロイターゲットを一つのフローに接続することです。そうすれば、毎回のコミットは独自の流れで進むことができます。Red HatのCI/CDの概要 ソースコントロール, ビルドサーバー, テストランナー, アーティファクトストア, デプロイターゲット CI/CDの概要 Red Hat CI/CD統合を説明する
何が壊れるか
When teams treat CI/CD as a single tool, they usually get partial automation and still keep the risky handoffs. Code gets merged, but someone still has to kick off the build. The build finishes, but a human has to copy the artifact somewhere. The staging release works, but production needs a different script, a different credential, and a different person who remembers how it all fits together.
__CAPGO_KEEP_0__ がマージされるが、誰かがビルドを開始する必要がある ビルドが完了したが、誰かがアーティファクトをコピーする必要がある
ステージングリリースが正常に動作するが、プロダクションでは別のスクリプト、別のクレデンシャル、別の人にプロセスを理解させる必要がある 実践的なルール:リリースが記憶、サイドチャット、または「スクリプトを知っている人」に依存している場合、パイプラインはまだ統合されていない
Cloud Native Computing Foundationの2024年のレポートも、同じ種類の複数のツールを使用すると、配信パフォーマンスに悪影響を与える可能性があることを警告している
CI/CDの現状
A release workflow gets much easier to reason about once you split the ideas apart. 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は前処理ステーション
CIは、単純な習慣から始まる。変更を小さくし、すぐに検証する。ソフトウェアの場合、コミットまたはマージリクエストごとに自動チェックがトリガーされるため、破損したcodeが大量のリリースで暴露されるのを待つ必要がない。実際、忙しいキッチンでは、食材を整理し、サービス開始前にチェックする。ここでは、「前処理」はビルドとテストの自動化である。
定義はRed HatのCI/CDガイドから CIは、自動ビルドとテストの分野であり、統合問題を早期に検出する。小さな変更は容易に検証でき、問題が発生した場合、チームは問題の原因となるリリースの部分を推測することなく、問題を追跡できる。 CDには2つの意味があり、チームは混乱する
継続的デリバリーとは、__CAPGO_KEEP_0__が常にデプロイ可能であるが、人工の承認が必要な場合もある。継続的デプロイはさらに進んで、すべてのパッシング変更を自動でデプロイする。区別は、コンプライアンス、リスク耐性、通常必要なリリース制御の種類など、重要な点である。
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デスクトップ | トリガー |
|---|---|---|---|
| プッシュまたはマージリクエストが検証を開始 | プッシュまたはマージリクエストが検証を開始 | プッシュまたはマージリクエストが検証を開始 | __CAPGO_KEEP_0__ |
| ビルド | アプリケーションをパッケージ化する | 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はモバイルアプリとデスクトップアプリでどのように異なるか
Webパイプラインは、CI/CDが主にサーバーにバンドルをプッシュすることだけに考えているように人をだます。ネイティブデリバリはルールを急速に変える。CapacitorJS ではWebをビルドしますが、ネイティブシェルにパッケージし、署名とプラットフォーム固有のリリースパスを管理する必要があります。Electron, you still build web code, but you also package it into a native shell, then manage signing and platform-specific release paths. With __CAPGO_KEEP_0____CAPGO_KEEP_0__
デバイスに配信されたアプリの変更点は何ですか
モバイルチームは署名キー、App StoreおよびPlay Storeのレビュー、および実行時更新チャンネルについて考慮する必要があります。デスクトップチームはインストーラー、code署名、およびプラットフォーム間で更新動作について考慮する必要があります。共通のパターンは明らかですが、codeは同じリポジトリとビルドトリガーを通じて移動するかもしれませんが、リリースサーフェイスは異なります。
The GitHub CI/CD Pipelinesを向上させるためのcode
CI/CD Pipelinesを向上させるための__CAPGO_KEEP_0__は、段階的なテスト、機能フラグ、およびロールバックチェックポイントを指し、この世界ではよく合致します。そうした慣行は、ビルドがインストーラーやパッケージのラッパー内に存在する場合に特に重要です。なぜなら、リリースは単に「__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バンドルをチャンネルに公開できる、更新が差分化できる、ロールバックがデバイスを最後の知られている良好なバンドルに戻すことができる。 これにより、pipelineは単なるバイナリリリースパスより多くのものになり、ネイティブアプリ内にありWebアセットを制御するリリースコントロールプレーンになる。
Capgoのpipeline統合は、GitHubアクション、GitLab CI/CD、Azure DevOps、Bitbucket Pipelinesなどのシステムのドキュメントに記載されており、CIからチャンネルベースのリリースに自動化されたビルドとデプロイフローを使用します。 また、リリースツールを比較検討する際に、ジョブリストやプラットフォームの期待を考慮すると、シニアチームはエンジニアがエンドツーエンドの統合について論理的に考えることができるのではなく、ビルドスクリプトだけを書くことができるエンジニアを求めることがよくあります。 例としては、Coinbaseソフトウェアエンジニア統合ロールのBlockchain Jobsに記載されているものがあります。 Coinbaseソフトウェアエンジニア統合ロールのBlockchain Jobs__CAPGO_KEEP_0__のシークレット管理ガイドライン
__CAPGO_KEEP_0__のシークレット管理ガイドラインはCI/CD pipelineの環境部分をより具体的で理解しやすくするような補助的なリファレンスです。 重要なのは、フロー、自動化されたビルド、署名されたバンドル、ターゲットチャンネル、制御されたプロモーションです。 Capgo’s guidance on managing secrets in CI/CD pipelines CI/CDにおけるセキュリティは制御問題であり、チェックボックスではありません。 U.S.防衛ガイドラインではCI/CD環境を保護されたパスとして扱い、リポジトリ、ビルドシステム、クレデンシャル、アーティファクトルートをエンドツーエンドで保護する必要があります。
__CAPGO_KEEP_0__
__CAPGO_KEEP_1__ CI/CD環境の防御に関するガイドライン. そのフレーミングは、製品チームにとっても有用です。信頼できるパイプラインは、最速のパイプラインです。
フロー内に属する制御
短期間の資格情報は、トークンが漏洩した場合のダメージを軽減します。署名されたアーティファクトは、期待どおりのパイプラインから来たアーティファクトを証明します。SBOMとSCAチェックは、リリース前に依存性のリスクを露呈し、レビュアーが何が変更されたか誰が承認したかを追跡できるログを作成します。
The CISAとDHSのCI/CDパイプライン防御に関するガイドライン セキュリティスキャン、ログ、署名された構成、クレデンシャルライフタイムの短縮は、パイプライン内に属するものであるべきです。 これは、金融、医療、電子商取引などの規制チームにとって正しい認識です。 合規性は、事後で追加するものではなく、リリースパスの一部です。
セキュリティを追加してもリリースは速くなるはずです
チームはパニックに陥り、手動ゲートの山を想像します。 それが必要ないのです。 ポリシーはパイプライン内に存在し、承認は適切な環境に制限され、スキャンは自動的に実行され、リリースを会議に変えることなく実行されます。
また、チームは、配信チェーンに署名されたバンドルを公開するプラットフォームを選択することもあります。これにより、ビルドからデバイスまでのインテグリティチェックが維持されます。 その実践的な側面についてのより深い調査のため、このCI/CDセキュリティガイド は参考になります。 主な考えは同じです。 セキュリティは配信システムに属するものであり、周辺に存在するものではありません。 CI/CDセキュリティガイド
トラブルシューティングと観測性
実行後にはトラブルシューティングと観測性
見えないパイプラインは信頼できないパイプラインです。失敗したビルドは、どこで破れたかという単純な質問を引き起こします。悪いリリースは、パッケージング、環境の変化、またはアップデート自体から失敗したかというより難しい質問を引き起こします。つまり、ビルドパスとライブリリースパスをカバーする観測性が必要です。どちらも外部から見ると似たような問題を引き起こす可能性があります。
Build logs tell you which job failed. Test flake patterns show whether the issue sits in the code or in the infrastructure around it. Deployment health tells you whether a release moved through the gates cleanly. The DORA lenses from the CNCF report, deployment frequency, lead time, change failure rate, and time to restore service, still give teams a practical way to judge whether the system is helping ビルドログは失敗したジョブを教えてくれます。テストフレイクパターンは、問題が __CAPGO_KEEP_0__ 内にあるか、周辺のインフラストラクチャにあるかを示します。デプロイメントヘルスは、リリースがゲートを通過したときに問題が生じたかどうかを教えてくれます。CNCFレポートのDORAレンズ、デプロイメント頻度、リードタイム、変更失敗率、サービス復旧までの時間、チームに実用的方法でシステムがどのように役立つかを判断させることができます。.
CI/CDレポートの現状
ライブアップデートワークフローでは、数分以内に「何が変わり、どこで、どのデバイスで」が答えられない場合、観測性は浅すぎます。
リリースが横転したときにチェックすること
Capgoのデバイスごとのログ、採用メトリクス、バージョン履歴、チャンネルガードレールは、そのようなインシデントレビュー用に設計されています。アラートについては CapgoのCI/CD Pipelinesにアラートを追加するためのガイド は、ユーザーが問題を報告するのを待つのではなく、信号を通知に変える方法を示しています。
CI/CDの旅からここまで
CI/CDの統合は成熟度の旅であり、チェックボックスではありません。信頼して発送するチームは基本的な部分を組み合わせてから、セキュリティ、リリースオーケストレーション、ロールバックの規則を追加します。緊張して発送するチームは、自動化が散在しているが、連続したフローがつながっていない場合があります。
迅速な自己チェックが役立ちます。トリガーは自動的ですか?アーティファクトは署名されていますか?デプロイメントをコミットに戻すことができますか?ロールバックポリシーは、プレッシャー下で実行できるものですか?答えが曖昧な場合は、次の改善は明らかです。
パイプラインを製品として扱い、フィードバックループを絞り、リスクが生じる場所にポリシーを追加し、必要に応じてアプリケーションアーキテクチャに応じてライブアップデートチャンネルに配信を拡張してください。
CapgoはCapacitorJSとElectronアプリのCI/CDをライブアップデート配信に組み込むのに役立ち、署名されたバンドル、ターゲットチャンネル、ロールバック保護は同じリリースフローの一部になります。手動リリースから制御されたアップデートシステムへの移行を試みているチームは、 Capgo そして、パイプラインにどのようにフィットするかを確認してください。
