« 【公開】第6回RxtStudy発表資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ダイジェスト版)」 #RxtStudy | トップページ | Redmine on JRuby part3~RedmineはJRuby+Tomcatで動かす方が簡単 »

2012/10/21

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

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

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

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

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

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

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

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

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

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

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

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

|

« 【公開】第6回RxtStudy発表資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ダイジェスト版)」 #RxtStudy | トップページ | Redmine on JRuby part3~RedmineはJRuby+Tomcatで動かす方が簡単 »

Agile」カテゴリの記事

ソフトウェア工学」カテゴリの記事

コメント

あきぴーさん、ご紹介ありがとうございました。

スライドの中には「基幹系業務システム」「経営情報データ」といった言葉には触れていませんが、まさにこちらに書いてある通り、データ集計、データ集計にたどり着くためのデータ収集をバッチでこなしています。
(的確な表現をありがとうございました!)

それまでは、バッチの状況やスケジューリングは個々のサーバに閉じてしまっており、ある上流サーバの処理が終わっていなかったため、下流の処理が出来ない、失敗するということも多かったのです。

Jenkinsで繋げると、時間に縛られず、上流ジョブの処理が終わったら下流を実行するという、イベントドリブン的な流れに置き換えることができました。

このため、『必要になるかならないか判らないけど、どにかく定時に実行する』という仕組みから、『必要になった時に(呼び出しを受けて)実行する』という組み方が出来るようになっています。

失敗談ももちろんありますが、プロダクト開発ではないけれど、自分も含め自動化に取り組んでくれた部署のみんなのアクションが、こんな感じで外の方にも受け入れていただけると、本当にうれしいです。

今後、『品質の向上』『安定配布』という点にもっと目を向けていくと、おそらく開発テストの手法なども応用できるんじゃないかと思っています。

投稿: akiko | 2012/10/22 09:34

akikoさん、コメントありがとうございました。
スライドを読んでたくさんインスパイアされました。

「Jenkinsで繋げると、時間に縛られず、上流ジョブの処理が終わったら下流を実行するという、イベントドリブン的な流れに置き換えることができました。」という指摘は、まさにビルドジョブがバッチジョブと同じように、ジョブフローという流れで順次実行される仕組みと同じですね。
基幹系業務システムのバッチ設計と全く同じです。

Jenkinsを単なるCIツールだけでなく、メトリクス収集ツールやバッチ監視ツールとして使うアイデアはたくさんの可能性を秘めている、と改めて痛感しました。

投稿: あきぴー | 2012/10/22 23:12

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« 【公開】第6回RxtStudy発表資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ダイジェスト版)」 #RxtStudy | トップページ | Redmine on JRuby part3~RedmineはJRuby+Tomcatで動かす方が簡単 »