CI/CDパイプラインとは？

DevOps (デブオプス)とは、開発と運用の間で人、手法、ツールを連携させることでチーム間の分断を防ぐソフトウェア開発手法を指します。DevOpsを導入すれば、ソフトウェア開発(アプリケーションコードの作成)とIT運用(アプリケーションの本稼動、エンドユーザーへの提供、保守)のギャップを埋めることができます。他にも、ITインフラ管理での要求にすばやく対応できるようにすることで、デプロイとアップデートの頻度を増やして、アプリケーションやサービスの開発を加速させ、業界内での競争力を維持できます。

DevOpsが注目される要因の1つが、アジャイル開発の導入が進んだことです。アジャイル開発ではアプリケーションの開発とコードのアップデートをより頻繁に行いますが、従来のプロセスではテストとデプロイに時間がかかってラピッド開発の利点が台無しになるという重大な問題がありました。アジャイルの原則の適用範囲をソフトウェア開発ライフサイクル(SDLC)全体に拡大するDevOpsなら、継続的な改善を目標としてワークフロー全体を最適化できます。DevOpsがうまく機能すると、コードのイテレーションとデプロイを加速するだけでなく、新しいアイデアを市場に投入するまでの時間を短縮し、バグを低減して、インフラの安定性を向上させることができます。

CI/CDはDevOpsの基盤となるプロセスです。開発者は、新しいコードをメインのソースコードに定期的に(通常は1日1回)統合します。新しいコードを中央の共有リポジトリにチェックインすると、自動ビルドプロセスによって変更内容がテスト、検証されます。そこで問題が検出されると、開発者にただちにフィードバックされるため、必要な修正を加えることができます。

CI/CDパイプラインは基本的に、DevOpsチームがソフトウェアのデリバリープロセスを自動化するための道筋を提供するワークフローです。自動化パイプラインがない場合、チームメンバーはワークフローを各自手動で実行する必要があるため、時間がかかり、ミスも発生しやすくなります。CI/CDパイプラインを構築すれば、人的ミスを排除し、開発者のフィードバックループを標準化して、イテレーションのスピードを向上させることができます。

CI/CDの前身となったモデルに、アプリケーションリリースの自動化(ARA)と自動リリース管理(ARM)があります。どちらも「リリース自動化」の作業カテゴリに分類され、自動プロセスの進化の過程で生まれ、この分野の流れを象徴しています。

CI/CDパイプラインの手法や導入方法に標準はなく、パイプライン構築に使用するツールやサービスはDevOpsチームによってさまざまですが、一般的にパイプラインには以下のステージが含まれます。

ソースステージ：開発者が、GitHubなどの中央リポジトリに保存されたアプリケーションのソースコードをチェックアウトし、ローカルの開発環境で作業を行います。新しいブランチを作成し、機能実装やバグ修正を行って、ローカル環境でテストを実施してから、ソースリポジトリにコミットします。

ビルドステージ：ソースリポジトリに新しいコードをコミットすると、ビルドステージが開始されます。このステージでは、ブランチのコードが集められ、コンパイルされて、実行可能なリリースインスタンスが構築されます。開発者は、担当するリリースを1日に何度でもビルドし、テストして、コード内のエラーを検出できます。ビルドが失敗したときやその他の問題が発生したときはアラートが送られるため、問題をただちに修正できます。すべてのエラーが解消されたら、次のステージに進みます。

テストステージ：ビルドでは複数のテストが実行され、コードが正しく動作するかどうかが検証されます。一般的なテストには、アプリケーションを構成するコードを小さい単位で個別にテストする単体テストと、本番環境へのデプロイ前にユーザーがアプリケーションをテストして他に変更が必要ないかどうかを判断するユーザー受け入れテスト(UAT)があります。負荷テスト、セキュリティテスト、その他の継続的なテストをこのステージで行うこともあります。

デプロイステージ：本番環境へのリリース準備ができたアプリケーションのデプロイには、さまざまな方法があります。どれを選択すべきかは、アプリケーションのタイプ、変更の規模、ターゲット環境などの要因によって変わります。クラウドアプリケーション向けの最新のデプロイアプローチには以下のものがあります。

• ローリングデプロイ：アップデートしたアプリケーションを段階的にデプロイし、最終的にすべてのターゲットに導入します。ローリングデプロイでは、ダウンタイム発生のリスクが低く、ロールバックが容易ですが、サービスで新旧バージョンのアプリケーションを同時に実行できる必要があります。
• ブルーグリーンデプロイ：新旧バージョンのアプリケーションを別々のインフラで並行して実行します。安定している旧バージョンを本番環境(ブルー)で実行し、新バージョンをステージング環境(グリーン)で実行します。グリーン環境で新バージョンの機能とパフォーマンスをテストし、合格したら、ブルー環境からグリーン環境にトラフィックを切り替えて、グリーン環境を新たな本番環境にします。ブルーグリーンデプロイは、すばやく簡単に導入できますが、本番環境が複雑な場合はグリーン環境を用意するのにコストがかかることがあります。
• カナリアデプロイ：一部のユーザーにアプリケーションをリリースし、実際の使用感についてフィードバックを提供してもらいます。アップデートしたアプリケーションが正しく機能することを確認したら、すべてのユーザーに展開します。カナリアデプロイでは、実際のユーザーに新旧バージョンを同時に試してもらうことができ、アップデートやロールバック時にダウンタイムが生じません。
  

パイプラインのどのステージでも、エラーが発生したときは開発チームにアラートが送られるため、問題にすばやく対処できます。修正したコードは再びパイプラインに送られるため、エラーをすべて解消した状態でコードを本番環境にデプロイできます。

継続的デプロイは、変更したコードを本番環境へ自動的にリリースするデプロイプロセスです。CI/CDパイプラインの中では、変更したコードが統合され、承認を受けた後で実行されます。変更したコードに対して一連の自動テストが実行され、すべてに合格すると、ユーザーにただちにプッシュされます。

継続的デプロイと継続的デリバリーはどちらも「CD」と略記され、同じものに思えるかもしれませんが、異なるプラクティスです。継続的デリバリーは、新しいビルドを自動QAテスト環境に自動的にプッシュしてバグなどの問題がないかを検証して合格すると、デプロイの承認を人が行い、エンドユーザーに自動的にプッシュするデリバリープロセスです。この最終ステージで人が介入することなくデプロイまで行うプロセスを、継続的デプロイと呼びます。

継続的デプロイではCI/CDのアジリティとスピードが向上しますが、最終テストからユーザーへのリリースの間に人の介在がない点にリスクがあります。そのため、機密データのセキュリティ、規制コンプライアンス、大きな経済的利害が関わるソフトウェアには適しません。

CI/CDを導入すれば、ソフトウェア開発を自動化、効率化して、アプリケーションやサービスをより短期間で頻繁にリリースできます。CI/CDで特に重要な役割を果たすのが自動化で、テスト、フィードバック、コード修正、デプロイの迅速化に大きく貢献します。

CI/CDプラクティスの導入にはさまざまなメリットがあります。

リリースのスピードと信頼性の向上：CI/CDの最も明確なメリットが、ソフトウェアデリバリーの時間短縮とプロセスの効率化です。テストとバグ修正の多くを自動化できるため、開発者はコードの記述とアプリケーションの品質改善に集中できます。

バグ検出の効率化：CI/CDパイプラインの各ステージでテストが自動実行されるため、開発者はバグなどの問題が入り込んだ時点(多くは初期段階)で問題に気づくことができます。これにより、デプロイの段階になって大きな手戻りが発生するのを防ぐことができます。

可視性の向上：CI/CDパイプラインでは、ビルド、テスト結果、コーディングミスを詳細に分析できます。そのため、どの変更が問題やパフォーマンス低下につながっているかを明確に理解し、問題が再発しないように対策できます。

フィードバックループの高速化：CI/CDでは、ユーザーとの継続的なフィードバックループが確立されるため、開発者はアプリケーションの新機能の開発やエクスペリエンスの改善にユーザーの声を反映できます。

コストの削減：CI/CDの自動化アプローチにより、開発プロセスの各ステージでエラーを大幅に削減し、発生したエラーをすばやく修正できます。そのため開発者は、時間のかかる手動作業に追われることなく、コード品質の改善とアプリケーションの改良に注力し、ROIの向上につなげることができます。

顧客満足度の向上：リリースの信頼性を向上させ、アップデート、バグ修正、新機能の追加のサイクルを速めれば、顧客からの評価の点で競合のアプリケーションやサービスの優位に立てます。

CI/CDパイプラインのオーケストレーションと実践方法に決まりはありませんが、以下の基本的なガイドラインに従えば、よくある問題に対処し、自社にとって効果的なパイプラインを維持できます。

環境の一貫性を保つ：CI/CDパイプラインの信頼性を高めるには、特定のインプットに対して常に同じアウトプットが生成される必要があります。実行のたびにパイプライン環境が変わって、同じパイプラインを維持するために隔離した環境で各ワークフローを始めなければならないようでは、信頼は得られません。

パイプライン分析を適用する：パイプライン分析では、CI/CDプロセスから収集されたテレメトリを可視化して、透明性を高め、測定能力を向上させることができます。これにより、デリバリーパイプラインの動作状況を明確に把握できます。

早い段階で頻繁にコミットを行う：変更を早い段階で頻繁にコミットすれば、検証するコードが少なくて済み、バグを発見しやすくなります。この「スモールバッチ」のアプローチは、コードの品質向上と効果的なイテレーションにつながります。

ビルドを1回に抑える：効果的なCI/CDパイプラインを構築するには、CI/CDサイクルの最初のステップにビルドプロセスを組み込み、ビルドを1回だけ実行して、その出力をパイプライン全体で使用します。1つのビルドで作業することにより、パイプラインのステージを進む中で不整合が新たに生じるのを防ぐことができます。

バージョン管理を導入する：バージョン管理システムは、ソースコードの保管、コード変更の追跡、必要に応じた過去のデプロイへのロールバックに欠かせません。バージョン管理は、アプリケーションに必要なスクリプト、ドキュメント、ライブラリ、設定の管理にも使用します。

段階的に開発する：機能をより小さいサブ機能に分け、それぞれ独自のフィーチャーフラグを実装して、小規模なイテレーションを繰り返すことで、問題の切り分けが容易になり、機能を本番環境にデプロイする段階で統合の問題が発生するリスクを減らすことができます。

CI/CDプロセスを導入する上で覚えておくべきポイントがいくつかあります。

CI/CDは製品ではなくワークフローであり、デプロイプロセスであることを理解する：「適切なツールを使う」という考え方に囚われないようにしましょう。CI/CDプロセスを導入する目的は、従来の手動による煩雑で時間のかかるソフトウェア開発プロセスから、自動化された効率的で高速なプロセスへと転換することです。まず、出発点を決め、自動化に関心の高い開発者と運用担当者を集めてPoC (概念実証)を実施してから、イテレーションの要領で段階的にパイプラインを構築していきます。

成功のための計画を立てる：技術面については、プラットフォームの選定から、イテレーションで効率的にアップデートできるようにするためのアプリケーションのリファクタリングまで、さまざまな計画を自然と立てることになります。一方で、関心が高い人だけでなく組織全体にCI/CDを浸透させるには、文化面にも気を配る必要があります。長期的な成功を目指すには、ITリーダーとビジネスリーダーからの賛同が欠かせません。

プロセスを最適化する：既存のデプロイパイプラインにCI/CDツールを導入する前に、ある程度時間をかけて現在のプロセスとワークフローを評価します。現在のプロセスが効果的でなければ、ただ自動化しても大きな改善は見込めません。その場合は、新しいCI/CDパイプラインに統合する前にプロセスを見直しましょう。

継続的な改善を重視する：CI/CDの導入には、間違いから学んで継続的に改善するという姿勢で取り組みます。また、CI/CDツールで継続的に測定されるメトリクスを単一の共通ダッシュボードにまとめて、関係者全員が状況を把握して必要な調整を判断できるようにすることも重要です。

アマゾン ウェブ サービス(AWS)とGoogle Cloud Platform (GCP)は、DevOps-as-a-Service (DaaS)プラットフォームとしても人気があります。どちらにも独自のメリットとデメリットがあります。

AWSは一般的に高速で、DevOpsのクラウド移行と運用が容易であり、便利な従量課金モデルを利用できます。GCPはアプリケーションライフサイクルのパイプラインで利用できるツールが充実していて、Stackdriver Monitoring、Stackdriver Debugger、Stackdriver Logging、Security Scannerサービス(App Engine)などが用意されています。

どちらもDevOpsソリューションとしては十分な機能を備えているため、選択のポイントとなるのは価格と運用面でしょう。

開発ツールチェーンに追加するCI/CDツールを選定するときに考慮すべきことがいくつかあります。

まず、オープンソースのツールを使用するか、商用のツール(コードのデリバリー)を使用するか、または独自のツールを開発するかを検討します。オープンソースツールを使用する場合はコストを節約できますが、ツール自体のコードが大幅に変更されたり開発が中止されたりするリスクがあります。また、多くの場合は最小限のサポートしか提供されません。一方、商用ツールを使用する場合は、通常、サポートが充実し、アップデートも定期的に行われますが、コストがかかり、統合の柔軟性に欠けます。独自に開発する場合は、組織のニーズに合ったツールを構築できますが、多くのリソースが必要になります。

もう1つの考慮事項はホスティングモデルです。コードベースをオンプレミスに残す必要がある場合は、オンプレミスのサーバーまたは仮想インフラに導入できるツールチェーンが必要です。しかし、多くのCI/CDツールはクラウドとクラウドネイティブインフラで使用することを想定しています。この場合、ベンダーのクラウドインフラで運用されるSaaS (Software-as-a-Service)モデルの一部としてCI/CD環境が提供されるため、組織側は運用コストをかなり軽減できます。

さらに、上記のどのオプションを選択する場合でも、関連コストを考慮する必要があります。オープンソースツールは導入コストを節約できますが、組織のインフラでのツールの設定やサポートにコストがかかり、開発者が使い方を覚えるまで生産性が多少低下します。商用の汎用的なツールやSaaSツールでは、一般的に、従量課金が採用されています。

組織に最適なオプションの選択は、最終的に、通常のビルド件数、ビルドの同時実行が必要かどうか、ツールを利用するユーザー数によって決まるでしょう。

ソフトウェアのリリース頻度は市場での大きな差別化要因です。成功している企業は1日あたり50～100件のデプロイを行い、Netflix社のような巨大企業になると1,000件にも及びます。効果的なCI/CDパイプラインを導入すれば、生産性、信頼性、スピードを向上させてこうした数字を達成し、必要とされるアプリケーションを適時に提供して、変化の激しいビジネスニーズに対応できます。逆に、CI/CDプラクティスを実践しないと、市場で取り残されるリスクがあります。ソフトウェア開発プロセスの転換は容易でなく時間もかかりますが、それだけの価値はあり、今後数年間の競争力維持に欠かせません。