2012-07-14

Redmineのプラグインのポーティングメモ (to Redmine2.0.x)

今回の内容: Redmineのプラグインのポーティング情報、対応したプラグインは少しずつ増えてきているので、今回はテスト、Jenkins利用時にちょっと困った部分と自分なりの対応を書いてみます。ちょっと長いので、まとめを先に書くと、下記のとおりです。
  • 1. ポーティングのための参考URLはここが良いよ!
  • 2. RAILS_ENV=testのエラーの場合は、Redmine本体のGemfileを修正してみよう
  • 3. SimpleCovのレポートがCI上でできないときは、SimpleCov.start だけにしてみよう
ということで、もしポーティングでお悩みの方、これだけで解決できれば幸いです。
以下はこのポイント発見までの顛末です。
* * *

1. はじめに: ひとまずポーティング

必要に迫られて、少しずつ書くようになった、Redmineのプラグイン。これも、Redmine本体のバージョンが上がると、見直しをしないといけなくなります。
なぜなら、

Redmineのバージョンアップによる機能向上 >>>>>> 越えられない壁 >>>> プラグインによる機能追加

なので…。
自分の職場では、諸々の事情でまだRedmine1.3なので、そんなに困ってはいないのですが、いったん公開してしまったプラグインに関しては、ポーティングしないといけなくなります。特に、春先はRedmine1.4 –> Redmine2.0.xと、rubyのベースもRailsのバージョンも上がってさあ大変!

さすがにRedmine2.0のリリース近辺に対応することはできませんでした。
少し落ち着いてから、いろんなBlog上の情報,Redmine本家の情報,先行して対応しているプラグインのソースを頼りに対応開始。とくに下記のサイトは大変お世話になりました。ありがとうございます!
まずは小さいプラグイン (SiteFeedback / とくに公開してない) でポーティングの練習をし、その後 Banner, Issue Templateの順ですすめてみました。

2. RAILS_ENV=test にしてテストしたのだけれど…

ひとまずポーティングが完了したのですが、プラグインの幾つかはr-labsのJenkinsにお世話になっています。(RORもテストコードも良くわかっていないのですが、見よう見まねでテストコードを書き、Jenkinsでテストを通させていただいてます)
このジョブ、当然のことながら、いままでのステップを使ってソースだけ変わっても失敗…。せっかく勉強を兼ねてテストする習慣がついたのに、ここで挫折するのは勿体ない(?)
ということで、コマンドラインでのUnit Testから再度進めてみました。
そこで問題になったのが、ここ。

rake db:migrate RAILS_ENV=test が通らない!!

RAILS_ENV=production, RAILS_ENV=developmentは通るのですが、test の指定をすると、ことごとくrake taskが失敗してしまいます!
/usr/local/lib/ruby/1.9.1/test/unit.rb:167:in `block in non_options': file not found: db:migrate (ArgumentError)….
途中まではうまくいってたのに、上記のように、『そんなrake taskは無いよ(?)』といったメッセージが出てあえなく終了…。(おんなじrake taskはtest以外なら通ります)
こんな状態でどうやってテストしてるんだろう??r-labsのCode Reviewのジョブは通ってるのに??、と悩むこと一週間…。
やっと、Redmine本家で解決につながる情報を見つけました。
Toshi MARUYAMAさんのソースの通り、Gemfileを修正したところ、RAILS_ENV=test が通るようになりました…。(なお、RAILS_ENV=testのmigrationがNGなら、development or production用のDBを、そのままtest用に使うという方法もありなんですね)

3. CI(Jenkins)サーバ上で、SimpleCovのカバレッジレポートが出来ない!

RAILS_ENV=test 問題が解決しても、すぐにはテスト完璧!とは行かず、もちろん諸々直しています。書き方もちゃんと勉強してるわけではないし、RSpecとかって何?Fixturesでがんばります、な状態ですが、とにかく「カバレッジだけは高いパーセントを維持したい!」ということで、怪しいながら、ほぼほぼコードをカバーするようにテストコードを書いてみました。

#プラグインが既存のコントローラーに対するパッチだったりすると、全部カバーするには、テストコードも工夫しないといけないので、Redmine本体のtestディレクトリの中身も参考にするようになりました。

カバレッジについては、Rails3, ruby1.9, JenkinsなどのCIツールを使う場合は、SimpleCovを使うといいよ!という記事がたくさんあります。おかげ様で、その方法に従うと、自分のNotePC内で、コマンドラインでの実行では、綺麗なレポートが出てくれました。(Windows7, Ruby1.9です)
また、同じNotePC内で、Jenkinsを使ってテストを通した場合でも、綺麗なレポートが出てくれました。

ですが、r-labsのJenkinsを使ってみると、テストは通るものの、coverage/rcov 以下には、index.html しか生成されません!(で、テストは100%…)

なぜだろうと思い、ひとまず手近なCentOSで同じように組んでみたのですが、やっぱり、coverage/rcov 以下には、index.html のファイル1つしか出来ず、網羅しているコードについては何もなし。『こんな100%なんて嬉しくないよ~!!』という状態です。

なにかSimpleCovの問題に違いない....と思うこと一週間、ようやく同様の事例を発見!
コメントには『うちもだよー!』という書き込みが多数ありました。
対応としては、SimpleCov.start 'rails' じゃなくて、SimpleCov.start だけでオッケーというものが多く見受けられたので、その通りにすると、あっさり解決!
おかげさまで、サーバ上のJenkinsでもカバレッジレポートの表示が再度できるようになりました。

なお、Jenkinsに合わせた、SimpleCovの出力フォーマットだと、HTMLとしては地味な感じです。一方で、SimpleCovの標準のレポートは、それはそれは洒落ている感じです。

simplecov
わたしはデフォルトのほうがすきなので、JENKINSを使ってる(環境変数での切り替えですが)場合だけ、フォーマットを変えるという設定にしました。
if ENV['JENKINS'] == "true"
  SimpleCov.formatter = SimpleCov::Formatter::RcovFormatter
end
ということで、今回はここまで。
最後まで読んで下さった方、ありがとうございます!なにかの参考、ヒントになれば幸いです。

2012-07-12

Join Pluginを試す&Build pipline Pluginで表示してみる

 

とてもお世話になっているJenkinsさん、ほんとうにありがとうございます (_ _) 
さて、今回、こんな流れで処理を組んでみることになりました。

  • 『よーいドン!』で、処理時間の異なるジョブを同時に起動
  • 両方オッケーになったら後続のジョブにうつる。

このあたりの処理の組み方は、いろんな方法があるかと思います。

ただ、自分以外にも設定を調整してもらう必要があるので、ひとまずあんまりコードを書いたり、複雑な設定をしなくてもサクッと実現できそうなもの…と思って取り入れたのが、Join Pluginです。

せっかくなので、設定のスクリーンショットと、こんなふうに検証してみた、というのを載せてみます。

1. ジョブの準備

実際のジョブはいろんな処理をしますが、とにかくよーいドン、のあと時間差でジョブが終了するというものを確認するために、こんなジョブを用意しました。

試しているのはWindows Server上です。

  1. Nightly-1: 定時に起動する。ただし、後続の2、3のジョブを起動するだけで何もしない。
  2. Nightly-2: 1から起動。”ping –n 30 localhost” というWindowsバッチを起動するだけ。
  3. Nightly-3: 1から起動。”ping –n 20 localhost” というWindowsバッチを起動するだけ。問題なければ2よりも先に終わるハズ。
  4. Nightly-4: 2&3が両方成功した後に実行して欲しいジョブ。これも “ping –n 10 localhost” するだけ。
  5. Nightly-5: 4の終了後に実行。

2. Join Pluginでの設定

さて、実際の設定は、Nightly-1 で行います。

通常のように、後続ジョブとして2&3を設定しますが、さらに、Join Trigger というビルド後のオプションを使い、『全ての下流ジョブが完了したら実行するジョブ』を設定します。今回の例では、Nightly-4を設定します。

config

設定は、ほんとにこれだけです。なお、両方とも成功、というのではなく、両方不安定でもJoinさせるというオプションも選べます。(両方失敗してても、とにかく両方とも終わったらJoinさせる、ということも、いろんなプラグインを組み合わせれば可能です)

ちなみに、最初にこのプラグインを試したのは、1年以上前。説明は英語なので、文面は良く分からなかったのですが、プラグインのページに、スクリーンショットがたくさんあったのも決め手でした。
不明点は、とにかく設定して実際の動きを確かめるという、地味な?方法を取りました。

3. どんな動きになるのかな?

では、実際に処理を実行してみると…。
後続ジョブの追跡は、下記のようなプラグインを使うと判りやすくなります。

Dependencency Graph View を利用できればいいのですが、こちらは画像生成のために専用のライブラリ・バイナリ(graphviz)が必要で、マスタがWindows Serverの場合はちょっと無理?

ひとまず実績から流れをつかめればいいのであれば、後者2つはWindowsでも問題無しです。
とくにBuild Pipline Viewは、見ても楽しいし!

さらに、可視化された形でジョブの実行時間も把握できるし、いろんなアイコンをクリックすると、コンソール出力を表示できたり、途中からジョブを起動できたりと、おススメです。

4. Join Pluginを使ったケースでは?

お試しのケースでは、こんな表示になります。

Build No. 10では、Nightly-1を起点に、後続の2&3が並行して走ります。

設定上はどちらでもNightly-4を呼び出せるようになっていますが、最終的に、あとで完了するNightly-2が、Nightly-4を呼び出しているのが分かります。(Nightly-3からNightly-4の流れは設定としては存在していますが、水色になっていて、実行もされません)

jointrigger

次に、Build Number 11で、Nightly-3が必ず失敗するように設定を変えてみました。(Windowsサーバで、”ls-la” して失敗させる処理を追加)
Nightly-3が失敗すると、Nightly-2が成功しても、その後の処理には遷移していません。(水色になったままです)

ひとまず、検証目的で、pingを打つだけの簡単なジョブを組み合わせてみましたが、想定したような処理ができそうでした。

* * *

ここから実際に呼び出すプログラム、スクリプトをくっつけて、最終的に仕上げていくことになります。また、一連の処理を行っている時に、ほかのジョブが並行で走って欲しくはないケースもあるので、排他制御の設定を加えて行く感じになっています。(ビルドの同時実行数を制限したり、優先順位をつけたり、排他制御用のプラグインをつかったりします)

わたしはプログラムのビルド、テストという仕事ではJenkinsを使っていないので、今回も、ほんとにプラグインの紹介をするだけの内容になってしまいましたが、設定事例を載せてみましたので、何かのお役に立てたなら幸いです。

* * *

おわりに。

今月末には、Jenkinsユーザ・カンファレンス2012が開催されます。
わたしも申込みはしているのですが、ちょっと時間の工面が難しくなってきていて、怪しいです。でも、なんとか参加したいと思っています。

(話すのではなくて参加、というだけなので、偉そうなことは言えませんが…)

2012-07-06

運用ネタ: チケット削除しちゃったんですが…。

写真

技術ネタではないのですが、一応管理者としてRedmineを運用している中で、いろんな問い合わせやリクエストを受けます。
一応はご用件をお請けするものの、既存の仕組みやプラグインを使っていてもダメなケースもあります。

そんな中で、1件だけ、『チケット間違って削除しちゃいました!』という連絡がありました。

「ああ、そういえば削除されるとレコードはどうなるんだっけ?」と思い確認したのですが、destroy なので、やっぱり論理削除ではなくレコード的な削除でした。

「物理削除になっているので、バックアップから該当するデータをインポートしますか?」、と伺ったところ、その回については、ご本人がブラウザキャッシュから戻しましたとのことでご了解いただきました。(もちろんIDは変わっちゃってます)

『うっかり消した・間違った内容を書いちゃった』、という場合に、特にメールが出てしまう仕組みが仇になることもあります。なので、実はメールは嫌いです…(^^;

#その他にも、メール機能についてはいろんな理由があるのですが、管理者としては嫌いなのでした…。