継続的インテグレーション
 | この記事には独自研究が含まれているおそれがあります。 |
| ソフトウェア開発 |
|---|
| 中心となる活動 |
| パラダイムとモデル |
| 方法論とフレームワーク |
| 開発支援 |
| プラクティス |
| ツール |
| 標準と機関 |
| 用語集 |
継続的インテグレーション、CI（英: continuous integration）とは、すべての開発者の作業コピーを定期的に共有されたメインラインにマージすることである。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はデプロイ作業を完全に自動化する。
コストとメリット[編集]
継続的インテグレーションは、次のようなメリットを生み出すことを目的としている。
- インテグレーションバグは早期に発見され、小さな変更セットのため追跡が容易になる。これにより、プロジェクトのライフサイクルにわたって時間とコストの両方を節約することができる。
- リリース日の土壇場の混乱を避けることができる。
- 単体テストが失敗した場合やバグが発生した場合、開発者がデバッグせずにコードベースをバグのない状態に戻す必要がある場合、少数の変更しか失われない（統合は頻繁に発生するため）。
- テスト、デモ、リリースの目的で「現在の」ビルドを常に利用可能にする。
- 頻繁にコードをチェックインすることで、開発者はモジュール化された複雑さの少ないコードを作成するようになる。
継続的な自動テストには、次のようなメリットがある。
- 頻繁に行われる自動テストの規律を強化
- ローカルな変更によるシステム全体への影響を即座にフィードバック
- 自動テストとCIから生成されたソフトウェアメトリクス（コードカバレッジ、コードの複雑さ、機能の完全性のメトリクスなど）は、機能的で高品質なコードの開発に開発者を集中させ、チームの勢いを高めるのに役立つ。
継続的インテグレーション用のソフト[編集]
- CABIE
- Cascade
- CircleCI
- codeBeamer
- CruiseControl
- CruiseControl.rb
- Electric Cloud
- FinalBuilder
- GitLab
- GitHub Actions
- Hudson
- Jenkins
- Rational Team Concert
- Rational Software SCLM
- Team Foundation Server
- Shippable
- Strider: Open Source Continuous Integration & Deployment Server
- TeamCity
- Thoughtworks
- Tinderbox
- Travis CI
- Xcode
脚注[編集]
- ^ Fowler (2006年5月1日). “Continuous Integration”. martinfowler.com. 2014年1月9日閲覧。
- ^ Booch, Grady (1991). Object Oriented Design: With Applications. Benjamin Cummings. p. 209. ISBN 9780805300918 2014年8月18日閲覧。
- ^ Beck, K. (1999). “Embracing change with extreme programming”. Computer 32 (10): 70–77. doi:10.1109/2.796139. ISSN 0018-9162.
- ^ Duvall, Paul M. (2007). Continuous Integration. Improving Software Quality and Reducing Risk. Addison-Wesley. ISBN 978-0-321-33638-5
- ^ Cunningham (2009年8月5日). “Integration Hell”. WikiWikiWeb. 2009年9月19日閲覧。
- ^ “継続的インテグレーションとは?”. アマゾン ウェブ サービス. 2021年1月10日閲覧。
- ^ Durieux, Thomas; Abreu, Rui; Monperrus, Martin; Bissyande, Tegawende F.; Cruz, Luis (2019). “An Analysis of 35+ Million Jobs of Travis CI”. 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME) (IEEE): 291–295. arXiv:1904.09416. Bibcode: 2019arXiv190409416D. doi:10.1109/ICSME.2019.00044. ISBN 978-1-7281-3094-1.
