DevOps

CI/CD とは

CI/CD とは、アプリケーション開発のステージに自動化を取り入れて、顧客にアプリケーションを提供する頻度を高める手法です。CI/CD から発生した主なコンセプトは、継続的インテグレーション、継続的デリバリー、継続的デプロイメントです。CI/CD は、新規コードの統合によって開発チームや運用チームに生じる問題 (すなわち「インテグレーション地獄」) に対する解決策です。

具体的には、CI/CD によって、統合およびテストのフェーズからデリバリー、デプロイメントに至る、アプリケーションのライフサイクル全体を通じて、継続的な自動化と継続的な監視が導入されます。これらの連結した作業習慣はまとめて「CI/CD パイプライン」と呼ばれ、アジャイルな方法で共同作業する開発チームと運用チームが実施します。


CI と CD (およびその他の CD) との違い

CI/CD という略語にはいくつかの意味があります。CI/CD の「CI」は継続的インテグレーションを指すのが常で、開発者向けの自動化プロセスを意味します。CI が正常に機能すると、アプリケーションへの新しいコード変更が定期的にビルド、テストされ、共通リポジトリに統合されます。CI により、アプリケーション開発において同時に生じるブランチが多すぎて互いに競合するという問題を解決できます。

CI/CD の「CD」は継続的デリバリーまたは継続的デプロイメントを指します。これらは関連性のあるコンセプトで、時には同じ意味で使用されることもあります。両方とも、パイプラインでの以降のステージの自動化に関するものですが、自動化の程度を表すために区別して使用されることがあります。

継続的デリバリーは一般に、開発者によるアプリケーションへの変更に対して、バグがないか自動的にテストし、リポジトリ (GitHub やコンテナレジストリなど) にアップロードします。ここで、変更が運用チームによって本番環境に導入されます。開発チームとビジネスチームとの間における可視性とコミュニケーションの不足という問題に対する解決策です。したがって、継続的デリバリーの目的は、新規コードの導入作業の負担を最小限にすることです。

継続的デプロイメント (もう 1 つの「CD」) は、開発者による変更をリポジトリから本番環境に自動的にリリースし、顧客が使用できるようにするというものです。運用チームが担当する手動プロセスが多すぎて、アプリケーション提供が遅れるという問題に対処します。継続的デリバリーのメリットを活用し、パイプラインの次のステージを自動化します。

CI/CD は、継続的インテグレーションと継続的デリバリーをつなげた作業習慣を指すことや、継続的インテグレーション、継続的デリバリー、継続的デプロイメントという 3 つの作業習慣をつなげたものを指すこともあります。さらには、「継続的デリバリー」が継続的デプロイメントのプロセスも含む意味合いで使用されることもあり、状況は一層複雑になります。

用語の意味に惑わされていては、時間が無駄になるだけです。CI/CD とはプロセスであり、多くの場合パイプラインとして視覚的に表現され、高度な継続的自動化と継続的な監視をアプリケーション開発に取り込むものだということを覚えておいてください。この用語が指す内容は、自動化がどの程度 CI/CD パイプラインに導入されるかによって、事例ごとに異なります。多くの企業は CI の導入から開始し、たとえばクラウドネイティブ・アプリケーションの一部として、デリバリーとデプロイメントの自動化へと進めていきます。


継続的インテグレーション

現代のアプリケーション開発では、複数の開発者が同じアプリケーションの別の機能に対して同時に作業することが目標です。ただし、すべてのソースコードのブランチを 1 日 (いわゆる「マージ日」) でマージするよう計画しているのなら、その作業は膨大になり、自動化されず、時間がかかります。開発者が孤立した状態で作業してアプリケーションに変更を加えると、同時に他の開発者が行った別の変更と競合する可能性があるからです。

継続的インテグレーション (CI) は、「トランク」と呼ばれる共有ブランチに開発者が各自のコード変更をマージする頻度を高め、毎日でもマージできるようにします。開発者による変更がアプリケーションにマージされると、 アプリケーションを自動的にビルドしてさまざまなレベルのテストを実行して、変更を検証します。通常は単体テストと統合テストを行い、変更によってアプリケーションが破壊されないことを確認します。つまり、クラスや関数から各種モジュールまで、アプリケーション全体を構成するすべてをテストします。自動化テストで新規コードと既存コードに競合が見つかった場合、CI を利用するとこのようなバグをすばやく容易に、高頻度で修復できます。


継続的デリバリー

CI でのビルドと単体テストおよび統合テストの自動化に続けて、継続的デリバリーは検証されたコードのリポジトリへのリリースを自動化します。そこで、効果的な継続的デリバリープロセスを実施するため、開発パイプラインに CI が組み込み済みであることが重要です。継続的デリバリーの目標は、本番環境にデプロイできるコードベースを常に保持しておくことです。

継続的デリバリーでは、コード変更のマージから本番環境対応のビルドのデリバリーまで、すべてのステージでテストの自動化とコードリリースの自動化が実施されます。このプロセスの終了時には、運用チームはアプリケーションを本番環境にすばやく簡単にデプロイできます。


継続的デプロイメント

成熟した CI/CD パイプラインの最終ステージは、継続的デプロイメントです。本番環境対応のビルドをコードリポジトリへ自動的にリリースする継続的デリバリーの延長として、継続的デプロイメントはアプリケーションを本番環境に自動的にリリースします。本番環境に移す前のパイプラインのステージでは手動でのチェックはないので、継続的デプロイメントは主に、入念に設計されたテスト自動化を活用します。

実際には、継続的デプロイメントによって、開発者によるアプリケーションへの変更は、作成してから数分以内に実稼働できます (自動テストに合格した場合)。これにより、ユーザーからのフィードバックを継続的に受け取って反映することが簡単になります。これらの CI/CD の作業習慣をすべて連結すると、アプリケーションのデプロイメントのリスクを低下させ、アプリケーションへの変更を一度に全部リリースするのではなく、少しずつリリースできるようになります。もちろん、CI/CD パイプラインのさまざまなテストおよびリリースステージに合わせて自動化テストを作成する必要があるため、まとまった事前の投資も必要です。

CI/CD パイプラインの構成要素

Automation

CI/CD requires custom coding and working with multiple software packages. Ansible is an open source automation language with all these capabilities in one composition.

Services

Speed up your next app development project. Our experts will guide your team to make use of innovative open source technologies, build prototypes, and solve the most vexing issues.

CI/CD についてさらに詳しく知る