前回はJenkinsの概要について紹介したので、今回はJenkinsの導入から始めましょう。
Jenkinsのインストールには幾つかの方法がありますが、一番ポピュラーなのは、お使いのOSにそったパッケージから導入することです。http://jenkins-ci.org/にはWindows, Ubuntu/Debian, RedHat/CentOS, Mac OS Xなどの専用パッケージが用意されており、これを使うことで、コンピュータの起動時に自動的にJenkinsを起動したり、セキュリティの向上の為にJenkinsユーザーを作成したり、ログファイルをローテートするための適切な設定等が自動的に行われます。また、JenkinsはJavaで書かれているために、実行にはJava実行環境が必要ですが、これもパッケージによっては自動的にインストールされます。Javaで開発をしているチームの中には、既にJavaのアプリケーションを動かす環境が整っている方もおられるでしょう。このような方は、jenkins.warをダウンロードしてお使いのTomcatなどにそのまま配備する事もできます。
インストールされるJenkinsは同じものですが、ログファイルを見たり、JVMのメモリサイズを設定したりといった運用作業の手順が微妙に異なってきます。Tomcatに詳しい方は.warを、システム管理経験がある人は.debをといった具合で、自分にあった方法を選択してください。
また、これらJenkins単独のインストーラに加えて、Java Web Startを使ってインストール作業無しで試験的に起動することもできます。この方法はインストールするか決めるために触ってみるのに適しています（ここで設定した情報はローカルコンピュータに記憶されているのでインストール後にデータを引き継いだりすることもできます）。また、Kanonや Trac Lightningといったall-in-onパッケージにもJenkinsが含まれています。
Jenkinsの特徴の一つは、設定を基本的に全てGUIで行えることが挙げられます。Jenkinsをインストールしたら、http://localhost:8080/にブラウザでアクセスしてみましょう。Jenkinsのウェルカム画面が表示されるはずです。
「新しいジョブを作成」を選んでジョブを作成してみましょう。「フリースタイル・プロジェクト」を選び、適当な名前を入力します。すると、ジョブの設定画面にジャンプするので、ここで作業の手順を指示します。
大きく分けて(1)ソースコードをリポジトリからチェックアウトする手順、(2)どのタイミングでビルドを行うかを指定する「ビルド・トリガ」の部分、(3)実際に何をどうビルドするかを設定する「ビルド」の部分、(4)ビルド後に出力されたファイルなどを解析する為の「ビルド後の処理」手順の４部分に分かれているので、これを設定します。
ソースコード管理システムサポートは、cvsとsubversionが標準で出荷されています。お使いのツールが入っていない場合には、対応するプラグインをインストールする必要があります。ここでは、「ビルド手順の追加」から「シェルの実行」か「バッチファイルの実行」を選んで、「echo hello world」などとして初めてもよいでしょう。
このように、Jenkinsで実際のビルドやテストを走らせるためには、ビルドやテストがスクリプトから実行可能であることが必要になります。IDE等でビルドしているためにビルドがスクリプト化されていない環境では、これが一見追加の工数であるかのように見えますが、実際にはスクリプト化は開発プロセス改善の最初の一歩ですから、21世紀のソフトウェア開発においては必須の作業です。世の中にはまだまだ書かれなくてはならないソフトウェアが沢山あるので、開発者は機械にできる作業はどんどん機械にやらせていく必要があります。
適当な設定が済んだら、スクロールして「保存」を押し、ジョブのトップ画面に戻ります。そして、ここから「ビルド実行」を押してみましょう。ビルドが実行され結果が保存される様子が確認できたでしょうか。これがうまくいったら、ジョブの設定を色々いじって様々な可能性を実験してみてください。Wiki上の「Use Jenkins」セクションも参考にしてください。
次回は、本格的な運用には必須の分散ビルドの機能について紹介します。
Jenkinsの紹介
Jenkins はオープンソースの継続的インテグレーション(CI)サーバです。CIサーバは最近普及しつつあるソフトウェア開発習慣・方法論の一つで、狭義にはビルド・テストの実行や品質検査を常時継続的に実行していくというものです。これによって、幾つかの具体的なメリットが得られます。
- 最新の変更によって生じた予期せぬ問題を早期に発見し、ソフトウェアの品質向上に貢献する
- ソフトウェア開発者がコーディングやデバッグなどの真に知的な作業に集中することができる
- 品質検査の結果などチーム全体で結果を共有できる作業に、個人個人が無駄に繰り返し実行するのを避ける
- サーバでもできる作業に手元の計算機を使わない。手元の計算機はIDEなどの対話的な作業に注力させる
- 品質検査などの結果をチーム内やマネージャーと共有することでプロジェクトの見える化が進む
元々CIはこのようにビルド・テストの実行といった狭い分野にフォーカスしていましたが、最近では、汎用の自動化プラットフォームとして、バックアップ・リリース・デプロイメントなどのスクリプト可能な作業をなんでもやらせる事も広義のCIに含んでよいと思います（Continuous Deploymentなどと呼ばれる事もあります）。今までは、こうした作業は担当者が個人の計算機上でスクリプトとして記述することが普通でしたが、ちょうど開発者がIDEとは切り離された誰にでも実行可能なビルドスクリプトの利便性に気づいたように、担当者の個人の環境を離れて誰にでも見え、修正でき、実行できるような形に書く事で、属人性と環境依存性を排除することができます。
Jenkinsは筆者が数年来開発に従事しているオープンソースのCIサーバです。元々は一人で書き始めたのですが、今はのべ数百人の開発者が開発に関わる大規模なソフトウェアプロジェクトに成長しました。認知度も高く、O'Reilly Open-Source Awardを受賞したり、Eclipseのユーザーコミュニティ調査でもここ数年目覚ましく普及が進んでおり、もっとも普及しているCIサーバです。アメリカ及びヨーロッパでは非常に普及が進んでおり、筆者が日本人な事もあって、日本にも活発なコミュニティが存在し、定期的な勉強会の開催やメールにより情報交換[3]などが行われています。
Jenkinsが普及した理由は幾つかあると思いますが、一つは、インストール及び設定がGUIから簡単に行えるという点と、もう一つは高い拡張性とそれによって可能になった豊富なプラグインとが挙げられます。今回は、InfoQの御厚意により、このJenkinsを数回の記事に分けて紹介していきます。