継続的インテグレーション（CI）とは

継続的統合は、ソフトウェア提供プロセスを効率化する自動化されたDevOpsワークフローであるCI/CDパイプラインの最初のステップです。継続的統合により、DevOpsチームはソフトウェア・アプリケーションを継続的に改善し、一貫したフィードバックを受け取り、エラーがソフトウェアの性能に影響を与える前に検出して修正し、より高品質なソフトウェアを予測可能なスケジュールで提供できるようになります。

開発者がバージョン管理システムのメイン・ブランチや共有ブランチにコード変更をコミットすると、そのアクションによりCIツールがトリガーされ、更新されたコード・ベースの「ビルド」が実行されます。CIシステムは、新しいコードを取得し、既存のコードとコンパイルを実行し、設定ファイル、ライブラリ、その他のリソースなどの依存関係とともにパッケージ化を行います。これが「ビルド」を構成しています。

「ビルド・アーティファクト」（さらなるテストまたは運用環境に渡される結果のファイル）が作成される前に、このビルドを検証するために自動テストが実行されます。パイプラインのこの次の工程は、継続的デリバリーと呼ばれます。

CIは、従来のソフトウェア開発、つまり統合およびデプロイメントプロセスに関連する課題に対するソリューションとして作成されました。従来の開発パラダイムでは、各開発者は新しいコードをアプリやサービスの新しいイテレーションに手動で統合する責任を負っていたため、特に大規模な開発チームの場合には、統合に時間がかかり、エラーが発生しやすいプロセスになっていました。

異なるコード同士が常にうまく連携するとは限らないのと同時に、開発者はさまざまなタイムラインで（場合によっては土壇場で）変更を組み込むので、統合の問題に関するフィードバックが遅れることは頻繁に起こりました。問題が発生した場合、フィードバックの遅延が原因でどの変更が問題を引き起こしたのかをチームが把握するのが難しくなり、デバッグがより骨の折れるプロセスになっていました。

さらに、ソフトウェアのテストはまれにしか行われていませんでした。チームは通常、大規模なバッチ更新を一度に実装していたため、不具合が見逃され、コードベースに蓄積されることがありました。その結果、開発チームはより困難なトラブルシューティング作業に直面し、失敗率が高まり、コードのリリースも遅くなりました。企業はプロセスの非効率によって収益を失い、ユーザーはソフトウェアのエラーや不具合をより多く目にすることになりました。

継続的統合は、現代のDevOpsの実践、継続的統合／継続的デプロイメント（CI/CD）パイプライン、およびマイクロサービス・アーキテクチャーの基盤となる要素で、統合性能に関する迅速なフィードバックを提供することで、ビルド・プロセスを効率化します。

CIシステムを使うと、新しいコードは中央リポジトリーに（通常は1日に複数回）追加されビルドとテスト用に同リポジトリーに残ります。システムがエラーを検知した場合、通知を送り、コードを修正し、更新されたコードが正しいことを確認してから、ソフトウェアのコードベースに完全にマージします。

継続的インテグレーション・システムの正確な構成は、チームごと、また企業ごとに異なりますが、いずれのCIシステムでもコード統合タスクを最適化するために、特定のコンポーネントとプロセスを用います。

CIはすべての開発者がコードをコミットする中央リポジトリーから始まります。中央リポジトリーは、CIプラクティスの基盤として機能します。多くの場合、GitやBitbucketなどのバージョン管理システム（VCS）がリポジトリーを管理しています。開発者が変更を送信すると中央リポジトリーが変更を追跡し、開発部門が効率的に共同作業をできるようにコード変更の完全な履歴を作成します。

リポジトリーでは分岐（ブランチ）手法も利用されます。これは進行中のコード変更をメイン・コードベース（メイン・ブランチ）から切り離して独立した開発ラインを作り、並行開発を容易にする仕組みです。分岐機能を使うことで、開発者は特定のアプリ機能を分離するための機能ブランチや、短期間だけ利用するブランチを作成し、それらをメイン・コード・ブランチにマージすることができます。

例えばGitflowは、Gitベースのブランチング・モデルで、異なるブランチに「main」「feature」「develop」「release」といった役割を割り当て、それらの相互作用を管理します。Gitflowのブランチでは、開発者はフィーチャー・ブランチを作成し、機能が完成するまでコード変更をメイン・ブランチにマージできません。

CIサーバーは、すべての継続的統合（CI）処理を一元化して管理するためのツールです。それらは、CIプロセスのオートメーションの中核として機能します。CIサーバーはリポジトリーを監視してコード変更を検出し、変更があれば定義済みのCIパイプラインを起動・実行します。CIサーバーは自動ビルド、テスト、ソフトウェアのリリースを実行し、バージョン管理プロトコルをオーケストレーションし、ステータス報告を処理し、システム機能を拡張できるプラグインをサポートします。

多くのCIサーバーには、チームがワークフローを設計・可視化し、継続的デリバリー（CD）パイプラインを構築するのに役立つユーザー・インターフェースが備わっています。

CIシステムでは、開発者が毎日数回コード変更を送信することを奨励し、特定のタスクや機能に対する小規模で的を絞った変更を優先します。CIツールを使用すると、チームは新しいコードをマージする前に、コードレビューを開始して問題について話し合うことができるため、開発プロセスの早い段階でエラーを検出できます。

例えば、GitベースのCIシステムは、プル・リクエストを開始して、ローカル・ブランチ（単一の開発者のコンピューターにローカルに保存されている）からコードの変更を取得し、それを現在のリモート・ブランチ（リモートに保存され、開発チーム全体で共有されている）に統合できます。また、マージ・リクエストを使用すると、開発者は、ローカル・ブランチで提案された変更を別のローカル・ブランチに統合し、リモート・ブランチとマージする前に、チームのレビュー、議論、承認を受けることができます。

継続的インテグレーション・サーバーとツール（Jenkins、CircleCI、GitHub、AWS CodePipeline、GitLab CIなどの一般的なオープンソース・ツールを含む）は、コードの変更を中央リポジトリーで監視します。新しい変更を検出すると、CIサーバーはビルド・プロセスをトリガーして、定義済みのワークフローとビルド・スクリプトを実行し、テスト（および最終的にはデプロイメント）の準備としてコードをコンパイルしパッケージ化します。

CIツールは、コードがコード・ベースにマージされる前に、さまざまなテストを実行してコードを検証します。ユニットテストは、個々のコンポーネントや関数を検証し、コードの動作に関するフィードバックを即座に提供します。統合テストは、ソフトウェア・コンポーネントやモジュール間の相互作用を評価し、それらが正しく連携して動作していることを確認し、ユニット・テストが見逃す可能性のある問題を検出します。

一部のCIワークフローでは、エンド・ツー・エンドのテストで、ユーザー操作のシミュレーションを行い、ソフトウェアがユーザーの視点から正しく動作しているかを確認して、ソフトウェアを検証します。またチームでは、コード品質テストと静的分析を実行して、負荷時のアプリケーションの応答性と安定性をチェックし、コーディング標準規格違反とセキュリティの脆弱性を特定することができます。

CIサーバーは、ビルドまたはテストが失敗した場合に、すぐに開発者に通知します。障害が発生した場合、開発者はコードを優先して修復し、メイン・ブランチがデプロイ可能な状態を維持できるようにします。

ソフトウェアのビルドが成功すると、サーバーは成果物（ビルドする過程で作成されたコンパイル済みのコード、Dockerイメージやライブラリーなどのファイル）を生成します。これらのファイルはバージョン管理され、今後のテストやデプロイメントのためにリポジトリーに保管されます。結果に関係なく、主要なCIシステムは統合の試行、成功率、その他のメトリクスをログに記録し、チーム・メンバーがいつでも包括的なバージョンのドキュメントにアクセスできるようにします。

テストは継続的インテグレーションのプロセスには欠かせない要素です。テストは少なくともCI作業の約3分の1を占めていますが、これはチームが単一のテスト・ステージを実行する場合にのみ当てはまります。多くの場合、テスト作業はCIツールのワークロードの大部分を占めます。

CI環境での継続的テストは、開発者がコード・ベースに新しいコードをコミットすると始まります。この動作をトリガーとしてビルドと自動テスト・プロセスが行われます。ビルド成果物が生成された後（コードが本番環境に移行する前）にはしばしば追加のテストが実行されます。開発者がローカル環境ですべてのテスト（およびテストのサブセット）を実行し、新しいコード変更がテストに合格した後にのみソースコードをバージョン管理にコミットすることが大切です。

さまざまな機能、ユースケース、統合を多角的にテストすることを総称して、テスト・スイートと呼びます。このアプローチにより、テスト範囲を最大化し、コードのリグレッションを防止し、継続的デリバリーを成功させるための基盤を築くことができます。

テスト駆動開発（TDD）はソフトウェア開発における別のアプローチです。TDDは開発者が「逆の順序で作業」することであり、コードを記述する前にテストを作成するアプローチです。開発者はこのアプローチで、ユニットレベルの失敗するテスト・ケースを作成してから、合格するための最小限のコードを記述します。これが完了すると、テスト用コードと本番用コードの両方をリファクタリングして改善できます。

このアプローチは開発者が明確に定義された要件に集中し、無関係なコードを書かないようにするために役立ちます。継続的なフィードバックも重視しており、開発サイクルを加速させるのに効果的な手法でもあります。

DevOpsパイプラインは、従来はそれぞれの独自のサイロに存在していた開発チームとIT運用チームの作業を自動化して組み合わせることで、迅速に高品質のソフトウェアを提供できるようにします。

DevOpsのプロセスと文化を成功させるには、開発と運用にとどまらず、プラットフォームとインフラのエンジニアリング、セキュリティ、コンプライアンス、ガバナンス、リスク管理、基幹業務、エンドユーザー、顧客を含める必要があります。言い換えれば、優れたDevOpsでは、すべてのアプリケーションの利害関係者からの意見をソフトウェア開発ライフサイクルに組み込む必要があります。

DevOpsフレームワークにおいて、継続的統合はソフトウェア開発プロセスおよびCI/CDパイプラインの最初に位置づけられます。CIにより、開発者は自分のコードを頻繁にチェックインでき、ローカルのコピーがコード・ビルドのメイン・ブランチから大きく乖離するのを防ぐことができます。このアプローチにより、チームはデリバリーやデプロイメントの段階でビルドを「壊す」原因となり得るマージ・コンフリクトを回避できます。

また、CIを使用すると、開発者は小規模かつ頻繁に更新を送信することで、顧客ニーズの優先順位付けに基づいた迅速で一貫性のあるフィードバック・ループと継続的な改善を促進できます。これはDevOps哲学の重要な原則です。

継続的統合はCI/CDパイプラインの最初の段階で、通常はこのあとに継続的デリバリーと継続的デプロイメントのプロセスが続きます。継続的統合とは、頻繁なコードのマージと、それに続くビルドおよびユニットテストを指します。

継続的デリバリー（CD）は、継続的統合が中断したところから再開し、検証済みのコードベースの変更（更新、修正プログラム、さらには主要な機能など）を特定の環境またはコードリポジトリに自動的に配信します。DevOpsチームは最新のビルドに関する通知を受け取り、更新内容を実際の本番環境に動き込むことができます。継続的デリバリーパイプライン段階の目標は、最小限の労力で新しいコードをデプロイすると同時に、コードが公開される前にある程度の人間による監視を可能にすることです。

継続的デプロイメントでは、コピーテキスト環境でコードをテストする統合テストなど、事前定義された一連のテストに合格した後、コード変更をエンド・ユーザーに自動的にリリースして、コードの整合性を確保します。継続的デリバリーと継続的デプロイメントはどちらも、CIよりもパイプラインの下流でのオートメーションを扱い、多くの場合同じ意味で使用されます。

継続的デリバリーと継続的デプロイメントの違いは、ソフトウェアまたはアプリのリリースに用いられる自動化の程度にあります。継続的デリバリーでは、リスクの評価やソースコードに潜む脆弱性の特定など、さらなるテストと品質保証を行うために、コードは自動的に疑似本番環境へ移されます。テストが成功した後に本番環境へ移行するには人間の介入が必要です。

継続的デプロイメントではさらなる自動化が行われます。コードがテストに合格すると自動的に本番環境へのデプロイメントが行われ、人間による承認は不要です。¹

アジャイル開発は、柔軟性、コラボレーション、継続的な改善、変化への迅速な適応を優先するソフトウェア・エンジニアリングの手法です。これは、開発を小規模の作業グループ、つまり「スプリント」に編成し、開発者と利害関係者の間のコラボレーションを効率化し、ソフトウェアの提供を加速する手法です。

同様に、CIでは頻繁な段階的なコード更新と継続的なコード検証が必要です。これは開発に対する反復的な手法であり、開発者はソフトウェア・ソリューションを時間の経過とともに迅速にアップグレードおよび拡張し、高品質の製品をユーザーにスピーディーに提供できます。そのため、継続的インテグレーションは本質的にアジャイルな方法です。

継続的統合は、開発チームが素早く反復を重ね、より良いソフトウェアをユーザーに届けることを可能にします。さらに、プロセスを最適化するために企業が実施できる追加の取り組みもあります。一般的に行われるCIプラクティスには次のようなものがあります。

継続的インテグレーション（より広義にはDevOpsフレームワーク）の実践は、企業が連携とコードの統合を合理化し、継続的デリバリーのパイプラインを維持するのに役立ちます。この方法の実践によりソフトウェアの品質が向上し、ソフトウェアのリリース・プロセスが加速します。最新のCIツールには、この実践を強化し、価値を高めるさまざまな新しい技術が組み込まれています。

例えば、継続的統合のプロセスに人工知能（AI）や機械学習（ML）を活用することは、標準的な開発手法になりつつあります。AI対応ツールは、問題のあるコードがメインの開発ストリームに影響を及ぼす前に自動的かつ自律的に検出・修正できる自己修復システムの構築を、開発者が実現するのに役立ちます。ML駆動型のCIシステムは、コードの提出や変更内容に基づいて最適化されたテストケースを自動生成できるため、開発者はコードテストを手作業で作成する時間を短縮できます。

サイバー脅威がますます巧妙になる中、² ソフトウエア開発プロセスに直接セキュリティー対策を組み込む開発者が増えています。こうした「シフトレフト」戦略では、CIプロセスを含む開発の初期段階にセキュリティー・チェックを導入し、デプロイメントの後ではなくコーディング中に脆弱性を確実に発見できるようにします。

今日、最新のIT環境の構成要素を形作っているのはKubernetesとより広範なコンテナ関連技術のエコシステムです。DevSecOpsはDevOpsのあらゆるフェーズにセキュリティーを組み込み、このような動的エコシステムに存在するセキュリティー上の課題に対処します。

コンテナとはアプリケーションのコードをそのライブラリーや依存関係と共にパッケージ化する実行可能なソフトウェア単位であり、あらゆるコンピューティング環境でコードを実行できるようにするものです。Kubernetes（k8sまたはkubeとも呼ばれます）は、コンテナ化されたアプリケーションのデプロイメント、管理、スケーリングをスケジュールおよび自動化するためのオープンソースのコンテナ・オーケストレーション・プラットフォームです。

従来、DevOpsチームは脆弱性を特定するために他のセキュリティー・チームに依存し、そのフィードバックに基づいて次のアプリ更新プログラムでコードの変更を実装していました。今では、開発者はコンテナとKubernetesクラスターを保護し、ソフトウェア・アプリケーションと開発プロセス全体にゼロ・トラストの原則を適用することが求められています。これは新しいオペレーション・パラダイムを反映したものです。 ³DevSecOpsプラクティスの採用により、コーディングとソフトウェア開発はもはや機能の構築だけでなく、リスクの予測も含まれるようになってきています。

サーバーレス・コンピューティングとクラウドネイティブ・アーキテクチャーも今日のDevOps部門にとっての優先事項です。

サーバーレス・コンピューティングは、開発者がサーバーやバックエンド・インフラのプロビジョニングや管理を行わずにアプリケーション・コードを構築および実行するためのアプリ開発および実行モデルです。サーバーレス構成のサーバーは存在しますが、それらはクラウド・サービス・プロバイダー（CSP）によって完全に管理されます。CIパイプラインでは、開発者はサーバーレス・プラットフォームのおかげでバックエンド・インフラのことを考える必要がなくなり、フロントエンドのコーディングとビジネス・ロジックに集中できます。

サーバーレス・コンピューティングとAIアプリケーションの普及に伴い、イベント駆動型アーキテクチャー(EDA）は、チームがクラウド・コンピューティングの複雑さの増大に対処する上で中心的な役割を果たしています。EDAは、疎結合されたフロントエンド・システムとバックエンド・システム間のリアルタイム通信をサポートし、 システムが独立して動作し、イベント（システム内で発生するあらゆる変更やアクション）を 非同期で処理します。

CIパイプラインでは開発者がアプリケーション全体に影響を与えることなく個々のアプリ・コンポーネントを拡張でき、チームがよりアジャイルで応答性が高く、スケーラブルなコードベースと統合プロセスを作成できるということです。

堅牢なCIパイプラインを設定するには、適切なツールの選択、ビルドとテストのワークフローの定義、インフラストラクチャーの構成など、慎重な計画と構成が必要です。CIパイプラインでは、コード・ベース、依存関係（APIなど）、インフラストラクチャーの変更に対応するために定期的なメンテナンスも必要です。

ただし、CIを実装すると、ソフトウェア開発チームには、次のようなさまざまなメリットがあります。

CIプロセスにより、チームは早期に、場合によってはコードの送信から数分以内にエラーに対処できます。

チームの全員がコードを変更し、コード変更を統合し、コードの非互換性や統合エラーを特定できるため、簡単に知識が共有でき、同僚間のフィードバックを通じて、コーディングとソフトウェアの品質を向上できます。

新しいコードを継続的に統合できるため、コードの大規模バッチへの統合とテストに費やすチームの時間を削減できます。また、CIツールが提供するフィードバック・ループの高速化により、開発者はソフトウェアのアップデートや新製品をより迅速に反復してエンド・ユーザーに届けられるようになります。

コードを頻繁にコミットすることで、より小さく段階的な変更ができ、理解や、レビュー、テストが容易になります。これにより、開発中にコード・ベースに重大な問題が持ち込まれるリスクが軽減できます。