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

継続的インテグレーション( CI ) は、ソース コードの変更を頻繁に統合し、統合されたコードベースが動作可能な状態であることを保証する 方法です。

通常、開発者は変更を統合ブランチにマージし、自動化されたシステムがソフトウェアシステムを構築してテストします。^{[1]多くの場合、自動化されたプロセスは}コミット ごとに実行されるか、1日1回などのスケジュールに従って実行されます。

グラディ・ブーチは1991年に初めてCIという用語を提唱しましたが^[2]、彼は1日に複数回の統合を推奨していませんでした。しかし後にCIにはその側面も含まれるようになりました^{[3] 。}

継続的インテグレーションに関する最も古い研究（1989年）は、GE Kaiser、DE Perry、WM Schellによって開発されたInfuse環境でした。^[4]

1994年、Grady Boochは「オブジェクト指向分析と設計とアプリケーション（第2版）」^[5]で継続的インテグレーションというフレーズを使用し、マイクロプロセスを使用して開発する場合、「内部リリースはシステムの一種の継続的インテグレーションを表し、マイクロプロセスの終了を強制するために存在する」ことを説明しました。

1997年、ケント・ベックとロン・ジェフリーズは、継続的インテグレーションを含むクライスラー包括的報酬システムプロジェクトに参加中にエクストリームプログラミング（XP）を発明しました。 ^{[1] [自費出版ソース]}ベックは1998年に継続的インテグレーションについて出版し、技術サポートよりも対面でのコミュニケーションの重要性を強調しました。^[6] 1999年、ベックはエクストリームプログラミングに関する初の完全な本でさらに詳しく説明しました。^[7]最初のオープンソースCIツールの1つであるCruiseControl ^{[8] [自費出版ソース]}は2001年にリリースされました。

2010年、ティモシー・フィッツは、IMVUのエンジニアリングチームがどのようにして最初の実用的なCDシステムを構築し、使用してきたかを詳述した記事を発表しました。彼の記事は当初懐疑的な反応を示しましたが、すぐに人気が出て、 IMVUに基づいたリーンソフトウェア開発方法論の一部として広く採用されました^[9]。

CI の中心的なアクティビティは、開発者がコード変更を共有の統合領域に頻繁に配置し、結果として得られる統合コードベースの正確性を検証することです。最初の部分では通常、共通のバージョン管理ブランチに変更をマージします。2 番目の部分では通常、ビルド、テスト、およびその他の多くのプロセスを含む自動化されたプロセスが行われます。

通常、サーバーは統合領域から頻繁にビルドを実行します。つまり、コミットごとに、または1日1回のように定期的にビルドを実行します。サーバーは、ユニットテスト^{[10]の実行などの}品質管理チェックを実行し、静的分析やパフォーマンステストなどのプロセスを通じてソフトウェア品質メトリクスを収集する場合があります。

‹テンプレート How-toは統合が検討されています。› 

このセクションでは、CI を強化するその他の実践に関する実践者の ベスト プラクティスをリストします。

ビルドの自動化はベストプラクティスです。^{[11] [12]}

CI では、バージョン管理システムがアトミック コミットをサポートする必要があります。つまり、開発者の変更はすべて単一のコミットとして処理されます。

コードを変更する場合、開発者は現在のコードベースのコピーであるブランチを作成します。他の変更がリポジトリにコミットされると、このコピーは最新バージョンから分岐します。

統合ブランチにマージせずにブランチで開発を続ける時間が長くなればなるほど、複数の統合競合^[13]や、最終的に開発ブランチがマージバックされたときの失敗のリスクが高まります。開発者がリポジトリにコードを送信する場合、まず自分のコードを更新して、コピーを取得してからリポジトリに加えられた変更を反映させる必要があります。リポジトリに含まれる変更が多いほど、開発者が自分の変更を送信する前に行う作業が増えます。

最終的には、リポジトリが開発者のベースラインから大きく異なるようになり、開発者は「マージ地獄」または「統合地獄」と呼ばれる状態に陥ることがあります^[14]。統合にかかる時間が、元の変更を加えるのにかかった時間を超えてしまうのです^{[15] 。}

CI の支持者は、開発者がテスト駆動開発を使用し、統合ブランチにコミットする前にすべてのユニット テストがローカルで合格することを確認することを提案しています。そうすることで、ある開発者の作業によって別の開発者のコ​​ピーが壊れることがなくなります。

機能トグルを使用して、コミットする前に不完全な機能を無効にすることができます。

継続的デリバリーにより、統合ブランチにチェックインされたソフトウェアが常にユーザーに展開できる状態になり、継続的展開により展開プロセスが自動化されます。

継続的デリバリーと継続的デプロイメントは、多くの場合 CI と組み合わせて実行され、CI/CD パイプラインを形成します。

CI の支持者は、ビルドに必要なすべてのファイルと情報をバージョン管理( gitの場合はリポジトリ)に保存することを推奨しています。つまり、システムは新規チェックアウトからビルド可能で、追加の依存関係を必要としない必要があるということです。

マーティン・ファウラーは、すべての開発者が同じ統合ブランチにコミットすることを推奨しています。^[16]

ビルド自動化ツールはビルドを自動化します。

CI の支持者は、単一のコマンドでシステムを構築できる機能を推奨しています。

自動化には統合の自動化が含まれることが多く、これには実稼働環境のような環境への展開が含まれることがよくあります。多くの場合、ビルド スクリプトはバイナリをコンパイルするだけでなく、ドキュメント、Web サイト ページ、統計、配布メディア (Debian DEB、Red Hat RPM、Windows MSIファイルなど) も生成します。

開発者は、変更を頻繁に、少なくとも毎日同期することで、競合する変更を解決する労力を削減できます。1週間分の作業をチェックインすると、競合が発生する可能性と解決の複雑さの両方で競合が発生するリスクがあります。比較的小さな競合は、大きな競合よりもはるかに簡単に解決できます。少なくとも1日に1回は変更を統合（コミット）することが良い習慣と考えられており、より頻繁に行う方が良いとされています。^[17]

一般的には、毎日、あるいはもっと頻繁に構築することが推奨されます。^[要出典]

システムは、現在の作業バージョンへのコミットをビルドして、正しく統合されていることを確認する必要があります。一般的な方法は、自動継続的インテグレーションを使用することですが、手動で行うこともできます。自動継続的インテグレーションでは、継続的インテグレーション サーバーまたはデーモンを使用して、リビジョン コントロール システムの変更を監視し、ビルド プロセスを自動的に実行します。

バグを修正するときは、バグを再現するテスト ケースをプッシュすることをお勧めします。これにより、修正が元に戻ってバグが再発する (回帰と呼ばれる) ことを回避できます。

統合に問題がある場合はすぐに特定できるように、ビルドを迅速に完了する必要があります。

テスト環境があると、テストされたシステムを本番環境に展開したときに障害が発生する可能性があります。これは、本番環境がテスト環境と大きく異なる可能性があるためです。ただし、本番環境のレプリカを構築するにはコストがかかります。代わりに、テスト環境または別の本番前環境(「ステージング」) を本番環境のスケーラブルなバージョンとして構築し、テクノロジ スタックの構成とニュアンスを維持しながらコストを軽減する必要があります。これらのテスト環境では、チームの制御が及ばない、まだ進化している、または仮想テスト ラボで構成するには複雑すぎる依存関係 (API、サードパーティ アプリケーション、サービス、メインフレームなど) へのオンデマンド アクセスを取得するために、サービス仮想化がよく使用されます。

ビルドを関係者やテスターがすぐに利用できるようにすることで、要件を満たさない機能を再構築するときに必要なやり直しの量を減らすことができます。さらに、早期にテストすることで、欠陥が展開まで残る可能性が低くなります。エラーを早期に発見することで、エラーの解決に必要な作業量を減らすことができます。

すべてのプログラマーは、リポジトリからプロジェクトを更新することから一日を始める必要があります。そうすれば、全員が最新の状態を維持できます。

ビルドが壊れているかどうか、また壊れている場合は、誰が関連する変更を行ったか、その変更内容は何かを簡単に確認できる必要があります。

ほとんどのCIシステムでは、ビルドが完了した後にスクリプトを実行できます。ほとんどの場合、スクリプトを書いて、誰でも確認できるライブテストサーバーにアプリケーションをデプロイすることができます。この考え方をさらに進めたものが継続的デプロイメントです。継続的デプロイメントでは、欠陥や回帰を防ぐために追加の自動化を加えて、ソフトウェアを直接本番環境にデプロイする必要があります。^{[18] [19]}

CI の利点は次のとおりです。

• バグの早期発見を促進
• バグの原因を見つける労力を削減します。CIテストが失敗した場合、最後の正常なビルド以降の変更には原因となる変更が含まれています。各変更後にビルドすると、正確に1つの変更が原因です^[1]
• 多くの変更を統合する際の混乱を回避
• テストが失敗したりバグが見つかったりした場合、コードベースを正常な状態に戻すことで、変更の損失が少なくなります。
• テスト、デモ、リリース用に、良好なビルドを頻繁に利用できる
• 頻繁なコードコミットはモジュール化され、複雑さの少ないコードを促進する^[20]
• コード変更によるシステム全体への影響を迅速にフィードバック
• コードカバレッジ、コード複雑度などのソフトウェアメトリクスの収集をサポート

CI のリスクには以下が含まれます。

• ビルドシステムのセットアップには労力が必要^[21]
• 自動テストスイートの作成と維持には労力がかかる
• 付加価値はテストの質に依存する^[22]
• ビルド待ち時間が長い（キューに待機している）と価値が制限される^[22]
• 不完全なコードは統合すべきではないことを示唆しており、これは一部の開発者の好ましい慣行に反する^[22]
• 安全性とミッションクリティカルな開発保証（DO-178C、ISO 26262など）には文書化とレビューが必要であり、達成が難しい場合がある。

以下の方法は、特にクラウドでホストされているシステムにおいて、パイプラインの生産性を向上させることができる。^{[23] [24] [25]}

• パイプラインの数: 小規模なチームでは、リポジトリとパイプラインを 1 つずつ持つことで生産性を高めることができます。対照的に、大規模な組織では、チームごとに個別のリポジトリとパイプラインを持つ場合や、チーム内のサービスごとに個別のリポジトリとパイプラインを持つ場合もあります。
• 権限:パイプライン関連の権限に関しては、アーキテクチャの動的な性質により、最小権限の原則を順守することが困難な場合があります。管理者は、爆発半径を最小限に抑えるために補償セキュリティ制御を実装しながら、より許容度の高い権限を選択できます。

• アプリケーションリリースの自動化 - パッケージ化と展開のプロセスPages displaying short descriptions of redirect targets
• ビルドライトインジケーター – アジャイルソフトウェア開発でビルドの進行状況をチームに知らせるために使用される視覚的なデバイスPages displaying wikidata descriptions as a fallback
• 継続的インテグレーションソフトウェアの比較
• 継続的設計 - コンポーネントを自由に置き換えて設計を改善したり、パフォーマンスを変更したり、後で別の機能を変更したりできるモジュール設計プロセスPages displaying wikidata descriptions as a fallback
• 継続的テスト – リリース候補に関連するビジネスリスクに関する即時のフィードバックを得るために、ソフトウェア配信パイプラインの一部として自動テストを実行するプロセスPages displaying wikidata descriptions as a fallback
• 多段階継続的インテグレーション - ソフトウェア開発手法
• 迅速なアプリケーション開発 – ソフトウェア開発の概念

• 「継続的インテグレーション」（wiki）（同僚とのディスカッション）。C2。 {{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です
• Richardson, Jared. 「継続的インテグレーション: 優れたショップの礎」(序文)。
• Flowers, Jay. 「ビルドの保守性と再利用性を高めるレシピ」。2020年6月25日時点のオリジナルよりアーカイブ。2006年5月28日閲覧。
• Duvall, Paul (2007 年 12 月 4 日)。「開発者向け作業」。IBM。
• 「バージョンライフサイクル」。MediaWiki。2024年6月。