Trac Lighting付属のHudsonをCI以外の目的で使ってみる

Trac

移行への道は実作業に疲れたので中休みってことで、運用を考えてみましょう。

運用といって一番最初に考えなきゃいけないのがバックアップです。
Trac Lightningにはバックアップ用のスクリプトが付属しています。
2.0.9までは改変しないとshで実行している部分の関係からWindowsのタスクに登録しても実行できませんでした。しかし2.1からの付属のbackup.batについてはタスクに登録することで実行可能になっています＼(^o^)／

となるとバックアップはWindwosのタスクに登録して定期的に実行するのが素直ですが、私は素直に登録するのは止めて『Hudson』を使っています。
Hudsonを使うメリットは

  • 任意のTimingで実行可能
  • 実行結果をクライアントから確認可能
  • 実行のログが勝手に残る
  • 追加処理がbatファイルを作成せずHudson上で登録・管理できる

の4点。
本来のHudsonの使い方とは異なりますが、実行結果の確認とbatファイルの管理がHudsonで集中管理できるのは運用面での大きなメリットになります。

簡単に言うと「やらなきゃハドソン」って感じですw



以下、Trac Lightning2.1beta3以降向けの、Hudsonでバックアップのジョブを管理する手順は以下の通りなのです。
(Trac Lightningのインストールしたディレクトリは適宜読み替えてください。)

Hudsonの起動の前準備

JDKが入っていない環境だとTrac LightningをインストールしてもHudsonは起動しません。
以下のステップを実行し起動を出来るようにしましょう。
詳細は(面倒なので)書きませんが、この以下作業をするとHudsonが起動出来るようになります。

  • JDKのインストール
  • JAVA_HOMEの設定

Hudsonの起動

スタートメニューからTrac Lightningを起動するとHudsonが自動起動します。
自動起動していない場合はスタートメニューから「Hudsonの起動」を選んで実行
その状態でHudsonのurlにアクセスすると、Trac Lightningに設定済みのジョブが二つ表示されます。
このトップ画面から左のメニュー部にある「新規ジョブ作成」をクリックし新規のジョブを作成をします。

新規ジョブ追加

まずはジョブ名とジョブの種類の設定。
ジョブ名はバックアップなので「TracBackup」とでもしておきます。
batファイルの実行を登録するので、「フリースタイル・プロジェクトのビルド」を選択。
そして［OK］ボタンを押します。

ジョブの設定

ジョブの設定画面が表示されるはずです。
プロジェクト名は先ほど設定したジョブ名が入力されてます。*1
説明を適当に入力。
説明をしっかり書いておくと後で引き継いだりとか、他人に任せるのが楽になるのでしっかり書いておくと良いでしょう。

ジョブの設定(ビルドトリガの設定)

ビルドトリガ(実行のタイミング)の設定。
バックアップなので「定期的に実行」を選択。
ここでは深夜0時に毎日実行するので

0 0 * * *

と入力。
記述方法はcron書式に準じる形ですが、記述方法が分からない場合には横にある[？]をクリックすると説明が表示されるので参考にすると良いでしょう。
それでも普段cronとかに触れないので分からないという人はこちらを参照して頑張って下さい。

ジョブの設定(バッチファイルの登録)

「ビルド」の部分で「Windwosバッチファイルの実行」を選択。

コマンドを入力するエリアが表示されるので、そこへ実行したいバッチファイルを書きます。
Trac Lightningに付属のbackup.batは TL_BACKUP_DIR という環境変数で設定されているディレクトリへバックアップしたファイルを保管しますが、実運用で利用する場合には任意の場所へ保管したいところです。
通常だと直接backup.bat中で TL_BACKUP_DIR を指定するか、もう一つバッチファイルを書いてそっちで指定するかになります。
「Command」に以下の様に設定します。(最後の行のドライブ指定はわざと間違えてます)

set TL_BACKUP_DIR=C:\TracLight\backup\%date:~2,2%%date:~5,2%%date:~8,2%
cd/d c:\trac
d:\TracLight\backup.bat

Hudsonを利用する場合には「Command」の部分に入力したテキストはバッチファイルとして実行されるので、前述のように環境変数を設定したり、カレントディレクトリを変更したりと、バッチファイルと同様の記述が可能です。
つまり付属の直接修正したり追加のバッチファイルを作成する必要がなく、サーバを直接操作しなくてもクライアントのブラウザの設定からバッチファイルを記述することが出来ます。*2
とここまで設定したら［保存］ボタンを押して設定完了。

ちなみに上記例ではバックアップの保管先は C:\TracLight\backup の YYMMDD というディレクトリに設定してバッチファイルを実行するように指定しています。
このあたりは各自の運用に合わせて、世代管理するなり他のサーバへコピーするなり任意の方法を検討しましょう。

ジョブのテスト実行

設定が完了すると、設定したジョブ画面になります。
プロジェクト名(ジョブ名)と説明が表示され左のメニューからはジョブに対する処理が選択できます。
先ほど定期実行として設定しましたが、左側のメニューから「ビルド実行」をクリックし実行することで即時実行します。
設定内容を確認したい場合には「設定」をクリックし確認します。

実行結果の確認

左側にあるビルド履歴から最新のモノを選んでクリックします。
通常ここにはSubverison関連の情報等がでますが、今回はバッチファイルの実行なので用事があるのは「コンソール出力」です。

コンソール出力の確認

コンソール出力にはバッチファイルの実行結果が表示されてます。
コマンドプロンプトで実行した結果が保存されているイメージです。
Windouwsのタスクで登録するとこのへんの処理も別途書かなきゃ確認できませんが、Hudsonを利用した実行の場合には勝手に保管されているので非常に便利です。
で確認すると、見事に先ほど設定したCommandが間違っていて実行出来ていないのが確認できます。

エラー内容を確認したら、「プロジェクトへ戻る」をクリックします。

ジョブの修正

ジョブのページの左側メニューから「設定」をクリックしジョブを修正します。
ディレクトリの指定が間違っていたので修正して保存します。

二度目の実行

修正が終わったら、再び即時実行。今度は間違えていないので実行に時間がかかるはず。
処理の進捗はビルド履歴の部分にプログレスバーで表示されます。
プログレスバーの表示表示中もビルド履歴を開けるので、終わる前に慌てて開いてみましょう。

実行中のコンソール出力

実行中でもコンソール出力を表示することが出来ます。
実行中はリアルタイムにコンソールにリダイレクトされた文字列が表示されるので、実行を生暖かく見守ることが可能。この辺りもWindowsのタスクと異なり非常に安心感があって私はお気に入り。*3

実行の確認

コンソール出力にエラーが表示されなければ無事に実行は完了です。
これで定期的にバックアップの処理がHudsonによって実行されます。
実運用では毎日定期的にHudsonを開いてコンソール出力を確認すると良いでしょう。*4

まとめ

ここまでの設定でバックアップはHudson化出来たと思いますが、Trac Lightning2.1からはSearchHyperEstraierPluginも同梱され定期的に実行すべき処理が増えてます。
Trac Lightning2.1rc1の時点ではHyperEstraier用のIndex作成のバッチは付属しませんが、Index作成の処理をHudsonに設定して実行してみるのはどうでしょうか？
ウチの環境ではバックアップ実行後に続けてHyperEstraier用のIndex作成処理を実行するようにしてます。
他にもTracDoxygenPlug-inを使っているので、Maven使っていないプロジェクトでもDoxygenの生成をHudsonにやらせていたりもしてます。
Maven使ってないのでHudsonは関係ないと思っている人も、Windowsのタスクよりも管理が楽で実行結果の確認が簡単なHudsonでの実行は個人的にはお奨めなので是非挑戦してみてください。

それとTrac Lightningをサービス化と、id:kaorun55さんのとこで解説のあるHudsonのサービス化を行うサーバをログイン状態にする必要が無くなるので、trac LightningとHudsonを本格的かつ積極的に使うのであれば検討したほうが良いと思います。

*1:なぜかジョブ名じゃなくてプロジェクト名となりまふ。混乱しないように注意

*2:どこまで出来るかは試してませんが処理のログを見ていると結構なんでも出来そうな気配。

*3:実際Windowsのタスクは実行状況の確認等が面倒なので個人的には好きじゃない

*4:基本的にこの設定ではビルドの失敗は、Command設定ミス以外では発生しません。
それはHudsonのWindowsバッチファイルの実行では、Commandに記載された最後のコマンドのエラーレベルが1以上で終了しなければ失敗とならないからです。
つまり今回の例ではbackup.batの実行途中でエラーとなっていないかの確認はコンソール出力で確認する必要があります。