継続的インテグレーション（CI）について調べてみた
はじめに
この記事では、「継続的インテグレーション（CI）の概要」について書いています。
DevOps勉強の中の一つとして継続的インテグレーションについて調べ記事に書いてみました。
自分に向けた備忘録でもありますが、「継続的インテグレーション（CI）とは何か知りたい」な人の一助になれば嬉しいです。
継続的インテグレーションとは何か
- CI（Continuous Integration）を日本語にしたもの
- 継続的 = 中断することなく、ずっと続く
- 断続的（ = 途切れ途切れでことが進む）の対義語
- インテグレーション = 統一する（コードをマージする）
- 継続的 = 中断することなく、ずっと続く
- 開発者がコードの変更を頻繁にメインラインへマージする開発手法
- メインライン = メインブランチ、トランク。ブランチの作成元のこと。
- 頻度は一日数回が一般的
- 継続的インテグレーションという言葉は２つの側面で使われる
- オートメーションの側面(CI やビルドサービスなど)
- 啓発の側面 (頻繁に統合する必要性を学習することなど)
- 継続的インテグレーションの目的
- バグを早期に発見して対処すること
- ソフトウェアの品質を高めること
- ソフトウェアの更新を検証してリリースするためにかかる時間を短縮すること
- 継続的インテグレーションが必要な理由
- 以前の開発方式の問題点を解消したい
- 以前の開発方式
- チームに所属する開発者が長期間にわたって独立して作業する。
- 作業が完了した後初めて変更点をマスターブランチにマージする。
- 以前の開発方式だとコードの変更をマージする作業が困難で時間がかかる
- 長期間独立して作業 = 変更点が多く、その分競合や失敗の可能性が高い
- バグが修正されないまま長期間にわたって累積する
- 変更点が多い中でバグの原因特定は時間がかかる
- これらが積もり積もって更新のリリースが遅れる原因になる
- 開発のための作業時間が競合の解決などマージのための作業時間をはるかに超えることにもなる
- 以前の開発方式
- 以前の開発方式の問題点を解消したい
- 継続的インテグレーションの仕組み
- 開発者は、Gitなどのバージョン管理システムを使って共有リポジトリに頻繁にコミットする。
- コミットする前にローカルでテストを実行し、自分のコードが問題ないかを確かめる
- 継続的インテグレーションはユニットテストと組み合わせて使用することが想定されている。
- コミットされたら自動的にビルドを行い、変更された新しいコードについて品質管理を実施する
- 品質管理: ユニットテストや統合テストに加えて静的分析など
- 継続的インテグレーションのメリット
- バグを短時間で発見、対処できるようになり、プロジェクトとして時間とコストの両方を節約できる。
- 更新を迅速に配信できるようになり、リリース直前での土壇場の混乱を避けることができる。
- 開発者が競合の解決などに時間を取られなくなるため生産性が向上する
おわりに
「継続的インテグレーション（CI）の概要」について解説しました。
さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。
