自ら肥え太る執事を現場に入れてみた

Jenkins勉強会大阪第４回

自ら肥え太る執事を現場に入れてみた

Agenda● 自己紹介● 本日の目的● そのまえに…

– 背景となるプロジェクトの説明– ３つの問題・お困りごと

● 「全回帰テスト実行環境」をつくろう

● 「JenkinsとSCMとを連携させる道具」を作る

– SCM to CI synchronizer● デモします● やってみて…

– やってみてわかったこと– 困っていること

– 今後やるorやりたいな

– 伝えたいこと

自己紹介

三浦一仁(ミウラカズヒト)

● @kazuhito_m● ３５歳児、独身

● 慢性中二病患者

● 「おもろい＆便利」至上主義者

● 自動化厨

● 得意技：手段の目的化

● 弱点：手段の目的化

● 苦手：英語と算数

● ハーモニカが好き

● 株式会社ヨドック所属

● 興味あるもの

– 無入力ライフログ

– 組込以上,PC未満ガジェット

● 例：ラズパイ等– 「自動的に～」な便利な仕組

– 歌(PG)って踊(インフラ)れるエンジニア

– “軸”はLinuxとRuby(最近サボリぎみ)

本日の目的

● 「こんなことしました！」のご紹介● 「明日から使えるモノ」の共有

それにプラスして…

自身も「定石」を知らないので、皆様教えて!＆アイディア下さい!


自ら肥え太る執事を現場に入れてみた

その前に…


背景となるプロジェクトの説明

背景となるプロジェクト-あらまし● 基幹システム(COBOL)のリプレース● 言語はJava、データはRDBMS(某社製)● このプロジェクト用の独自FW

– ５～６年前のJava界トレンドが…● Maven2,Struts,Spring,ORM(自作

● ソース管理はSubversion (以下、略称SVN)● Web画面とバッチ処理

– １機能:１Javaプロジェクト● Web画面 – war● バッチ1ジョブ – jar

特徴● システムの構成システム

サブシステム

分類

業務機能

× 3

× 約25

× 約120

サブシステムごとにJavaPrjが約1000ずつ

およそ3,000のJavaプロジェクト(jar/war)※現在も日々増殖中

＝Javaプロジェクト

特徴

● Javaプロジェクトの論理的種類

業務機能

機能モジュール

バッチジョブ(jar)・バッチ１ジョブ

or

Webアプリ(war)

・2～3ページのWebアプリ

機能共通モジュール(jar)

・機能モジュール間のビジネスロジック共有

汎用共通モジュール(jar)

・「DB参照アリ」のUtilみたいなもの例:日付取得等「業務色の薄い」ロジック

利用

利用

利用

構成管理/実装単位

「業務機能」命名則の統一：[サブシステム名]-[分類名]-[機能番号]

pom.xmlのArtifactIdpom.xmlのArtifactId

Javaプロジェクト名（IDE内での認識）

● SVNの利用形態

– リポジトリTopに,trunk,branches,tagが並び、その下にJavaプロジェクトのディレクトリが並ぶ形

独自文化● 「データファースト」のアプローチ

● 単体テストの基準

– 確認対象はDBテーブル、確認基準は「DB変化の有無」

● 独自テストFW

– テスト仕様書からテストコード

– テストデータはExcel● 対象はRDBMS● 1ケース：1ファイル、初回実行時テンプレ作成● 複数テーブル1シート● 投入、確認(diff)用の２シート● 所定の場所に置くと、投入し実行し確認する

– Seasar2のS2Unitと類似

※この頁のすべての画像はイメージです。実際のものとは異なります。

独自文化- プログラマーさんのお仕事

Lan内独自リポジトリ

基本仕様書

※個々端末にExpressEditon

IDEテスト用ローカルDB

DDL DTO.jar

準備:ローカルにDBのガワ作る

※DDLとO/Rマッパ用クラスはプログラムとは別にニコイチで独自管理・リリースされている。

①基本仕様書を元にプログラミングする

単体テスト仕様書

②基本設計書を元に単体テスト仕様書を作る

テストクラスソース

Javaプログラム

テストデータテンプレート

③単体T仕様書からテストクラスとデータテンプレートを生成する

④テストデータ作りテスト実施、レビューを受ける

Jar/warモジュール

⑤ビルドしMavenサーバにアップロードする

● Javaプロジェクト一つ作るには

プログラマーさん


３つの問題・お困りごと

問題 - お困りその１

● 「テスト回りました！完了！」…のはずなのに環境依存が酷い

– テスト用DB作成も、「ビルド→Mavenリリース」するのも、すべて「開発PC」

問題 - お困りその２

● 「自動テストを毎日回す仕組み」が無かった

– 「ある変化」による「翌日大量死」などを一切検出できず

問題 - お困りその２…に抗った死屍累々● チームの努力で…

– 「全回帰テスト実行環境」を作っていた– 日々「回す」「記録をとる」仕組みを作った

● 初代–Win(DOS)バッチ & タスクスケジューラ–細かな制御が出来ず取り回し悪し

● 二代目–Linuxシェル& Javaプログラム & cron–細かく制御できたがパーツが多い–履歴取り・可視化が人系で…

● それすら…

– 一年後、行われなくなっていた

私見-「自動テストを作成・実行する意味」● 大きく三つ

1.テストの過程・手段の明確化

2.テストの再現性

3.「日々変化」での不具合検出● 前提は「日々回す」

– 回す(再利用)しないと価値がダダ下がり！● 自分が「回帰テスト」を知ったきっかけ

– 「ナイトリービルド」の記事● 「90年代シリコンバレーの常識」と聞いたが…● 「ナイトリービルド」が常態であるべし● 壊したら次の日怒られる

問題 - お困りその３

● リプレイスだが「新規機能」が日々増える！

–開発期間中に増えていく！–保守フェーズでも増える！–…だのに追随できない

ここが今回の「発表の起点」

「日々増える」に追随できない…

重要なので二回言いまし(ry

「日々増える」に追随できない…

逃げ…ダメ…

問題

なんとかしたい…


と、ここまでが前フリで…


自ら肥え太る執事を現場に入れてみたやっと本題！

急にボールが来たので…

「全回帰テスト実行環境」を作ろう

三代目ッ！

こんなんならいいなぁ…● 自分からプロジェクトの空気を読んでくれる

– 勝手に「増えたプログラム」を認識する– 何も言わなくてもテスト回しといてくれる

テスト、回しておきました。

ソースが追加されているな…

こんなんならいいなぁ…● こちらから言わなくても「教えて」くれる

– プッシュ型– 無論「こちらから聞いて」も教えてくれる

あの件どうなりました

ええ、ばっちりうまくいきました！

ソースが増えていたので、テスト

回しておきました。

さらに言うなら

出来るだけ”在りモン”でできたら

うれしいな…

＞突然の…＜

私をお呼びですかな…

＞突然のJenkinsさん！＜

私をお呼びですかな…

余談- Jenkins師匠のここがステキ！● Jenkinsって何ぞ？

– 「何か」を「登録」すれば「蹴ってくれる」仕組み● そんなのいっぱいあるじゃんｗ

● 自分に「ドンピシャ」な理由

– 暗黒世界を「絵ヅラ」で見れる、見せられる● 出来ることは「コンソール」同様、また設定要● 「実行状態を観察出来る」「誰でも見られる」の威力

– キックタイミング(実行/駆動きっかけ)が豊富– Java/Mavenがデフォルト

→最大限に利用しよう！

で、考えてみた

DBサーバ

と、言うのが「毎日勝手に回る」といいな！


テストスキーマ

①①ソースの追加を監視ソースの追加を監視自身自身JobJobに反映するに反映する

②②最新の最新のDDLDDLを取得を取得テストスキーマ構築テストスキーマ構築

③③最新プログラム最新プログラムソースを取得ソースを取得

④④プログラムソースをプログラムソースを「テスト用」に最適化「テスト用」に最適化

⑤⑤最新モジュール群最新モジュール群を取得しビルドを取得しビルド

⑥⑥テスト実行！テスト実行！

⑥⑥テストの結果をテストの結果を関係者にメールで報告関係者にメールで報告

足りないものは？

DBサーバ










今回のメインは、ここのお話


「Jenkinsとソース管理システム(SCM)とを連携させる道具」

-SCM to CI synchronizer-を作る

やりたいことは● ソース管理システム(SVN)のディレクトリを調べる

● Javaプロジェクトが増加すれば、Jenkins側に「お手本Job」を一部変更したJobを追加

やりたいことは● 一日一度、一斉に流したい

– Jenkins中に「キッカーJob」を設けておいて、「ビルド後の処理-他のプロジェクトのビルド」に結び付ける

どうしたら出来る？● SVN側

– 起動都度「そのディレクトリのリビジョン番号」の最新を覚えておく

– 前回と今回のリビジョン番号の間で「追加されたディレクトリ」の名前を割り出す

● Jenkins側

– SVN側のディレクトリ名＝JenkinsのJob名– 「お手本Job(テンプレート)」から「Jobごとに変わ

る部分」だけ書き変えたものを登録● 「Job名」や「ソースのSVN-URL」など

問題は…● SVN側

– SVNには「リビジョン指定でディレクトリを一覧する」コマンドが在る

● コマンド“svn list -r [リビジョンNo] “等– SVNには各プログラミング言語から操作できるライ

ブラリが多くある

○大丈夫だ、問題無い● Jenkins側

– 「外部からJobを増殖」ってどうするのだろう…

×大丈夫じゃない、問題だ！

おでぷろぐらむとかあんまでけへんので

● Jenkinsの動きを外側から眺めてみよう！

– JenkinsはJob追加の際、処理時間は僅か数ミリ秒にすぎない

– では、その「Job追加プロセス」をもう一度見てみよう！

Jenkinsの内部(超絶ざっくり)● プログラムやリソース

– War とそれが展開されたディレクトリ

● データに属するもの

– $HUDSON_HOME で与えられたディレクトリ

JenkinsにJobを追加した場合● $HUDSON_HOME/jobs/ にディレクトリが追加さ

れ、config.xml ファイルが出来る

JenkinsにJobを変更した場合● $HUDSON_HOME/jobs/[Job名]/config.xml

ファイルが変更される

● Jenkinsのデータ周りの設計はかなり素直

– 画面と設定ファイルは「ほぼ写像」

– ディレクトリ構成も推測を越えない● Jobは手動で追加・更新して、再起動しても認識した

– Jenkins側は「ディレクトリとファイルがあれば」しか見ていない

– 最悪「スケジューラで日に一度再起動」しとけば良い● 「最低限の手段」確保、これで勝つる！

もう少しインテリジェンスな方法を

●先の方法では「Jenkinsサーバ内部から」しか操作できない

●外部から操作できないか？

どっちが良いだろうか

1.Jenkins Remote access API– https://wiki.jenkins-ci.org/display/JA/Remote+access+API

– 公式曰く「RESTのような形式」

– 公式曰く「一体何ができるの？→ジョブ作成、コピー」

– 個人的に「LAN内のJenkins探索」面白そうw

→総じて「自分ではハマリそう…」

2.Jenkins-CLI– https://wiki.jenkins-ci.org/display/JA/Jenkins+CLI

– 別PCのコンソールからJenkinsを操作できる

● ただし、そのPCに”jenkins-cli.jar”が必要– java -jar jenkins-cli.jar -s [サーバ] [コマンド]

→こっちのほうが楽そう♪

https://wiki.jenkins-ci.org/display/JA/Remote+access+API

https://wiki.jenkins-ci.org/display/JA/Jenkins+CLI

CLIを使うとしても● 普通にやると…

自作JavaProgram Jenkins-cli.jar

コマンドライン

Java -jar jenkins-cli.jar ...

コマンドキック！※多分Runtime.exec() とか…

通信！

自PC　ネットワーク

– なんかヤダ！(そこはかとなく原始人っぽい)● うわっ、Javaを使って「jarをコンソールから実行」って、私のPG

レベル低過ぎ…？

● これならどうか自作JavaProgram

Jenkins-cli.jar

自PC　ネットワーク

通信！

– ボク満足！

– 「コマンド」と「CLIのJava内部Interface」ってどちらが…

● 仕様変更の可能性、中の人はこの使い方望んで無さそう…

コマンド動作をエミュレート

以前の「ソース読んだ」と言ったのはココとココ

CLIを使って「Jobを追加する」● コマンドでJenkinsさんに「Job１つ分のファイル」を送りつけ

る

– “cat config.xml | java -jar jenkins-cli.jar create-job [ジョブ名]”

● 標準入力からなので、自力でリダイレクト

を、自作プログラム(java)でエミュレート

CLIを使って「Jobを更新する」

1.コマンドでJenkinsさんから「Job１つ分のファイル」を取得する

– “java -jar jenkins-cli.jar get-job [ジョブ名] > config.xml”

– 標準出力から出すので、自力で保存

2.取得した「Job１つ分のファイル」の一部を変更

– 今回は「他のプロジェクトのビルド」-「ビルドするプロジェクト」の末尾に文字列を加える

3.コマンドでJenkinsさんに「Job１つ分のファイル」を送りつける

– “cat config.xml | java -jar jenkins-cli.jar update-job [ジョブ名]”

● 標準入力からなので、自力でリダイレクト

を、自作プログラム(java)でエミュレート

やることは決まった！実装方法は？● 「Maven Plugin」で！

– 予想されるツッコミ「Jenkins Pluginちゃうんかい！」

● 理由

– その時の「マイブーム」● 興味在り探求中＆手に馴染んでた

– 「コマンドラインキックのツール土台」としての「必要と思われる装備」を備える

● 設定ファイル、引数、Log、etc + Javaの資産● Mavenの「依存性解決」はデフォルト装備

– 他端末のコマンドラインでもJenkinsのJobでも蹴れる

● 「Mavenインストールされてれば」どの端末からでも● Jenkinsは親和性高、pom.xmlさえあればOK

maven-pluginについて知りたい方は…

●続きはWebで！

http://www.slideshare.net/guestd4898b/maven2


するまでもない「なんちゃって設計」

実装

※絵面はイメージです。

なんだかんだあって…

できました！

https://github.com/kazuhito-m/maven-scm2cisync-plugin

※業務で使用したものではありません。すべてリライトしています。

http://github.com/kazuhito-m/maven-scm2cisync-plugin

「やりましたやりました詐欺」がひどいので

デモしまーす

● デモ環境での特殊事情

KVMは、Linuxカーネルに搭載された"仮想OSスーパーバイザ”です(VMWare等と同じ)

全ては、この発表用ノートの中で起きている出来事。

デモします● 前提


・SVNは、Javaプロジェクトが多く登録された状態

シンク用SVN 兼 Mavenリポジトリごった煮サーバ

192.168.1.219

192.168.1.23X

主役のJenkinsサーバ(群)

この発表用ノートPC

・テストのため、大量に作りクローン

・初期状態は「ほぼピュア」

・Javaは入れてある (OpenJDK7)・maven-pluginの

"scm2cisync-plugin”は、ビルド・mavenリポジトリ登録済み。

・scm2cisync-pluginを動かす用設定ファイル群は、SVNサーバに登録済み。

有線LAN

デモします● お品書き

1. Jenkinsインストール

2.Jenkins-pluginをお好みで導入

3.SVNサーバからプロジェクト一つJenkinsに登録

お手本プロジェクト、模範的な設定に

4.config.xml を抽出してテンプレート化

「変化してほしいところ」に変数記述

5.SVNにテンプレートをコミット

6.scm2cisync-pluginと全JobキッカーをJenkinsに登録

7. scm2cisync-pluginを実行

JenkinsにJobが増えていたら成功！

これに● さらにプラスして

– DBスキーマをリフレッシュしてくれる仕組み

– 実行前にテスト対象プロジェクト最適化の仕組み

完成！三代目！！

DBサーバ










「自ら肥え太る」「自ら肥え太る」

執事さん完成！執事さん完成！

使い出は？● 使い方として想定できるもの

–新規大規模案件での「日々全回帰テスト」● 今回の例です●序盤時点でプロセスに組込んでしまえば

– お客様企業にて既存Javaプログラム資産がある場合の自動回帰テスト● 「自動テスト実装済み」は必須

– 中小企業の「社内プロジェクトの全量回帰テスト」● これも「自動テスト実装済み」は必須● 自社でやってみる予定

これを言うとかないと…

やってみて…

やってみて解ったこと● 「１OS:１Jenkinsサーバ」が扱い易い

– 今回の事情として

● 「ジョブ大量増殖」することから「中央集権&クラスタ」より「根元から別ける」でJenkinsを複数たてた方が管理しやすかった

–約100個のJob越えると、なぜか「起動」が2次曲線的に遅く– サブシステム別に何台か立てるがベター

– Linux使ってリポジトリ足して自動or手動更新

● 起動・停止とインストールとアップデートの管理をOS側に任せる

– 試行錯誤をした結果…(次ページ)● JenkinsとOS仮想化は相性が良い

– 「良い」観点は「扱易さ」「簡単さ」「デリバる早さ」

– 試行錯誤が続くこと、水平展開を考慮すると有用

– Jenkins＋必要な装備「デフォルトイメージ」用意、必要時に増殖

● CloudBeesさんがお手本＆素晴らしいというステマ

余談-いくつかの運用と試行錯誤● こんなのを試してみました

1台：1Jenkinsで、大量生産（仮想OS増殖)

1台に、tomcatを載せ、Jenkinsを複数インスタンス

運用

1台に、1Jenkinsで、Jobを多量に登録し、タブを使ってカテゴライズ管理

困っていること● 技術面

– 並列実行が出来ない(Executer複数化orクラスタ化)● Jenkinsサーバ１台=1つexecutorでしか動かせない

● テスト用DBの都合「executorごとに接続先変える」出来れば…

– テスト実行の終わらないプロジェクトがある

– OS依存・端末依存・環境依存がしつこく駆逐出来ない

– SCMのbranchへの対応

● 「本線より先行」が多くHotSpotが多く必要

● 「branch生存期間」的なのが解らない● 運用・プロセス面

– 観測者が居ないと意味ない

– 観測者に「促す！」手段が必要

● 管理者メールを送るも不十分● 「テストコケ始めた」「治った」等「変化」を「まとめて伝達」な手段

今後やるorやりたいな● お仕事

– 3,000プロジェクトへの全展開

● 600ごと、あるいはもう少し少ない単位での展開– 全体成績収集＆蓄積＆分析＆「促す」機構作成

– 平行化（クラスタ or Executor毎のDB振り分け化）● 個人的

– Jenkins Plugin 化!(普通そうでしょう…)● そもそも「CIサーバ」は世にあまり無い● 導入の敷居がある限り「便利」じゃない

– 他SCM対応

● gitに「PJで横並ディレクトリ」有るか解りませんが

伝えたいこと● Jenkinsなんだし…

– 「自動化の寵児(老人)」なのだから「Jenkinsのメンテナンス」も自動化しなきゃ♪

● これは流行る！● よく考えれば「あたりまえ」ですよね● クラスタ化以外で

「管理用のJenkinsから他Jenkinsを弄らせる」という考え方も…–すでにみんなやっている？

伝えたいこと● 今からJenkinsを導入する・したい皆様へ

– 本日は「ベンダー系」「旧資産リプレイス」「大規模開発」の前例をご説明させていただきました

– 明日には「前例ありますよ！」でゴリ押し導入！● …ちょっと無理強いが過ぎるので

–来週には上司・お客様に掛け合い、年明けには導入している…はず

– 本日使った「資料」「ソフトウェア」「作るための道具」はすべてタダです！

● ※発表用PCと「自身の睡眠時間」は除く● OpenSource/FreeSoftwareの違い知らん訳じゃ無い

● 反対意見・対抗勢力への材料として

以上です

ご覧いただきありがとうございました。

※宣伝「アジャイルラジオ」聞いてくださいね！http://www.agileradio.info/

http://www.agileradio.info/

参考文献/参考URL● MavenPlugin入門

– http://www.slideshare.net/guestd4898b/maven2● Jenkins Remote access API

– https://wiki.jenkins-ci.org/display/JA/Remote+access+API

● Jenkins-CLI– https://wiki.jenkins-ci.org/display/JA/Jenkins+CLI




https://wiki.jenkins-ci.org/display/JA/Jenkins+CLI

余談- 他にもこんなネタを…● 死ぬまでには誰かに伝…(王ロバ的な意味で)

– SpringAOP/DIを使用したメソッド高速化キャッシュ機構●超限定的シチュエーションながら、大規模プロジェクトにおける

AOP活用法の一例– Maven2を利用した「コンパイル以上ビルド未満のチェック」機構

● 「現場ルール」「社内ルール」「チームルール」など、「人の努力」で回っているものを自動化

– RubyとRFIDで作る「激安！勤怠記録システム」TimeSeal作ろう！● デカい会社の入り口の「ピッ！」なアレを自分のお小遣いで簡単

に作る– ソース管理システム内全検索機構の模索

●現在進行中●大規模現場でも、中小企業内でも…個人的には効果絶大と思うけどなぁ…

もうちょっと考えて● Jenkins自体からでも、外部からでも起動出来るよう

に● 「追加」は良いとして…

– 「更新」は何にも当たらない● 「ソースの変更」「Job設定変更」くらい？● 「毎日同じ様に回してくれる」がキモ、要らない

– 「削除」は「プロジェクトのSVN上での削除時」

● JenkinsのJobを削除は人が判断する想定–勝手に消されても困るだろう

● 削除の絶対量がそんなに無さそう–何もしなくて良い

● 「追加」だけ考えれば良い

没稿

デモします● 前提

– リンクするSVNサーバはLAN内に構築済み

● Javaプロジェクトが多く登録された状態で

– LAN内Mavenサーバは構築済み

– Jenkins入れるLinuxサーバは構築済み

● CentOS ６.３– maven-pluginの”scm2cisync-plugin”は、ビルド、ローカル

mavenリポジトリに登録済み

– Maven-pluginを動かすための設定ファイル群はSVNサーバにコミット済み

● pom.xml,config.xml● デモ環境の特殊事情

– 上記、SVN & MVNサーバ、またJenkinsサーバ用のLinuxも仮想OS(KVM)で、このPCに構築済み

没稿

自ら肥え太る執事を現場に入れてみた

Technology

Transcript of 自ら肥え太る執事を現場に入れてみた