Jenkinsをバッチ監視ツールとして運用する事例

@akiko_pusuさんが公開されたJenkinsによる運用事例の資料が素晴らしいのでリンクしておく。
Jenkinsはたった一つのツールに過ぎないが、たくさんの可能性を秘めていると思う。

【皆のつぶやき】
Twitter / 検索 - 20121019-jenkins-akiko_pusu.pdf

Twitter / udzura: 凄く心に響きました…… / “20121019-jenkins-akiko_pusu.pdf” http://htn.to/m5MjUJ

20121019-jenkins-akiko_pusu.pdf from akiko_pusu

Jenkinsの元々の目的は、ソースのビルド管理だろう。
だが、「高機能なCron」という隠れた機能がある。
この機能を使って、Unixのパイプラインのように、定型的な処理をバッチ処理のジョブでつなげる。
すると、定期的に決まった日や時間帯に動くバッチ処理になる。
この発想は、日々のバックアップ処理や、サーバー間のデータ転送、ログ監視やログ集計などにも適用できる。

上記資料の中にあるフレーズがとても印象深い。
「それまで単純に個々のサーバのCronやバッチ処理という扱いだったものが、成果物を出すための一連の「ビルド」という考え方に変わっていきました」
「データソース＝SCM」
「SQL・解析処理＝ビルド」
「レポート＝成果物」
「レポート配布＝Continuous Deliverly」
「Continuous Deliverlyに近いのかな、と感じています」

最後の一文は、PMBOKで言うならば「実績報告プロセス」「情報配布プロセス」に同一視できるだろうと思う。
進捗・実績レポートをPM自らが配布するのでなく、システムで自動化する仕組みを作ってしまえばいい。

基幹系業務システムでは、バッチ処理はまさにシステムの生命線だ。
例えば、日次で日々の売上データを集計したり、月次で在庫を確定して、毎月の損益計算書や貸借対照表を出力する。
部門別やグループ別、商品別、補助科目別の試算表は、経営者が一番気にする部分だろう。
それらのデータを元に、経営状態を精査して経営方針を微修正していく。

経営者と同じように、サーバー保守の担当者も、日々の定型的作業をバッチ処理のジョブとしてプログラム化してしまい、Cronで実行するように自動化すればいい。
更に、ログを収集して、日時や月次報告の資料の元ネタになるように、整形出力してもいい。
毎月のログ集計結果から、リスクを検知したり、予防対策を立てることに役立てることもできる。

Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索

基幹系業務システムのバッチ処理は普通はCobolが今も主流だ。
でも、Jenkinsをバッチ監視ツールとして使う場合、AntやMavenやGradleのようなビルドスクリプトだけでなく、PerlやRubyのようなスクリプト言語の方が相性がいい。
なぜなら、テキストファイルを作成・削除したり、正規表現で検索・置換するなどの処理が多いので、スクリプト言語の方が書きやすいからだ。

上記資料は、ツールがプロセスを改善するだけでなく、組織も変えてしまう事例の一つとして興味深い。