概要
CI/CDとは、「Continuous Integration／Continuous Delivery」の略であり、日本語では継続的インティグレーション/継続的デリバリーと呼ばれています。CI/CD は、アプリケーション開発の各ステージに自動化を導入し、顧客にアプリケーションを頻繁に提供できるようにする手法です。CI/CD は、新規コードの統合によって開発チームや運用チームに生じる問題 (すなわち「インテグレーション地獄 (integration hell)」) を解決します。
CI/CD の具体的なメリットとして、CI/CD によって、統合およびテストのフェーズからデリバリー、デプロイメントに至る、アプリケーションのライフサイクル全体を通じて、継続的な自動化と継続的な監視が導入されます。これらの連結した一連のステップはまとめて「CI/CD パイプライン」と呼ばれ、DevOps または SRE (サイト信頼性エンジニアリング) のいずれかのアプローチを使用してアジャイルな方法で共同作業する開発チームと運用チームが実施します。
CI と CD の意味と役割
CI/CD という略語にはいくつかの意味があります。CI/CD の「CI」は継続的インテグレーション (Continuous Integration) を指すのが常で、開発者向けの自動化プロセスを意味します。CI が正常に機能すると、アプリケーションへの新しいコード変更が定期的にビルド、テストされ、共通リポジトリに統合されます。CI は、同時に生じるブランチが多すぎて互いに競合するというアプリケーション開発の問題を解決します。
CI/CD の「CD」は継続的デリバリー (Continuous Delivery) または継続的デプロイメント (Continuous Deployment) を指します。これらは関連性のあるコンセプトで、時には同じ意味で使用されることもあります。両方とも、パイプラインの後半のステージの自動化に関するものですが、自動化の程度を表すために区別して使用されることがあります。
継続的デリバリーは一般に、開発者によるアプリケーションへの変更に対して、バグがないか自動的にテストし、リポジトリ (GitHub やコンテナレジストリなど) にアップロードします。ここで、変更が運用チームによって本番環境に導入されます。開発チームとビジネスチームとの間における可視性とコミュニケーションの不足という問題に対する解決策です。したがって、継続的デリバリーの目的は、新規コードの導入作業の負担を最小限にすることです。
継続的デプロイメント (もう 1 つの「CD」) は、開発者による変更をリポジトリから本番環境に自動的にリリースし、顧客が使用できるようにするというものです。運用チームが担当する手動プロセスが多すぎて、アプリケーション提供が遅れるという問題に対処します。継続的デリバリーのメリットを活用し、パイプラインの次のステージを自動化します。
CI/CD は、継続的インテグレーションと継続的デリバリーをつなげたプロセスを指すことや、継続的インテグレーション、継続的デリバリー、継続的デプロイメントという 3 つのプロセスをつなげたものを指すこともあります。さらには、「継続的デリバリー」が継続的デプロイメントのプロセスも含む意味合いで使用されることもあります。
「CI/CD」とは簡単に言うと、CI/CD とは「プロセス」であり (多くの場合パイプラインとして視覚的に表現される)、高度な継続的な自動化と監視をアプリケーション開発に取り込むものだということを覚えておいてください。
結局のところ、「CI/CD」が指す範囲は、自動化がどの程度 CI/CD パイプラインに導入されているかによって異なります。多くの企業は CI の導入から開始し、たとえばクラウドネイティブ・アプリケーションの一部として、デリバリーとデプロイメントの自動化へと進めていきます。
Red Hat のエキスパートは、組織が既存のアプリケーションをより効率的にモダナイズし、新しいアプリケーションをビルドするために必要なプラクティス、ツール、文化を生み出すお手伝いをします。
継続的インテグレーション (CI) でできること
現代のアプリケーション開発では、複数の開発者が同じアプリケーションに対して同時に作業でき、それぞれが別の機能の開発を行えることを目標としています。しかし、組織ですべてのソースコードのブランチを 1 日 (いわゆる「マージ日」) でマージするよう計画されている場合は、その作業は膨大になり、追加の手動の作業と時間が発生します。開発者が孤立した状態で作業してアプリケーションに変更を加えた場合に、同時に他の開発者が行った別の変更と競合する可能性があるからです。また、チーム全員が 1 つのクラウドベースの統合開発環境 (IDE) を使うのではなく、各人がローカルで IDE をカスタマイズして使用している場合、この問題はさらに大きくなります。
これとは対照的に、継続的インテグレーション (CI) では「トランク」と呼ばれる共有ブランチに開発者が各自のコード変更を頻繁にマージでき、日次ベースのマージも可能です。開発者による変更がアプリケーションにマージされると、アプリケーションのビルド、さまざまなレベルのテスト (通常は単体テストと統合テスト) が自動的に実行され、変更の検証が行われます。これらのテストでは、変更によるアプリケーションの破損がないことを確認します。つまり、クラスや関数から各種モジュールまで、アプリケーション全体を構成するすべてのテストが行われます。これらの自動化されるテストで新規コードと既存コード間に競合が見つかった場合も、CI プロセスではバグを簡単に、迅速に、高頻度で修復できます。
継続的デリバリー (CD) でできること
CI でのビルドと単体テストおよび統合テストの自動化の後、継続的デリバリーは検証されたコードのリポジトリへのリリースを自動化します。効果的な継続的デリバリープロセスを実施するには、CI が開発パイプラインに組み込まれている必要があります。継続的デリバリーの目標は、コードベースを常に本番環境にデプロイできる状態にしておくことにあります。
継続的デリバリーでは、コード変更のマージから本番環境用ビルドのデリバリーまでのすべてのステージで、テストの自動化とコードリリースの自動化が実施されます。このプロセスの終了時に、運用チームはアプリケーションを本番環境にすばやく簡単にデプロイできるようになります。
継続的デプロイメント (CD) でできること
成熟した CI/CD パイプラインの最終ステージには、継続的デプロイメントが来ます。継続的デプロイメントでは、継続的デリバリー (本番環境用ビルドをコードリポジトリへ自動的にリリースするプロセス) の延長として、アプリケーションを本番環境に自動的にリリースします。本番環境への移行前のパイプラインのこのステージでは手動チェックは発生しないため、継続的デプロイメントの成功は、テストの自動化が適切に設計されているかどうかに依存しています。
実際のところ、継続的デプロイメントでは、開発者によるクラウドアプリケーションへの変更は、作成後数分以内に実稼働に反映されます (自動テストに合格した場合)。これにより、ユーザーからのフィードバックを継続的に受け取り、反映させることが簡単になります。これらの相互に接続された CI/CD プロセスでは、アプリケーションのデプロイメントのリスクを低下させ、アプリケーションへの変更を一度に全部リリースするのではなく、少しずつリリースできます。ただし、CI/CD パイプラインのさまざまなテストやリリースステージに対応する自動テストを作成する必要があるため、まとまった先行投資も必要になります。
CI/CD ツールの種類
CI/CD ツールは、開発、デプロイ、テストを自動化するためのものです。これらのツールには、インテグレーション (CI) 側を処理するものもあれば、開発とデプロイ (CD) 側を管理するものもあり、継続的なテストや関連機能に特化したツールもあります。
CI/CD のオープンソースツールで最もよく知られている 1 つが、自動化サーバーの Jenkins です。Jenkins は、単純な CI サーバーから CD ハブ全体までのあらゆるものを処理するように設計されています。
Tekton Pipelines は、コンテナを使って標準のクラウドネイティブな CI/CD エクスペリエンスを提供する Kubernetes プラットフォームの CI/CD フレームワークです。
Jenkins と Tekton Pipelines 以外にも、知っておくべきオープンソースの CI/CD ツールには次のようなものがあります。
GoCD：モデリングと可視化に重点を置いた CI/CD サーバー
Concourse：「オープンソースの継続的な実行者」
Screwdriver：CD 用に設計されたビルド・プラットフォーム
さらに、さまざまなベンダーから入手できるマネージド型の CI/CD ツールを検討することもできます。主要なパブリッククラウドプロバイダーはすべて、GitLab、CircleCI、Travis CI、Atlassian Bamboo などとともに、CI/CD ソリューションを提供しています。
さらに、DevOps の基盤となるほぼすべてのツールは CI/CD プロセスの一部となっていると言えます。構成の自動化 (Ansible、Chef、Puppet など)、コンテナランタイム用ツール (Docker、rkt、cri-o など)、コンテナ・オーケストレーション用ツール (Kubernetes) は、厳密には CI/CD ツールではありませんが、 多くの CI/CD ワークフローで使用されています。
