継続的インテグレーション (CI) とは？

CI（継続的インテグレーション）の概要

CIとは、Continuous Integrationの略であり日本語では「継続的インテグレーション」として知られています。継続的インテグレーションはデプロイするコードの品質を確保しながら、開発スピードを向上させる DevOps（デブオプス） ソフトウェア開発手法です。開発者は継続的にコードを少しずつ (少なくとも 1 日 1 回、可能なら 1 日に数回) コミットし、そのコードが共有リポジトリ（マスターブランチ）にマージされる前にビルドとテストが自動的に実行されます。また、継続的インテグレーションを実現する流れを CI/CDパイプラインと呼びます。CI/CDパイプラインに関する詳しい情報はこちらをご覧下さい。

CI(継続的インテグレーション)の仕組み

• 開発者は 1 日 1 回またはそれ以上の頻度で、共有メインライン コード リポジトリにコミットを行う。
• コミットのたびに、コードベースの自動ビルドと自動テストがトリガーされる。
• ビルドやテストが失敗しても、数分以内にすばやく修復できる。
• 開発チームの生産性の向上実現。
• コードバグの発見と修正が最短時間で実現する。

CI（継続的インテグレーション）は、アジャイル手法と密接に関係しています。チーム メンバーは小さく分割された一連の「ストーリー」に取り組み、ソフトウェアの変更コードは、共有ソフトウェア リポジトリに 1 日に何度も少しずつマージされます。

CIの導入メリット

CI の基本的な考えは非常にシンプルで、頻繁に、少なくとも毎日、コードをコミットして統合します。ソフトウェア開発プロセスでは、このような小さな変更が、ときに大きな成果を企業にもたらします。

この開発戦略には次のようなCIのメリットが期待できます。

• チームの生産性向上と効率化
• 市場投入までの時間短縮
• プロダクト マーケット フィットの検証
• より高品質で安定した製品のリリース
• 顧客満足度の向上
• 開発意欲の維持とコード配信の継続

ワークフローの簡単な変更からこのようなメリットが得られる理由

コミットの頻度を高めれば、マージの競合を早期に発見して解決することや、完全に回避することも可能になります。つまり、1,000 行のコードを書いてからエラーを見つけ出そうとするのではなく、100 行書いただけでコミットしていくのです。そうすれば、コード内のバグ探しが、数時間ではなく数分で済みます。これがチームの生産性向上につながり、作業したコードをより迅速にリリースできるようになります。

新機能を迅速にリリースできるということは、市場投入までの時間が短縮されるということです。これにより、次の 2 つの重要な点で競争力を高められます。

1. 顧客が新機能をすぐに利用できるようになり、顧客満足度の向上につながります。
2. 企業としては、新機能の投資回収期間が短くなります。次のマイルストーンまでリリースを待つのではなく、新機能の準備が整ったらすぐに市場に投入して価値を実現できます。

継続的インテグレーションは、多くのソフトウェア プロジェクトに適用できます。たとえば、CircleCI では Web サイトの更新にCIを採用しています。

1. 開発者 (またはコンテンツ発行者) がコードの新しいブランチを GitHub に作成し、ページの HTML を更新して、変更をコミットします。
2. そのブランチの変更がすべて完了したら、開発者が GitHub にプル リクエストを作成します。
3. GitHub と CircleCI を連携させているため、コードを基に CircleCI でビルド プロセスが実行され、その後に自動テスト スクリプトが実行されます。
4. CircleCI でエラーが発生した場合 (ビルド ステータスがレッド)、開発者にその旨がメールで通知されます。
5. エラーが発生しなければ、ビルドが成功して (ビルド ステータスがグリーン)、コードがステージング サーバーにプッシュされたことが通知されます。これで、開発者は Web ページのプレビューを確認できるようになります。
6. 検証が完了したら、開発者は新しいブランチのコードを本番環境にマージできます。

CI/CD を組織に導入する方法

アプリケーション開発のできるだけ早い段階で継続的インテグレーション (CI) パイプラインを整備することが重要です。CI パイプラインにテストを追加すれば、テストに合格しないコードはメインのブランチにマージされなくなるため、開発者は安心してイノベーションと開発に打ち込むことができます。また、継続的デプロイメントのワークフローを CI パイプラインに組み込むことで、デプロイメントの自動化が可能になります。CircleCI を利用すれば、ソフトウェアのビルド、テスト、デプロイメントを自動化でき、エンジニアはユーザーにとって特に重要な機能の構築に集中できます。

CI/CDツール導入のステップ

1. 全員の認識を統一する。新しい CI/CD ツールを導入する目的について意識の統一を図ります。

2. 必ず小さなところからスタートする。一夜にして理想的な DevOps チームを作り上げることはできません。まずは 1 つのチームでプロセスを変更し、その変更が組織内で有効かどうかを確認しましょう。改善が見られたら、少しずつ進めていきます。

3. 自分たちに適しているかどうか見極める。組織によっては DevOps が適していない可能性があることも理解しておきましょう。実際、DevOps を導入しなくても長年成功を収めている企業も存在し、そうした企業にとっては社内文化や製品に対するニーズなどの面から DevOps が最適なソリューションとは言えないのです。たとえば、製品戦略において機密性が特に重要になる企業では、段階的に配信を行ってフィードバックを集めるのは現実的ではありません。大規模なリリースを行うまで、製品についてのすべての詳細を秘匿しておく必要があるからです。そのような環境で DevOps の文化を築くことは非常に難しいでしょう。

4. 常に測定する。改善計画を実行に移す前に、現状を正確に測定しておきます (開発サイクルには○時間かかっているなど)。サイト信頼性の担当エンジニアを開発チームに招集するよりも、まず指標を測定しましょう。少し時間がたてば、取り組みの効果を確認できます。一例を挙げると、アジャイル手法による変革が盛んに行われていたころ、多くの企業がスタンドアップ ミーティングを採用しましたが、その必要性をよく理解していないケースや、実施効果を測定していないケースが目立ちました。これでは、スタンドアップ ミーティングによって時間が節約されたどころか、無駄になっていたかもしれません。

5. なんでも自動化しようとしない。少なくとも一度にすべてを自動化するのはやめておきましょう。DevOps に関して、インフラストラクチャのプロビジョニングと構成管理をすべて自動化しなければならないとお考えの方もいらっしゃるようですが、これは誤解です (こうしたインフラストラクチャは「コードとしてのインフラストラクチャ」と呼ばれます)。中には手動のほうがうまくいくこともあり、自動化がすべての最適解となるわけではありません。場合によっては、手動の方法から始めて、実際に何が最良の自動化ソリューションとなるのかを見極めなければならないこともあります。

継続的インテグレーションは、新しいツールを導入して終わりではありません。その本質は、開発チームの仕事の進め方を変え、新たなマインドセットを形成することです。そして、組織の文化を変えるのは簡単な道のりではありません。継続的インテグレーションを始めるにあたっては、小さなところからスタートしていくのが最善の方法となります。

今後予定している小規模なプロジェクトで概念実証を行い、次のような基盤を整えましょう。

• 厳格なテスト手法、理想としては自動テストの実装
• テストから本番環境まで、一貫性のあるソフトウェア環境
• 継続的インテグレーションの実践に関するトレーニング
• 重要な測定指標に関するレポート

定期的に小さな増分ごとにコミットするようになると、バグへの対応がとてもスムーズになることが実感できるはずです。すばやくバグを解決できれば、機能の配信もスピードアップできます。その勢いに乗って、継続的インテグレーションを組織全体へと拡大していきましょう。

CI/CD に最適なCIツール

DevOps とは、開発チームと運用チームの連携関係に特化した手法です。基本的には、文化的な観点から、インフラストラクチャに開発手法を適用し、開発サイクルに運用手法を適用します。具体的な内容を説明すると、インフラストラクチャをコードとして管理することや、再利用可能なコンポーネントを構築してイミュータブルなインフラストラクチャを作成すること (いつでも分解・破棄でき、バージョン管理や変更履歴の記録も容易です) が挙げられます。また、すべてのプロダクト コントリビューターたちが「製品が世の中でどう役に立っているのか」「ユーザーはどのように操作しているのか」など、自身が進めている作業の最終的な結果にもっと関心を持つようになります。本気で品質を意識すれば、ビジネス価値とユーザビリティの両方を意識することになります。これこそ、DevOps 導入による真の成果です。

こうした手法を採用するには、広範囲から支持を取り付けなくてはならず、さまざまなスキルや専門知識を持つ人々の助けが必要になるため、ソフトウェア開発チームにとっては特に難しいでしょう。それでも実現するには、部門を超えた 1 つのチームとして、配慮あるコミュニケーションを心がける必要があります。たとえば、エンジニアがデータベースの問題についてビジネス サイドのだれかと話すときには、単に作業に関連するデータを提示するだけでなく、必要な背景情報も伝え、問題意識を持つべきポイントやその理由について強調することが大切です。

では以上を踏まえて、新しいツールを導入する必要があるか考えてみてください。必要だと言い切れない方もいらっしゃるのではないでしょうか。ツールは、手っ取り早い手段のように思えることもありますが、どんな状況にも使える万能の武器というわけではありません。新しい DevOps ツールを導入する前に、こうしたポイントを踏まえておくと、成功の確率が高まるでしょう。チームにとって一番適したツールが、ベストな CI/CD ツールなのです。

関連記事

DevOps への移行: 本当に必要なツールとは – June Jung
新しいツールをチームに導入する方法 (そしてその過程でつぶされないようにする方法) – Emma Webb

CI、CD、継続的デプロイメントの違い

• 継続的インテグレーション(CI) 新しいコミットごとに自動でアプリケーションのビルドとテストを行います。

• 継続的デリバリー(CD) アプリケーションをいつでもデプロイできる状態にします。実際にアプリケーションをデプロイするには、手動の操作が必要です。

• 継続的デプロイメント ビルド、テスト、デプロイメントを自動で行います。すべてのテストに合格すると、新規のコミットごとに新しいコードが開発パイプライン全体を通過して本番環境にプッシュされます。手動の操作は介在しません。

CI/CD関連記事

CI/CDパイプラインとは？ – Molly Fosco 氏
継続的デプロイメント – Timothy Fitz 氏
継続的デリバリー – Wikipedia
CIツールの比較一覧 – 勢理客 那帆
アジャイルとは？ – 勢理客 那帆
ウォーターフォールとは？ – 坂本 裕樹
DevOps（デブオプス）とは？ – 中林 優菜
CI/CD とは？ – 勢理客 那帆

継続的インテグレーション(CI)と継続的デプロイメント(CD)

継続的インテグレーションは、ソフトウェアのビルドとテストを自動化する手法です。継続的デプロイメント(Continous Deployment)は、この自動化の延長線上にあり、コードのコミットが毎回テスト スイートに合格しなければ、ソフトウェアはデプロイされません。特に大きな成果を収めている開発チームでは、高い頻度でソフトウェアをデプロイしています。

ソフトウェア開発プロセスは、主に 3 つの作業で構成されます。

1. コードの作成: ソフトウェア開発チームの創造性が最も発揮される場面です。ユーザー ストーリーを洗練されたコードに落とし込みます。

2. ソフトウェアとしての「新しいコードのオーケストレーション」: 継続的インテグレーションの核心はここにあります。開発者がコードをコミットすると、継続的インテグレーションのビルド サーバーがビルド、テスト、デプロイメントのプロセスを自動的に実行します。

3. 配信: 新しいソフトウェアを本番環境にリリースする最終ステップです。この段階では、本番環境でのソフトウェアの監視と管理を行うツールが使用されます。

コードの作成で最も重要なツールは、コードを保持しておくために使用されるリポジトリです。CircleCI は GitHub や Bitbucket と連携しています。CircleCI のサーバー ソリューションなら、GitHub Enterprise とも連携が可能です。

CircleCI は、オーケストレーションの段階で機能し、コードを有効なソフトウェアに変換するという、最も負荷の大きい作業を担います。ユーザーは、YAML ファイルを介してコードを処理する方法を構成します。YAML ファイルはコードで設定でき、ほぼあらゆることを際限なく構成できるため、開発チームは思いのままにビルドとテストを実行できます。

配信では、テストと承認が完了したコードが本番環境に展開されます。これには、運用サーバーのセットアップ、構成、管理が含まれます。継続的インテグレーションのメリットを最大限に引き出すには、継続的デプロイメントが欠かせません。

クラウド ホスト型とオンプレミスの継続的インテグレーション

CircleCI はクラウド マネージド サービス (SaaS) として提供されています。また、お客様のプライベート インフラストラクチャのファイアウォール内で CircleCI を実行していただくことも可能です。

オープンソース プロジェクトの CI/CD

CircleCI は、Linux のオープンソース プロジェクト用に毎月 400,000 クレジットを Free プランのお客様に提供しています。ご利用条件は、リポジトリを公開することだけです。Free プランを使用して macOS でビルドを行っている組織にも、毎月 25,000 クレジットが無料で提供され、macOS オープンソース プロジェクトのビルドに利用できます。ご希望の方は、billing@circleci.com までお問い合わせください。

継続的インテグレーションのベスト プラクティス

継続的インテグレーションを実践している開発者は、早い段階から頻繁にコミットしています。そうすることで、コードを本番環境にデプロイする前に、競合を検出できます。また、より小規模にコミットすることで、問題が発生した場合のトラブルシューティングが容易になります。ただし、ソフトウェアを毎日、またはそれ以上の頻度でコミットすることは、継続的インテグレーションには必要ですが、それだけでは十分ではありません。

継続的インテグレーションを成功させるには、次のことを行う必要があります。

• テストを開発プロセスの一部として不可欠な要素とする(テストは、コードの作成と同時に記述するべきです)
• テスト環境が本番環境を反映したものとなるよう徹底する
• ペア プログラミングなど、コーディングのベスト プラクティスを採用する
• デプロイメントのワークフローを自動化する

厳格なテスト文化を育むことは、企業が継続的インテグレーションを成功させるうえで必要となる最も重要な要素です。自信を持って新しいコードをメインラインに統合するためには、コードが正常であるという確信が必要となります。エンジニアは、各機能の開発中にテストを記述するべきです。CircleCI では、新しいコードがコミットされるたびにテストが実行され、ビルドがグリーン (成功した) か、レッド (失敗して問題の修正が必要) かが開発者に通知されます。テストを実行しないのであれば、ビルドが成功しても意味がありません。自動化されたテストを活用するのは必須ではないものの、理想的と言えます。Rainforest QA などの QA サービスを継続的インテグレーションのプロセスに組み込むのもよいでしょう。

厳格なテストの文化を支えていくには、テスト環境が本番環境を反映していることが重要です。そうでなければ、テストしているものが本番環境で動作するという保証はありません。つまり、テスト環境のデータベース、Web サーバー構成、アーティファクトなどは本番環境のものと同じである必要があります。

ソフトウェア開発のもう 1 つのベスト プラクティスは、ペアでコーディングすることです。複雑な機能については、1 行のコードを記述する前に、アーキテクチャのアプローチについてペアで議論を行います。コードを本番環境にマージする前には、常に別の開発者がコード レビューを行います。これにより、コーディングのベスト プラクティスが適用されていること、コードが既存のコードまたは別の開発者が作業しているコードと競合していないこと、新機能が拡張可能であることを確認できます。

さらに、ソフトウェア開発パイプライン全体を高速かつ効率的にするためには、デプロイメント ワークフローも自動化する必要があります。そうすることで、完成したコードをより迅速に本番環境に展開できます。ソフトウェアを短時間で開発できても、顧客の手元に届けなれば意味がありません。

継続的インテグレーションを追跡するための重要な指標

継続的インテグレーションは、どのソフトウェア開発チームにとっても価値のある目標です。しかし、目標を達成したかどうかを確認するにはどうすればよいでしょうか。そこで出番となるのが、重要業績評価指標 (KPI) です。ソフトウェア開発ライフサイクルの改善を図るなら、それを構成するプロセスについて測定する必要があります。そうすることで、プロセスの変更が効果を生んでいるかかどうかがわかります。

以下に、ソフトウェア開発について測定する 4 つの KPI を紹介します。

• リード タイム: 最初のトリガーからワークフローの完了までにかかる実行時間の長さです。実行結果のシグナルをどれだけ速く取得できるかを示します。リード タイムを短くするには、極限まで自動化されたソフトウェア開発パイプラインが必要です。だからこそ、ビルドやテストを自動化するために継続的インテグレーション (CI) を行うのです。CI によるパイプラインの自動化によって、数週間から数か月かかっていたデプロイメントのタイムラインが、数分とまではいかなくても、数時間に短縮されます。

• デプロイメントの頻度: ワークフローを開始する頻度は、どれくらいの数の個別の作業が開発パイプラインを通過しているかを示す指標となります。完全に自動化されたソフトウェア開発パイプラインでは、コードベースへの複雑な更新も自動的にデプロイできます。ホットフィックスで あっても、他の更新と同様に厳格なテストを経て速やかに配信できます。

• 平均復旧時間 (MTTR): 復旧までにかかる時間は、有用な情報をどのくらい迅速に入手できるかによって変わります。失敗したというステータス情報をすばやく取得できれば、エラーの状態から最短時間で正常に戻すことができます。CI/CD を導入することは、高速なフィードバック ループを実現するカギとなるので、開発者に迅速かつ確実にシグナルを伝える最善の方法と言えます。CI/CD をしっかりと実践するには、テスト スイートのログやカバレッジ レポートなどのリアルタイムのアーティファクトを作成することも求められます。それによって、開発者は本番環境と同等の環境でトラブルシューティングを行えます。

• 変更の失敗率: 優れたパフォーマンスを誇るチームが不良コードをデフォルト ブランチにプッシュすることは稀です。しかし、そうしたチームが欠陥のあるコードを決して記述しないというわけではありません。テストとセキュリティ チェックを別のブランチで実行し、すべてが成功した場合にのみマージが許可されるようにすることをお勧めします。コードをデフォルト ブランチにマージする前に、そのコードが正常に動作することをきちんと確認するべきです。

定期的にレポートを作成するとよいでしょう。日次レポートの作成を自動化しておくと、エラーの発生をすぐに検知できます。また、週次レポートを分析することで、CI プロセスを掘り下げて振り返り、改善点を見つけることができます。

2022 年版ソフトウェアデリバリーに関する現状調査レポートをダウンロード

テストを CI/CD パイプラインに組み込む

テストにはいくつかの種類があります。

単体/コンポーネント テスト

可能な限り最小のコンポーネント、ユニット、機能を対象とします。依存関係やモックをあまり必要としないため、実行コストが最も低い最速のテストです。パイプラインの早い段階で実行して終わらせる必要があります。

結合テスト

前のステージから移行された各ユニットが他のコンポーネント、ユニット、機能と連携してどの程度正常に動作するかを確認します。広義では、サービス (API など) が正常に相互連携できるかどうかのテストを指します。

UI レイヤー テスト

自動化されたブラウザーベースのテストで、基本的な UI フローを確認します。セットアップにコストがかかり、実行に時間がかかるため、パイプラインの後半で実行します。

では、これらのテストがソフトウェア開発パイプラインにどう組み込まれるのかについて説明します。テストごとに個別の役割があり、実行する場所が決まっています。