継続的インテグレーション超入門(1)

外資系企業のソフトウェアエンジニアをしておりますタロイモと言います。
よろしくお願いします。

今回から2回にわたって、現代の開発に欠かせない継続的インテグレーション（CI, Continuous Integration）を紹介していきます。開発側の方も必ず必要となる知識ですので、ぜひ見ていただけると嬉しいです。

まず1回目の記事では、継続的インテグレーションのメリットについて説明します。そして2回目の記事で、製品や使用時の流れについて紹介したいと思います。

この記事（１）のゴール
・継続的インテグレーションを使用するメリットを説明できる。

0. 継続的インテグレーションを一言で言うと

*ビルド、*テスト等の一連作業を自動化することで、開発者および運用担当者の負担を減らすツール。

この文面を見てもよく分からない方が多いと思いますので、その背景を説明していきたいと思います。

*ビルド...プログラムを組み立てる作業
*テスト...プログラムが要件を満たしているかのテスト

1. 以前のビルド・テスト作業

かつてのウォーターフォール開発手法では、基本的に*コンポーネントをまとめてビルドするのは1つの開発ライフサイクルで一回だけでした。

*コンポーネント...プログラムを部品単位で分けたときの一部分のこと。

そのため、ビルドが失敗した場合にどのコンポーネントにエラーが出ているのか探すのが大変でした。なぜなら多くのプログラマーが、様々なコンピューター環境でプログラミングを行っていたからです。

さらに、当時は開発期間が何年にもなることがあり、エラーが見つかってもプログラムを作った本人が「一年前に作ったコンポーネントなんて覚えてないよ」なんてことがありました。

2. ビルドサーバーの誕生 

そんなビルド作業の欠点を解消しようと誕生したのが、ビルドサーバーです。コンピューターがビルド作業を行ってくれるので、ビルドする担当者の負担が減り、一日一回ビルドすることができるようになりました。

ー日一回の自動ビルドは確かにエラーの早期発見に役立ち前述の問題点を解消しました。

しかし、ビジネスの流行に対応するために生まれたアジャイル開発手法では、一日一回のビルドでは足りなくなってきました。

3. 継続的インテグレーションの誕生

そこで生まれたのが、継続的インテグレーションです。

継続的インテグレーションでは、*コードのチェックイン (例えばGitHubなどのリモートリポジトリにpushをすること)をするたびにビルドが自動的に行われます。

*自分のパソコン上のプログラムファイルを、開発者全体が見れる共有フォルダに置く作業。

チェックインのたびにエラーのフィードバックが得られ、どの部品コンポーネントに問題が起きたのかを見つけるのにかかる時間は、数日から数分になりました。

そのおかげで、さらに短期間での開発ライフサイクルで市場にプロダクトを投入することが可能になりました。

まとめ

以上が継続的インテグレーションの説明です。継続的インテグレーションはDevOpsにも対応しており、今後ますます需要が増えるでしょう。

次回は、継続的インテグレーションソフトウェアの種類と継続的インテグレーションの利用の流れについて説明します。