【Ruby版】CI（継続的インテグレーション）ツール導入ガイド：第1回 CI の概要

Ruby版 CIツール導入ガイド

CI（継続的インテグレーション）とは、開発、テスト、リリースのサイクルが継続的に行われていく様子の事であり、それらを円滑に行うためのツールが CIツールである。

CI の目的は品質の良いプログラムをリリースする事であり、プログラムコードの更新とともに自動的にビルドやテストを行ったり、ドキュメントを更新したりする。CIを構成するさまざまなツールを実行するサーバーを CIサーバー等と呼ぶ。CIサーバーでは実行されたテストの統計情報等を視覚化する事で、さらに品質を高めるための工夫が行われている。

本稿では CI の概要を紹介すると同時に主に Ruby プログラマ向けの CIツールを紹介する。各章の概要は以下の通りである。

第1回 CI の概要:CI の概要と、どのようなツールが存在するのかについて紹介する
第2回さまざまなジョブ:CIの実行中に処理されるジョブについての概要
第3回さまざまなジョブ(1):CIのジョブとして利用可能なRuby用のツールのインストール方法等
第4回さまざまなジョブ(2):その他のツールの紹介
第5回 CIサーバーの構築: Jenkins を利用し、CIサーバーを構築する手順
第6回 CIサーバーを使ってみよう:第5回で構築した Jenkins で、実際に CI を行った様子の紹介

Ruby版 CIツール導入ガイド　第1回 CI の概要

CI を利用する事で、より品質の高いアプリケーションを素早くリリースできるようになる。まずは CI が目指す物や、メリットについて解説しよう。

CI とはどういう動作をする物か？

複数人での開発を行う時、プログラムコードのマージが問題になる事がよくある。マージの問題は、バージョン管理ツールのステータスだけでは解決できない。これは単なる更新ファイルの衝突の問題ではなく、完全に独立したファイル同志であっても発生する問題だからだ。例えば開発中に仕様変更が発生し、クラスを作る側と使う側とで微妙に認識がずれてしまうという事があるかも知れない。こんな時はお互いに単体テストをするだけでは問題に気が付くのが難しいだろう。リリース間際の結合テストで初めて問題が発覚し、大慌てで修正しなくてはならない可能性もある。

こういう問題を避けるためには、こまめにテストをするのが一番だ。頻繁にリポジトリに登録するようにして、登録の度に単体テスト、結合テストを行う。テスト以外にもコーディング規約にマッチしているかどうかをチェックしたり、コメントによる自動ドキュメント生成等も毎回できれば理想的だ。これをリリースまで継続する事でプログラムの品質を高めていくのだ。

この工程を CI と呼ぶわけだが、これを開発者ひとりひとりが手作業で行っていくのは現実的では無い。テストにはそれなりに時間が掛かるし、ちょっとしたコミットの度に毎回テストを行えと言っても、いつの間にかおざなりになってしまう事もあるだろう。そこで専用の CIツールを利用して、自動化する事が必要となる。CIツールを利用すれば、リポジトリにプログラムを登録するたびにテストが自動的に行われる。

CIツールをインストールし、CI の自動化を担うサーバーを CIサーバーと呼ぶ。CIサーバーはバージョン管理システムのリポジトリサーバーと兼用される事も多いが、独立して運用する事も、もちろん可能だ。
CIサーバーではプログラムコードのテスト以外にもさまざまな処理を実行できる。正常にビルドできるかをチェックしたり、自動ドキュメント生成や静的コード解析（後述）等、品質を高めるためのさまざまなジョブを CIサーバーが一元的に管理するのだ。問題があればメールやWEB画面で警告してくれるので、開発者はすぐに自分の間違いに気が付く事が出来るわけだ。

CI の前提条件

CI を行うためには、いくつかの前提条件がある。

バージョン管理を行っている事

プログラムのバージョン管理を行う事は、CI を行う上での第一の前提条件である。昨今では Git や Subversion を利用してバージョン管理を行う事は、システム開発会社にとっては当たり前の事だろう。しかしホームページ制作会社や自社の小規模システムを管理する部署等では、必ずしもそうではないのが現状だ。もしまだバージョン管理を行っていないのなら、まずはそれから初めてみよう。本稿ではバージョン管理ツールの導入についてはサポートしていないので、別の記事等を参考にして頂きたい。

テストを自動化している事

CIサーバーではプログラムの登録をトリガーとしてテストを行うので、テストが自動化されている事は必須では無いにせよ、重要な前提条件である。バージョン管理が広く普及しているのに対し、テストの自動化は開発会社でもまだ採用に至っていない所は多いようだ。テストの自動化を行う場合、テストスクリプトの開発というこれまでには無い作業を行わなければならず、スケジュールやコストへの影響も大きい。テストの自動化に興味があっても、それがネックとなり導入に踏み切れない事は多々あるようだ。

しかし、テストスクリプトを作らなくても自動テストができるとしたらどうだろうか？　例えば静的コード解析ではプログラムコードを実行する事なく分析し、さまざまな問題点を指摘してくれる。多少の初期設定は必要だが、各モジュールごとにテストスクリプトを記述する必要も無いので初期導入も保守も非常に簡単だ。

もちろん、テストスクリプトを記述してテストを行った方が良質なテストができる事は言うまでもない。しかし、静的コード解析を CI に導入するだけでも、従来より高い品質のプログラムをリリースできるようになるだろう。

本稿の第2回目以降では、静的コード解析を始めとする、 CI で利用可能なさまざまなツールを紹介したいと思う。

CIツールを稼働させる事

CI の専用ツールをインストールするための CIサーバーが必要になる。CI は比較的重い処理が走るので、ある程度のスペックのサーバーが必要だと思って欲しい。ユーザーが直接利用するサーバーではないだけにコストを抑えたい所だが、少なくとも 8GB 程度のメモリを独占的に利用可能なサーバーが望ましいだろう。本稿の第5回目では、実際に CIサーバーを構築するまでの手順を紹介する予定だ。

なお、SaaS の CIツールにも色々な物がある。自前のサーバーを用意しなくて良い点は、SaaS の大きなメリットだ。

さまざまな CIツール

CIツールには多くの製品が存在する。有償の物、オープンソースの物、SaaS型の物等、形態もさまざまであるが、その中から代表的な物をいくつか紹介しよう。

Jenkins

公式サイト::
https://about.gitlab.com/

Ruby on Rails で記述された CIツールであり、Jenkins と同じく複数のジョブをコードの push に連動してまとめて実行できる。GitLabは元々は GitHub のクローンとして登場したツールだが、Version 8以降、CIツールとしての機能が実装された。そのため GitHub に慣れているユーザーにとっては導入しやすいツールと言える。

どのようなジョブを利用するかは、yamlファイルで設定を記述する。視覚化できる範囲は限定的だが、気軽に記述できる yaml ファイルで色々なツールを導入できる点は使いやすい。

一方、GitHub をモチーフしたアプリケーションであるだけに、リポジトリとして Gitしか想定されていない事は、Gitを導入していない環境においては大きな障壁になるかも知れない。ただし Subversion等を Git と連携させる方法は色々あるので、工夫次第では補えるだろう。

AWS CodePipeline

公式サイト::
https://aws.amazon.com/jp/codepipeline/

Amazon が提供する SaaS型の CD（継続的デリバリー）サービスである。CD とは CI をさらに拡張し、デプロイまでを統合的に扱う手法である。つまり、ソースコードをリポジトリに push するだけで、ステージング環境や本番環境の更新まで自動的に行ってくれるわけだ。さらに AWS CodeStar とも連携が可能で、この場合開発環境の構築まで自動化してくれる。

もちろん、SaaS型であるが故に使用量に応じた料金を支払う必要がある。また、EC2, S3, CodeCommit 等、さまざまな AWS (Amazon Web Service) の技術と連携した上で動作するため、本格的に利用するなら AWS に対する広範囲な知識が必要かも知れない。AWS のアカウントがあれば手軽に始められるため、興味があれば是非一度は試して頂きたい。