CI/CD
CI/CD とは
CI/CD (継続的インテグレーション/継続的デリバリ/デプロイ) は、自動化によって実現されるソフトウェア開発手法です。頻繁で信頼性の高いアップデートを通して、継続的なコード配信によりリリースサイクルを短縮します。
詳説 CI/CD
CI/CD は、複数の DevOps フェーズをカバーする包括的な用語です。CI (継続的インテグレーション) とは、コードの変更を 1 日に数回リポジトリに統合することを指します。CD には 2 つの意味があります。継続的な デリバリ はコードの統合を自動化し、継続的な 展開 は最終的なビルドをエンドユーザーに自動的にリリースします。 CI/CD はコードのエラーや不具合を減らすため、すべての DevOps ワークフロー にとって不可欠です。
継続的インテグレーションとはCI
継続的インテグレーション (CI) は、すべてのデプロイでクリーンで高品質なコードを確保しながら、開発スピードを高める自動化されたソフトウェア開発プロセスです。継続的インテグレーションでは、開発者は 1 日に何度もコードの単位を中央の共有リポジトリにチェックイン/コミットする必要があります。
CI は DevOps ベストプラクティス であり、開発者が共有コード リポジトリにコードをチェックインするときの DevOps ライフサイクル のステージです。自動ビルドツールは、チェックインまたはブランチにエラーがなく、本番環境に入る準備ができていることを確認します。ここでの主な利点は、問題が雪だるま式に大きな問題に発展する前に早期に発見されることです。
CI を実践するということは、時間をかけ頻繁に更新するのではなく、変更の小さなサブセットをより短期間で統合することを意味します。共有リポジトリに対する変更のテスト、マージ、チェックインのワークフローを自動化することで、チームはよりクリーンなコードをより迅速に提供できるようになります。コードがクリーンになれば、より迅速な検証、より高品質なリリース、より効率的な開発パイプラインが実現し、スケールが容易になります。
継続的インテグレーションのしくみ
継続的インテグレーションは、開発フェーズから始まり、テスト環境で終わるシンプルでシームレスなプロセスです。継続的インテグレーションにより、すべての開発者が協力して作業し、コードを追跡することができます。すべての開発者は、メインラインリポジトリとも呼ばれる共有コードリポジトリにコードを少しずつ "コミット” します。コードリポジトリは、Unity VCS、Perforce、Git などの バージョン管理システム で管理されます。リポジトリのメインブランチ (または選択可能な場合は子ブランチ) にコミットするたびに、コードを取得してビルドを作成するビルド管理システムにリンクされた自動ビルドプロセスをトリガーできます。コードがビルドシステムにマージされると、開発者はコードビルドにフルアクセスできるようになります。ここから、コードが正しくコンパイルされているか、修正が必要なエラーがあるかどうかを確認できます。ビルドシステムは、さまざまなテストフレームワークをサポートするように設定できます。
コードが承認され、ビルドサイクルが成功すると、自動テスト環境がトリガーされ、ビルドとその後のリリースの品質が検証されます。テストとビルドのプロセスがきわめて迅速であるため、コードのコミット結果がすばやく伝達され、開発者は残ったエラーをタイムリーに修正できます。このプロセス全体を通じて、コードベースが健全に保たれ、全員が効率的に作業を続けることができます。
CI のルールと原則
- 1 つの中央コードリポジトリを維持する
さまざまなチームのさまざまな開発者のコードを、別々のリポジトリや別のシステムに一時的に保存することは、最小限に抑える必要があります。
- メインラインリポジトリにコードを頻繁にコミット/チェックインする
開発者がビルドやテストを行わずにコードを保持する期間が長いほど、中央リポジトリに保存されているコードとの整合性がとれなくなります。
- ビルドサーバーとテストサーバーを分ける
チームは、ビルドの目的でのみ専用マシンを維持するようにしてください。これにより、ビルドプロセスがスピードアップし、他の開発者のワークフローへの影響を最小限に抑えることができます。
- ビルドとテストは自動化する必要がある
中央ソースコードリポジトリにコミットされたすべてのコードは、継続的インテグレーションツールを使用して自動的にビルドおよびテストされる必要があります。
- 本番環境に近いテスト環境を使用する
テスト環境では、最終的な本番環境のシミュレーションを行う必要があります。これにより、テスト環境の有用性が確保され、展開全体を通して期待を一貫したものにすることができます。
- 品質保証チームはビルドにアクセスできる必要がある
QA がビルドにアクセスできると、本番環境での要件を満たしていないことを早期に発見できるため、後でコードビルドを作り直すリスクを軽減できます。
継続的デリバリと継続的デプロイ
継続的デプロイと継続的デリバリは、新しいコードをできるだけ迅速かつ効率的に本番環境にプッシュするために使用されるプラクティスです。継続的デリバリは CI に従います。最終製品を顧客にリリースする前の、開発パイプラインのチェックポイントフェーズと考えることができます。コードの変更が検証されると、自動的に中央リポジトリにデリバリされます。
継続的デプロイは DevOps ライフサイクルの CI に従いますが、この 2 つのプロセスはリンクされています。CI は自動化によってビルドにコードを統合し、CD がそのプロセスを完了します。DevOps の自動化は、アップデートの品質を評価します。エラーがないことが確認されると、自動的に本番環境にデプロイされます。
継続的デリバリとは
継続的デリバリとは、ソフトウェアに対するコード変更を構築、テスト、デリバリすることです。このプロセスでは、コードは自動単体テスト、統合テスト、システムテストなどのさまざまなテスト環境を通過してから本番環境にプッシュされます。継続的デリバリは、QA がコードのレビュー、バグ修正、自動テストを実行する本番環境のようなステージング環境で発生し、ビルドが常にデプロイ可能かつリリース可能な状態であることを確認します。
継続的デリバリでは、メインビルドの更新が最終製品の "製品版" ステータスを損なわないように、変更セットを小さく保つことが目標です。最終製品には小さなエラーが含まれているかもしれませんが、ユーザー体験を損なうような重要なものはありません。
開発者は、継続的デリバリを実践することにより、社内でのテストに費やす時間を減らすことができます。安定したコードのみが第一にデリバリフェーズに間に合うようになるからです。これにより、バグ検出のプロセスが容易になり、解決までの時間を短縮できます。
継続的デプロイとは
継続的デプロイは、ビルドが安定したら、コードの変更を中央リポジトリから本番環境に継続的にデプロイすることを目的としています。運用チームは、コンパイルされたコードをデプロイし、さまざまな環境 (開発/テスト、ステージング、本番) にソフトウェアをインストールします。各変更は自動化されたパイプラインを通過し、アプリケーションの現用バージョンが本番環境にプッシュされます。デプロイにはさまざまな形態があります。ダークリリース とは、ユーザーから見えないようにデプロイすることであり、機能トグル や スイッチ は、テストやフィードバックのために変更セットの特定のサブセットをユーザーのグループにデプロイするために使用できます。
継続的デプロイは、開発者と顧客にとって数多くの利点があります。継続的デプロイソリューションを使用している開発者は、手動でのビルドデプロイに頭を悩ませる必要がなくなり、よりスキルベースのタスクに集中できます。自動化によってフィードバックループが短縮されるため、顧客からの意見に基づいて製品をより迅速に更新できます。継続的デプロイにより、品質を確保し、製品のリアルタイム監視を可能にするシミュレーション環境でコードが実行および維持されます。継続的デプロイの主な目標は、新しいバージョンのコードを一貫してリリースし、その変更を自動的にエンドユーザーにデプロイすることです。
CI/CD と DevOps の関係
すべてのソフトウェア開発は、プリプロダクション (計画フェーズ) から始まり、プロダクション (コーディングとアセット作成) が続きます。DevOps は、これらのプロセスをより効率的にするための文化でありプロセスです。CI/CD は、DevOps ライフサイクルのフェーズの 1 つです。このフェーズでは、最終製品の継続的かつ反復的な改善を保証するために、小規模ながら安定したコード更新のストリームを経時的に実施することを義務付けています。
特定のツールや製品を使用して、コードの変更を統合、デリバリ、デプロイできるようにすることにより、定期的で頻繁なソフトウェアリリースを実現できます。これを CI/CD パイプラインと呼びます。
CI/CD パイプラインは、DevOps ライフサイクルを実現するツールと自動化に結び付けられた特定のフェーズのセットです。CI/CD は DevOps の文化に不可欠な要素ですが、DevOps はコラボレーションからチーム構造、可観測性、バージョン管理など、ソフトウェア開発のライフサイクル全体にわたり、はるかに多くの要素を含んでいます。
DevOps の実装は組織によって大きく異なりますが、DevOps の核となるのは CI/CD です。CI/CD パイプラインは、本質的に DevOps の文化と、小規模で頻繁なリリースのプロセスと結びついています。
CI/CD の利点
- 迅速なイテレーション
CI/CD プラクティスを DevOps ライフサイクルの一部として採用することにより、コードベースに対する変更の検証とデプロイの手動作業を自動化し、開発をスピードアップします。
- より明確なコード
1 日を通して数多くの小さな変更をチェックインすることにより、ビルドを壊すエラーがソースコードに導入されるリスクを大幅に軽減できます。
- より迅速なバグ修正
小さな変更セットを CI/CD で頻繁にマージすることで、コードエラーを特定し、大きな問題になる前の修正が容易になります。
- フィードバックループの短縮
CI/CD は、DevOps のコア原則であるフィードバック ループを短縮するのに役立ちます 。これは、小さな変更を反復的に行うことで、統合、テスト、デプロイが容易になるからです。
- コラボレーションの向上
CI/CD は、コードのコミットとビルドの起動のプロセスとタイムラインを定義することで、作業をより明確化します。目標が明確になれば、チームは俊敏に行動できるようになります。
- お客様の満足度向上
ビルドは常に CI/CD でリリース可能なため、サービスの中断が減り、フィードバックをより迅速に統合できます。
アジャイルは CI/CD と同じですか?
アジャイルワークフローと CI/CD は関連しますが、同じではありません。それぞれ、ソフトウェア開発パイプラインのまったく異なる側面を説明しています。アジャイル開発とは、ソフトウェア開発におけるワークフロー、ミーティングの頻度、チーム編成を管理するためのプロセスまたは方法論のことです。アジャイルな方法論では、顧客のニーズに耳を傾けて対応し、開発プロセスの各段階に顧客を参加させることで、変化を受け入れながらデリバリをスピードアップします。
CI/CD は、ソフトウェアのリリースと改善においてボトルネックとなる人的要素を取り除くために、自動化に依存しています。テストは CI と CD の両方でパイプライン全体を通して自動化されており、不具合の修正にかかるコストと時間を最小限に抑えるために頻繁に行われます。
継続的デプロイで本番環境にデプロイする頻度はどれくらいですか
CI/CD では、将来の問題を回避し、ソフトウェアが常にリリース可能な状態 (通常は 1 日に複数回デプロイ) になるように、リリースを常に頻繁に行う必要があります。CI/CD チームでは、”定数" リリースを実装すべきという前提が一般的ですが、常にそうとは限りません。リリースサイクルは、製品、ビルド、その他考慮すべき要素によって大きく異なります。
1.重大な修正ですか、マイナーな修正ですか?
2.ビルドからビルドへのリグレッション数を追跡していますか?
3.QA チームは配置されていますか?
4.コードベースに単体テストはありますか?
5.コードの重複はありますか?
これらはリリース戦略とパイプラインを考える際に考慮すべき事柄のほんの一例ですが、チームによって大きく異なります。製品によって求められるアプローチも異なります。
継続的デプロイに価値がありますか?
この質問に対するすべての答えに当てはまるものはありません。継続的デプロイに投資する前に、まず自社製品の最大のリスクを評価し、次にソフトウェアのデプロイ方法のトレードオフを決定する必要があります。
製品の成功は、迅速にイテレーションを行い、顧客からフィードバックを得て、変更を加え続けることができるかどうかにかかっています。フィードバックループの短縮とレスポンシブなビジネスの構築を優先している場合は、継続的デプロイはきわめてインパクトがあり、収益性も高くなります。
ただし、顧客の数が少ないビジネスでは、デプロイの増分を導入することで得られるメリットは少なく、コストが増加します。どのステージング環境を導入するかは、最終的にビジネスニーズ、ワークフロー、予算によって異なります。
継続的デリバリは、設定内の元のコードを継続的に変更するため、設定が促進されます。これにより、時間の経過とともに発生する可能性のあるコードエラーが確実に回避されます。