|
継続的インテグレーション継続的インテグレーション（けいぞくてきインテグレーション、英: continuous integration、CI）とは、すべての開発者の作業コピーを定期的に共有されたメインラインにマージすることである。1日複数回行われるのが一般的である[1]。グラディ・ブーチは1991年のメソッド[2]でCIという用語を最初に提案したが、彼は1日に数回の統合を提唱していなかった。エクストリームプログラミング(XP)ではCIの概念を採用し、1日に1回以上、おそらく1日に何十回も統合することを提唱した[3]。 理論的根拠開発者は変更に着手するとき、現在のコードベースのコピーを取って作業する。他の開発者が変更したコードをソースコードリポジトリに提出すると、このコピーは徐々にリポジトリのコードを反映しなくなる。既存のコードベースが変更されるだけでなく、新しいコードを追加したり、新しいライブラリやその他のリソースを追加したりすることで、依存関係や競合が発生する可能性がある。 メインラインにマージせずにブランチでの開発が長く続けば続けるほど、開発者ブランチが最終的にマージされたときに複数の統合の競合[4]や失敗が発生するリスクが高くなる。開発者がリポジトリにコードをコミットするとき、まず、コピーを取ってからのリポジトリの変更を反映させるためにコードを更新しなければならない。リポジトリに含まれる変更点が多ければ多いほど、開発者は自分の変更点をコミットする前に、より多くの作業をしなければならない。 最終的には、リポジトリが開発者のベースラインとあまりにも異なるものになってしまい、「マージ地獄」や「統合地獄」と呼ばれるものに突入してしまうことがある[5]。その場合、統合にかかる時間は、元々の変更点を作るのにかかった時間を超えてしまう[6]。 ワークフローローカルでテストを実行するCIは、テスト駆動開発の実践を通して書かれた自動化されたユニットテストと組み合わせて使用することを意図している。これは、メインラインにコミットする前に、開発者のローカル環境ですべてのユニットテストを実行し、通過させることによって行われる。これにより、ある開発者の進行中の作業が他の開発者のコピーを壊してしまうことを防ぐことができる。必要に応じて、フィーチャートグルなどを使用してコミット前に部分的に完成した機能を無効にすることができる。 CIでコードをコンパイルするビルドサーバは定期的に、あるいはコミット後にコードをコンパイルし、その結果を開発者に報告する。ビルドサーバの使用はXPコミュニティの外で導入されており、多くの組織がXPのすべてを採用することなくCIを採用している。 CIでテストを実行する自動化されたユニットテストに加えて、CIを使用している組織は、一般的にビルドサーバーを使用して、品質管理を一般的に適用する継続的なプロセスを実装している。ユニットテストや統合テストの実行に加えて、このようなプロセスでは、追加の静的分析の実行、パフォーマンスの測定とプロファイル、ソースコードからのドキュメントの抽出とフォーマット、手動のQAプロセスの促進などが行われる。オープンソース向けの人気の高いTravis CIサービスでは、CIジョブの58.64%しかテストを実行していない[7]。 この品質管理の継続的な適用は、すべての開発が完了した後に品質管理を適用するという従来の慣行に代わって、ソフトウェアの品質を向上させ、納品までの時間を短縮することを目的としている。これは、統合をより簡単にするために、統合をより頻繁に行うという、QAプロセスにのみ適用されている元々の考え方と非常によく似ている。 CIからアーティファクトをデプロイする現在、CIはいわゆるCI/CDパイプラインの中で継続的デリバリーと絡み合っていることが多い。CIはメインラインでチェックインしたソフトウェアを常にユーザーにデプロイできる状態にし、CDはデプロイ作業を完全に自動化する。 コストとメリット継続的インテグレーションは、次のようなメリットを生み出すことを目的としている。
継続的インテグレーション用のソフト
脚注
関連項目外部リンク
|
|||||||||||||||||||||||||||
Portal di Ensiklopedia Dunia
