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

CIとは

ソフトウェア開発プロセスの自動化により、チーム開発のスピード向上と品質の安定化を試みる手法のことです。
チーム内で共有するリポジトリにコミットされることをトリガーに、予め定めたビルドとテストが自動実行されます。
なお、ステージング環境、本番環境へのデプロイやセットアップなどを含む「継続的デリバリー」とは区別されます。

メリット

• バグを短時間で発見できる
• テストにかける開発者の時間を節減できる
• 安定し、かつスピーディーな製品のリリースにつながる

共有リポジトリにコミットすると、テストが自動実行されますから、開発者自身で逐一テストを考え、実施する必要がなくなります。これは時間の節減だけでなく、ヒューマンエラーの可能性も抑えることができます。また、機械的なテストが義務付けられていることで、いつ・どこに問題があるのかを把握できるなど、ソフトウェア全体の品質を管理しやすくもなります。

効果的な取り組みのために

CIをより効果的にするため、下記のことを守ると良いとされます。

• 頻繁にコードをコミットする
• ビルドが失敗したコードはコミットしない
• ビルドが失敗したコードは、早急に修復する
• 開発者による単体テストを自動化する
• 全てのビルドとテストを合格（オールグリーン）にする
• 開発環境において、最新のコードと自分のコードをマージしてビルド、確認する（プライベートビルド）
• ビルドに失敗したコードを取得しない

ただし、CIだけではありませんが、テストカバレッジには厳密さを求めすぎないことに注意したいところです。 カバレッジを100%にすることに躍起になると、開発者にかかる負担と時間が重なり、CIの導入が遅れます。
カバレッジだけではなく、テスト内容が適切かどうかを検証するようにします。

CIプロセスとツール

外部サイトにわかりやすい図解がありました。

CI – 継続的インテグレーションとは？ | tracpath:Worksより引用

このプロセスからわかるように、CIには3つのツールが関連します。

• リポジトリ
• オーケストレーション
  　CIの核となるツールで、コミットをトリガーとして、テストなどを実行します。
  
• チャット、メール
  　CIの結果を開発者に通知します。
  

オーケストレーションではテストの他に、継続的デリバリーに含まれるデプロイを自動で実行する等のオプションもあります。

CIによる効果の測定

CIの導入によって、開発プロセスの改善にどの程度効果があったのかについて、下記観点で測定します。

1. パイプライン時間の変化
   　コードのコミットからデプロイにかかる時間
   

2. ビルド時間の変化
   　テストの実施とその準備にかかる時間も含む
   

3. エンジニアの待ち時間の変化
   　ビルド実行までの待ち時間
   

4. masterブランチの障害時間
   　masterブランチが壊れて利用できない時間
   

5. ツールのメンテナンスに要した時間
   　クラウド、インフラ、監視、ツールの導入と設定に要した時間
   

CIの導入にあたって

最初からテストの自動実行を始めようとすると、負荷が高く頓挫してしまうこともあるようです。 コードのインスペクションやコンパイル、バイナリパッケージングなどに絞って始め、少しづつ拡張していくことが勧められています。

また、チーム内での共有リポジトリを整備する、決まったタイミングで小刻みにコミットするよう義務付ける、などのチームルールを整えることも必要です。

CI – 継続的インテグレーションとは？ | tracpath:Works

あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ - Qiita

テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について - Qiita