継続的インテグレーション (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. 検証が完了したら、開発者は新しいブランチのコードを本番環境にマージできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CI/CD関連記事

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

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

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

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

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

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

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

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

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

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

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

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