Continuous Integration （継続的インテグレーション、CI）は、開発初期から定期的に（4時間後とか毎コミットとか）ビルドやテストを行い、インテグレーションの時に発生する可能性のあるエラーなどを早期に発見してそれらを随時修正しながら進めていく、XP（eXtream Programming）のプラクティスの一つです。
継続的インテグレーションを実施するにあたり、自動でビルドを行ったりテストをしたりするシステムを作るのはとても大変です。Signalで記事の題名通り簡単に継続的インテグレーションを行うシステムを作ることができそうです。
記事の中には他にいくつかのCruseControlやIntegrityなどのインテグレーションシステムの名前が出てきます。色々と試してみて、開発環境やスタイルにあったシステムを選ぶことがいいと思います。
Signalで作るとても簡単な継続的インテグレーションシステム
Diego Carrion
SignalはRailsで作成された継続的インテグレーションサーバーです。似たようなシステムの使える機能を集めてとても簡単に使うことのできるアプリケーションにしました。
Railsを使って仕事を始めた時、最初に試した継続的インテグレーションシステムはCruseControl.rbでした。CC.rbもRailsで作成されていましたが、プロジェクトを追加する際にサーバーに接続して次のようなコマンドを実行することが面倒でした:
./cruise add [project-name] -r [repository] -s [svn|git|hg|bzr]
上記のコマンドを実行してから、YAMLファイルを開いてビルドが失敗した場合の通知メールを受け取る人のメールアドレスを設定することができます。Scaffoldingの考えにおいて全くおかしいです。難しいことをしなくてもHudson、Integrity、そして、Signalのようにプロジェクトにどんなユーザーでも登録できるページを作るほうがもっと簡単です。
CC.rbでもう一つ面倒なことは、（プロジェクトを）監視するプロセスをたくさん作って、それらのプロセスが時々ハングすることです。暫くは個人の問題だと思っていたのですが、何人かの人と話した後にそんなに特殊な問題ではないことが分かりました。
3つめのCC.rbについて面倒なことはホームページでそれぞれのプロジェクトの最新5つのビルド結果を表示することです。最新の2つのビルド結果でも十分すぎると思います。過去のビルド結果が壊れていようがいまいが私は関心がありません。IntegrityやSignalがうまく表示するような情報であるプロジェクトが現在良好な状態であるかどうかについてだけ関心があります。
Integrityは多くのことを洗練された方法で実行しますが、インストール時にgemをダウンロードしてあるコマンドを実行しなければならないことが気に入りません。最悪なのは使用したいサーバーによって異なるパラメーターがコマンド実行に必要なことです。なぜ、このインストール方法が問題かを説明する前にIntegirtyについてもう一つ嫌いなことを告白させて下さい。それは（訳者注:通知メールの送信）メールに対応していないことです。最悪にも未対応である上、対応するには他のgemをダウンロードしてファイルを編集しなければなりません。簡単なようですが、対応させることができませんでした。
どうも、プラグインgemのバージョンがアプリケーションgemのバージョンに対応していないからでした。じゃあ、gemからのコマンドを実行してインストールしたアプリケーションのバージョンをどうやったら変更することができるようでしょう？別のバージョンのgemをダウンロードして最初のgemを消すだけでいいのでしょうか？アプリケーションを再インストールする必要があるのでしょうか？分かりませんが、何か変なことをしてしまったのだと思いますが、うまくいきませんでした。だから、このような方法でアプリケーションを扱うのは問題になると思っています。
SignalはGitをうまく利用しようとしています。Signalをインストールするには、次のようにコマンドを実行します:
git clone git://github.com/dcrec1/signal.git cd signal rake inploy:local:setup
もし、ある特定のバージョンに戻りたい場合は「git reset -hard COMMIT」を実行して下さい。簡単でしょ？履歴を利用すれば、今どのバージョンで何を取り消したを知ることもできます。
CC.rbの特徴の一つでIntegrityに無いと思われるのは、ホームページにそれぞれのビルドが実施された日時を表示することです。Signalではどれくらい前にそれぞれのプロジェクトのビルドが実施されたかを表示します。そのため、最後のビルドがいつで結果はどうであったかを簡単に知ることができます。
report_cardは、Integrityでmetric_fuを対応させるプロジェクトですが、他のアプリケーションをインストールしていくつかのコマンドを実行する必要があります。これはとても複雑だと思います。このため、Signalでは、metric_fu、RSpec、そして、Cucumberに元から対応しています。
RSpec、Cucumber、そして、metric_fuへのSignalの対応はとても簡単です。それぞれのプロジェクトページにspecs、features、そして、metricsという3つのリンクがあり、それぞれ、ROOT/docs/specs.html、ROOT/docs/features.html、そして、metric_fuのデフォルトの出力パスであるROOT/tmp/metric_fu/output/index.htmlを指し示しています。もし、（訳者注: RSpecによって）仕様のHTMLページが生成している場合は、プロジェクトのページからアクセスすることができます。
SignalはInployにも対応しています。アプリケーションを展開する場合、プロジェクトページから展開（のリンク）をクリックするだけです。そうするとinploy:remote:updateのタスクが実行されます。
Hudsonはとても良いインテグレーションサーバーです。しかし、Signalの方が使うのに少しだけ簡単で、Railsで作成されており、GitHub上で管理されているという点で優れていると思います。
Railsで開発されているということは長所の一つです。なぜなら、（RSpecやCucumberといった）プロジェクトでは通常、プラグインが提供されており、Railsではプラグインのサポートがあるからです。大抵のRails開発者はプラグインのインストール方法を屋それらがどのように動作するのかを知っています。そのため、プラグインを作成することは問題にはなりません。
GitHubで管理されていることも長所の一つです。なぜなら、プロジェクトを共同して開発することができるからです。今のところ、Signalには多くの規約がありますが、ある理由で特別な設定が必要な場合には、プロジェクトを分岐して、貢献しはじめることができます。SignalはRailsを使って開発されているため、とても簡単です。どのように動作するのかを理解することができるはずです。
Signalの規約の一つは、Rakeのbuildタスクを実行することでビルドを実施することです。プロジェクトにもよりますが、通常、私は次のようなタスクをビルドで実施しています:
task: build => ['db:migrate', :spec, :cucumber, 'metrics:all']
Signalをインストールして使うことが簡単であるかを紹介する3分間ほどの短い動画を撮影しました。この動画では、アプリケーションをダウンロードしてInployを使ってインストールしています。それから、新しいプロジェクトを登録して新しいビルド方法を作成します。プロジェクトと共にビルド方法は自動的には作成されません。それはビルドを実施する前にいくつかすることがあるからです。デモ目的のため、ビルドが早いRubyで開発されたプロジェクトを選択しています。そのため、Cucumberやメトリック計測を実施していません。最初のビルドの後にdelayed_jobを開始してコマンドラインからGitへのフックとなるようなビルドを作成しています。Signal自身のビルドを紹介して、（RSpecやCucumberでの）仕様やストーリーや（metric_fuによる）コードメトリックの計測結果をプロジェクトページから簡単に参照できることを紹介して動画が終了します。
Really easy continuous integration with Signal from Diego Carrion on Vimeo.
0 件のコメント:
コメントを投稿