ruby on rails on hudsonの活用事例
TRANSCRIPT
Ruby on Rails on Hudsonの活用事例
Toshio Maki
(@Kirika_K2 / id:Kirika)
自己紹介• 名前
–牧 俊男（ Toshio Maki）– Twitter @Kirika_K2 / はてな id:Kirika
• 所属–ちょっと大きな SI企業の研究開発っぽいところ
• 社内 Ruby開発環境の整備担当• Ruby産業を国内に普及させるための取り組み
• 最近の活動– RubyWorld Conference 2010発表
Hudsonとの出会い• 小規模の勉強会の中でリファクタリングをテーマにしたときに使用
• @ikikkoが Hudsonを使ったビルド環境を構築• それ以来自分の仕事にも Hudsonを取り込む
ここに立つことになった経緯• RubyWorld Conference 2010で Hudsonを活用したネタを発表
ここに立つことになった経緯• 発表した内容を簡単に勉強会で紹介
ここに立つことになった経緯• 気がついたら ikikkoの RTに巻き込まれてた。
ここに立つことになった経緯
• 軽いノリで発表を OK。
自主規制
ここに立つことになった経緯• 気がつけば ATND 250人以上• RubyWorld Conferenceは 100人程度
ここに立つことになった経緯• どうしてこうなった的な
フィードバック希望です
• 何か思うことがあれば、懇親会の場でもTwitterでもいいのでフィードバックを頂ければと思います。
アジェンダ
• Ruby on Rails on Hudsonのメリット• 活用事例
–全体概要– Hudsonの設定
• まとめ
Ruby on Rails on Hudson
RoRに Hudsonを適用することのメリット (1/4)
• デイリービルドによる日々の成果物チェック– Ruby / Railsは実行環境差で動いたり動かなかったり。
– 社内では用意したクリーンな環境で正しく動くことをテストする。
RoRに Hudsonを適用することのメリット (2/4)
• テスト時間の省力化–毎日 rake testを実行してくれると、個別に
rake testしなくても良くなるので省力化できる。
RoRに Hudsonを適用することのメリット (3/4)
• テストコードを書くモチベーションが上がる
RoRに Hudsonを適用することのメリット (4/4)
• パッケージの自動生成と Capistranoの代用– Hudsonで Railsアプリを RPMに変換– RPMのインストールでデプロイ
活用事例
基本コンセプト
• 同じ環境が作れる• その上で動作確認がいつでもできる• なるべくデプロイにおける人手の介入を減らす
全体図
②
③
④
⑤ ①⑤
① ⑤①Kickstartによる配信（初回のみ）②ソースコードのコミット③ソースコードの取得④成果物のアップロード⑤yum update（毎日実行）
① ⑤
Hudsonの設定
稼働状況
約 10のプロジェクトが 1台の Hudsonサーバで稼働。HDDが 60GBしかなく、既に限界
メインで利用しているプラグイン
• Version Number Plug-in– 環境変数に日付やビルド番号を含めたバージョン番号を入れてくれる
• Rake Plugin– ビルドタスクに rakeタスクを使用することができる
• Ruby metrics Plugin– Rcov, Rails Statsなどを表示
• Subversion Plugin
• Hudson SCP publisher plugin– SCP経由で成果物を特定サーバにアップロード
汎用的に利用している設定
古いビルドの破棄• スタートアップのプロジェクトではグラフの遷移が気になるので 10程度を指定– 一番大きいプロジェクトはビルド履歴の保存は２– １回のビルドに 3.4GB使用するため
権限設定• プロジェクト単位の権限設定• PMっぽい人に configure権限を与えて運用
– まだ Hudsonの仕組みが社内に浸透していないので、設定を書き換えて使っている人はそんなに居ない
ソースコード管理システム• Subversionを選択
– 社内インフラとして Subversionリポジトリが提供されているため、そのアドレスを記入
ビルドトリガ
• 毎朝 5時に定期実行
• 全部のプロジェクトをまとめてビルドするので、人の居なさそうな時間を指定
ビルド環境• Create a formatted version numberをチェック
– Version Number Pluginを入れることで利用可能• 環境変数 versionにビルド年月日とビルド番号を書き出す設定にする
Version Number Plugin使用例
ビルド
• ビルドタスクは以下の３ステップでビルド
1. db:migrateの実行2. rcovの実行3. テスト→ RPMパッケージの自動生成
db:migrateの実行• Rake db:migrateを実行してデータベースの表設計を最新にする
• Rake Pluginの機能で Rakeを実行させる
rcovの実行• rcovを実行して、カバレッジデータの収集をします
• Hudson標準のシェルの実行機能を使います
RPMパッケージの生成• 独自の rakeタスクを実行（ rails内 lib/taskに格納）• テスト後、成果物を RPMにパッケージング
– RPM内でやってくれること• 特定ディレクトリへのインストール• rake db:migrateの自動実行• Apacheの VirtualHostの自動設定
• Ruby・ Rails・ Passengerが構築済みの状態でインストールされるので、 RPMをインストールすると即実行可能状態になる
ビルド後の処理
• 成果物を保存
Publish Rcov Report
• Ruby metrics Pluginを使用• 生成したカバレッジデータの出力ディレクトリを指定
• カバレージ率が低い時に Hudsonにアラートをあげさせることもできる
Publish Rcov Report
–テストを書くモチベーションを上げる–重点的にテストを書く箇所の判断材料
Publish Rails Stats report
• 一応有効に。• あまり良い使い方が思い浮かばず。• うまく活用している人が居ましたら、教えてください。
Publish Rails Stats report
ビルド後の処理
• E-mail通知–管理者である自分と、 PMを加えておく
• 基本的には向こうで対応してもらうが、対応できなかったときは問い合わせがあるので、いつでも対応できるように。
SCPによる成果物の転送
• SCPでアプリ配信サーバにデータを転送• アプリ配信サーバは１日１回、レポジトリの内容を更新する
適用後の効果
良かったところ
• 適用前はうさんくさいツールだと思われていたようだが、こちらから設定とかをお膳立てしてあげると、積極的に使ってくれるようになった。–１回のテストで動作確認から、インストール用パッケージ生成まで出来るのが良い
– Capistranoに比べて、 UIが優れていて、設定しやすい
反省ポイント
• マシンのスペックが貧弱だと色々悩まされる–ビルド時間、 HDDの容量–特に HDDの容量は気を抜くとすぐなくなります
• 何かトラブルが発生したときは、まだSSHを使うことが多い
• RPM生成やパッケージの自動更新の仕組みはかなり作りこんでいるので、将来的に引き継ぐのが大変になる
まとめ
• 開発インフラの中に Hudsonが１つ入ると、色々と捗るぞ。