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

5,391 views

Published on

Jenkins勉強会大阪 第4回 (2012/12/21) にて発表した資料です。
まとめサイト : https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=65669255

また、2016/10/22 企業の勉強会にて「アレンジして再演」しました。(スライドはその時のものです)

Published in: Technology
0 Comments
13 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,391
On SlideShare
0
From Embeds
0
Number of Embeds
94
Actions
Shares
0
Downloads
18
Comments
0
Likes
13
Embeds 0
No embeds

No notes for slide

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

  1. 1. 第04回 大阪Jenkins勉強会 自ら肥え太る執事を 現場に入れてみた Ver 2.0 2016年版
  2. 2. お断り この資料は 「2012年12月に発表したものに 加筆・修正したもの」 です。 当時、主流だった技術や 「自身が当時の考え」で 変化があったものについて、 アレンジしています。 アレンジ部分には、元のものには 新しいものには という表記を付記しています。 2012年版 2016年版
  3. 3. 自己紹介 三浦 一仁(ミウラ カズヒト) • @kazuhito_m • 39歳児、独身 • 慢性中二病患者 • 「おもろい&便利」 至上主義者 • 自動化厨 • 得意技:手段の目的化 • 弱点:手段の目的化 • 苦手:英語と算数 • フリーランス • 興味あるもの – 無入力ライフログ – 組込以上,PC未満ガジェット • 例:ラズパイ等 – 「自動的に~」な便利な仕組 – 歌(PG)って踊(インフラ)れる エンジニア 2016年版
  4. 4. 本日の目的 • 「こんなことしました!」のご紹介 • 「明日から使えるモノ」の共有 それにプラスして… 自身も「定石」を知らないので、 皆様教えて!&アイディア下さい!
  5. 5. 第04回 大阪Jenkins勉強会 自ら肥え太る執事を 現場に入れてみた その前に…
  6. 6. 第04回 大阪Jenkins勉強会 背景となる プロジェクトの説明
  7. 7. 背景となるプロジェクト-あらまし • 基幹システム(COBOL)のリプレース • 言語はJava、データはRDBMS(某社製) • このプロジェクト用の独自FW –8~10年前のJava界トレンドが… •Maven2,Struts,Spring,ORM(自作 • ソース管理はSubversion (以下、略称SVN) • Web画面とバッチ処理 –1機能:1Javaプロジェクト •Web画面 – war •バッチ1ジョブ – jar 2016年版
  8. 8. 特徴 • システムの構成 システム サブシステム 分類 業務機能 × 3 × 約25 × 約120 サブシステム ごとに JavaPrjが 約1000ずつ およそ3,000のJavaプロジェクト(jar/war) ※現在も日々増殖中 =Javaプロジェクト
  9. 9. 特徴 • Javaプロジェクトの論理的種類 業務機能 機能モジュール バッチジョブ(jar) ・バッチ1ジョブ or Webアプリ(war) ・2~3ページのWebアプリ 機能共通モジュール(jar) ・機能モジュール間のビジネスロジック共有 汎用共通モジュール(jar) ・「DB参照アリ」のUtilみたいなもの 例:日付取得等「業務色の薄い」ロジック 利用 利用 利用
  10. 10. 第04回 大阪Jenkins勉強会 3つの 問題・お困りごと
  11. 11. 構成管理/実装単位 「業務機能」命名則の統一: [サブシステム名]-[分類名]-[機能番号] pom.xmlのArtifactIdpom.xmlのArtifactId Javaプロジェクト名 (IDE内での認識) • SVNの利用形態 – リポジトリTopに,trunk,branches,tagが並び 、 その下にJavaプロジェクトのディレクトリが 並ぶ形
  12. 12. 独自文化 • 「データファースト」のアプローチ • 単体テストの基準 – 確認対象はDBテーブル、確認基準は「DB変化の有無」 • 独自テストFW – テスト仕様書からテストコード – テストデータはExcel • 対象はRDBMS • 1ケース:1ファイル、初回実行時テンプレ作成 • 複数テーブル1シート • 投入、確認(diff)用の2シート • 所定の場所に置くと、投入し実行し確認する – Seasar2のS2Unitと類似 ※この頁のすべての画像はイメージです。実際のものとは異なります。
  13. 13. 独自文化- プログラマーさんのお仕事 Lan内独自 リポジトリ 基本仕様書 ※個々端末に ExpressEditon IDEテスト用 ローカルDB DDL DTO.jar 準備:ローカルにDBのガワ作る ※DDLとO/Rマッパ用クラスは プログラムとは別にニコイチで 独自管理・リリースされている。 ①基本仕様書を元に プログラミングする 単体テスト 仕様書 ②基本設計書を元に 単体テスト仕様書を作る テストクラス ソース Java プログラム テストデータ テンプレート ③単体T仕様書から テストクラスとデータ テンプレートを生成する ④テストデータ作り テスト実施、レビューを受ける Jar/war モジュール ⑤ビルドしMavenサーバに アップロードする • Javaプロジェクト一つ作るには プログラマーさん
  14. 14. 第04回 大阪Jenkins勉強会 3つの 問題・お困りごと
  15. 15. 問題 - お困りその1 • 「テスト回りました!完了!」 …のはずなのに環境依存が酷い –テスト用DB作成も、 「ビルド→Mavenリリース」する のも、 すべて「開発PC」
  16. 16. 問題 - お困りその2 • 「自動テストを毎日回す仕組み」 が無かった –「ある変化」による「翌日大量死」 などを一切検出できず
  17. 17. 問題 - お困りその2…に抗った死屍累々 • チームの努力で… –「全回帰テスト実行環境」を作っていた –日々「回す」「記録をとる」仕組みを作った • 初代–Win(DOS)バッチ & タスクスケジューラ –細かな制御が出来ず取り回し悪し • 二代目–Linuxシェル & Javaプログラム & cron –細かく制御できたがパーツが多い –履歴取り・可視化が人系で… • それすら… –一年後、行われなくなっていた
  18. 18. 私見-「自動テストを作成・実行する意味」 • 大きく三つ 1.テストの過程・手段の明確化 2.テストの再現性 3.「日々変化」での不具合検出 • 前提は「日々回す」 – 回す(再利用)しないと価値がダダ下がり! • 自分が「回帰テスト」を知ったきっかけ – 「ナイトリービルド」の記事 • 「90年代シリコンバレーの常識」と聞いたが… • 「ナイトリービルド」が常態であるべし • 壊したら次の日怒られる
  19. 19. 問題 - お困りその3 • リプレイスだが 「新規機能」が日々増える! –開発期間中に増えていく! –保守フェーズでも増える! –…だのに追随できない
  20. 20. ここが今回の「発表の起点」 「日々増える」に 追随できない…
  21. 21. 重要なので二回言いまし(ry 「日々増える」に 追随できない…
  22. 22. 逃げ…ダメ…
  23. 23. 問題 なんとかしたい…
  24. 24. 第04回 大阪Jenkins勉強会 と、ここまでが前フリで…
  25. 25. 第04回 大阪Jenkins勉強会 自ら肥え太る執事を 現場に入れてみた やっと本題!
  26. 26. 急にボールが来たので… 「全回帰テスト 実行環境」 を作ろう 三代目ッ!
  27. 27. こんなんならいいなぁ… • 自分からプロジェクトの空気を読んでくれる – 勝手に「増えたプログラム」を認識する – 何も言わなくてもテスト回しといてくれる テスト、 回しておきました。 ソースが追加 されているな…
  28. 28. こんなんならいいなぁ… • こちらから言わなくても「教えて」くれる – プッシュ型 – 無論「こちらから聞いて」も教えてくれる あの件 どうなりました ええ、 ばっちりうまく いきました! ソースが増えて いたので、テスト 回しておきました。
  29. 29. さらに言うなら 出来るだけ ”在りモン”でできたら うれしいな…
  30. 30. >突然の…< 私をお呼び ですかな…
  31. 31. >突然のJenkinsさん!< 私をお呼び ですかな…
  32. 32. 余談- Jenkins師匠のここがステキ! • Jenkinsって何ぞ? – 「何か」を「登録」すれば「蹴ってくれる」仕組み • そんなのいっぱいあるじゃんw • 自分に「ドンピシャ」な理由 – 暗黒世界を「絵ヅラ」で見れる、見せられる • 出来ることは「コンソール」同様、また設定要 • 「実行状態を観察出来る」「誰でも見られる」の威力 – キックタイミング(実行/駆動きっかけ)が豊富 – Java/Mavenがデフォルト →最大限に利用しよう!
  33. 33. で、考えてみた DBサーバ と、言うのが「毎日勝手に回る」といいな! ①①ソースの追加を監視ソースの追加を監視 自身自身JobJobに反映するに反映する ②②最新の最新のDDLDDLを取得を取得 テストスキーマ構築テストスキーマ構築 ③③最新プログラム最新プログラム ソースを取得ソースを取得 ④④プログラムソースをプログラムソースを 「テスト用」に最適化「テスト用」に最適化 ⑤⑤最新モジュール群最新モジュール群 を取得しビルドを取得しビルド ⑥⑥テスト実行!テスト実行! ⑦⑦テストの結果をテストの結果を 関係者にメールで報告関係者にメールで報告 Lan内独自 リポジトリ テスト スキーマ
  34. 34. テスト スキーマ 足りないものは? DBサーバ ①①ソースの追加を監視ソースの追加を監視 自身自身JobJobに反映するに反映する ②②最新の最新のDDLDDLを取得を取得 テストスキーマ構築テストスキーマ構築 ④④プログラムソースをプログラムソースを 「テスト用」に最適化「テスト用」に最適化 ⑤⑤最新モジュール群最新モジュール群 を取得しビルドを取得しビルド ⑥⑥テスト実行!テスト実行! ⑦⑦テストの結果をテストの結果を 関係者にメールで報告関係者にメールで報告 ③③最新プログラム最新プログラム ソースを取得ソースを取得 Lan内独自 リポジトリ
  35. 35. 今回のメインは、ここのお話
  36. 36. 第04回 大阪Jenkins勉強会 「Jenkinsと ソース管理システム(SCM) とを連携させる道具」 -SCM to CI synchronizer- を作る
  37. 37. やりたいことは • ソース管理システム(SVN)のディレクトリを調べる • Javaプロジェクトが増加すれば、 Jenkins側に「お手本Job」を一部変更したJobを追加
  38. 38. やりたいことは • 一日一度、一斉に流したい – Jenkins中に「キッカーJob」を設けておいて、 「ビルド後の処理-他のプロジェクトのビルド」 に結び付ける
  39. 39. どうしたら出来る? • SVN側 – 「検知するジョブ」の起動都度 「そのディレクトリのリビジョン番号」の最新 を覚えておく – 前回と今回のリビジョン番号の間で 「追加されたディレクトリ」の名前を割り出す • Jenkins側 – SVN側のディレクトリ名=JenkinsのJob名 – 「お手本Job(テンプレート)」から 「Jobごとに変わる部分」だけ書き変えたものを登録 • 「Job名」や「ソースのSVN-URL」など
  40. 40. 問題は… • SVN側 – SVNには 「リビジョン指定でディレクトリを一覧する」 コマンドが在る • コマンド“svn list -r [リビジョンNo] “等 – SVNには 「各プログラミング言語から操作できるライブラリ」 が多くある ○大丈夫だ、問題無い • Jenkins側 – 「外部からJobを増殖」ってどうするのだろう… ×大丈夫じゃない、問題だ!
  41. 41. おでぷろぐらむとかあんまでけへんので • Jenkinsの動きを外側から眺めてみよう! –JenkinsはJob追加の際、 処理時間は僅か数ミリ秒にすぎない –では、その「Job追加プロセス」をもう一度 見てみよう!
  42. 42. Jenkinsの内部(超絶ざっくり) • プログラムやリソース – War とそれが展開された ディレクトリ • データに属するもの – $JENKINS_HOME で 与えられたディレクトリ
  43. 43. JenkinsにJobを追加した場合 • $JENKINS_HOME/jobs/ にディレクトリが追加され、 config.xml ファイルが出来る
  44. 44. JenkinsにJobを変更した場合 • $JENKINS_HOME/jobs/[Job名]/config.xml ファイルが変更される • Jenkinsのデータ周りの設計はかなり素直 – 画面と設定ファイルは「ほぼ写像」 – ディレクトリ構成も推測を越えない • Jobは手動で追加・更新して、再起動しても認識した – Jenkins側は「ディレクトリとファイルがあれば」しか見ていない – 最悪「スケジューラで日に一度再起動」しとけば良い • 「最低限の手段」確保、これで勝つる!
  45. 45. もう少しインテリジェンスな方法を • 前述の方法では 「Jenkinsサーバ内部から」 しか操作できない • 外部から操作できないか?
  46. 46. どっちが良いだろうか 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 [サーバ] [コマンド] →こっちのほうが楽そう♪
  47. 47. CLIを使うとしても • 普通にやると… 自作Java Program Jenkins-cli.jar コマンドライン Java -jar jenkins-cli.jar ... コマンドキック! ※多分Runtime.exec() とか… 通信! 自PC ネットワーク – なんかヤダ!(そこはかとなく原始人っぽい) • うわっ、Javaを使って「jarをコンソールから実行」って 、私のPGレベル低過ぎ…? • これならどうか 自作JavaProgram Jenkins-cli.jar 自PC ネットワーク 通信! – ボク満足! – 「コマンド」と「CLIのJava内部Interface」ってどちらが… • 仕様変更の可能性、中の人はこの使い方望んで無さそう… コマンド動作を エミュレート 以前の「ソース読んだ」 と言ったのはココとココ
  48. 48. CLIを使って「Jobを追加する」 • コマンドでJenkinsに 「Job1つ分のファイル」を送りつける – “cat config.xml | java -jar jenkins-cli.jar create-job [ジョブ名]” • 標準入力からなので、自力でリダイレクト を、自作プログラム(java)でエミュレート
  49. 49. CLIを使って「Jobを更新する」 1.コマンドでJenkinsの「Job1つ分のファイル」を取得する – “java -jar jenkins-cli.jar get-job [ジョブ名] > config.xml” – 標準出力から出すので、自力で保存 2.取得した「Job1つ分のファイル」の一部を変更 – 今回は「他のプロジェクトのビルド」 -「ビルドするプロジェクト」の末尾に文字列を加える 3.コマンドでJenkinsに 「Job1つ分のファイル」を送りつける – “cat config.xml | java -jar jenkins-cli.jar update-job [ジョブ名]” • 標準入力からなので、自力でリダイレクト を、自作プログラム(java)でエミュレート
  50. 50. やることは決まった!実装方法は? • 「Maven Plugin」で! – 予想されるツッコミ「Jenkins Pluginちゃうんかい!」 • 理由 – その時の「マイブーム」 • 興味在り探求中 & 手に馴染んでた – 「コマンドラインキックのツール土台」としての 「必要と思われる装備」を備える • 設定ファイル、引数、Log、etc + Javaの資産 • Mavenの「依存性解決」はデフォルト装備 – 他端末のコマンドラインでもJenkinsのJobでも蹴れる • 「Mavenインストールされてれば」どの端末からでも • Jenkinsは親和性高、pom.xmlさえあればOK
  51. 51. maven-pluginについて知りたい方は… • 続きはWebで! http://www.slideshare.net/guestd4898b/maven2
  52. 52. するまでもない「なんちゃって設計」
  53. 53. 実装 ※絵面はイメージです。
  54. 54. なんだかんだあって… できました! https://github.com/kazuhito-m/maven-scm2cisync-plugin ※業務で使用したものではありません。すべてリライトしています。
  55. 55. 「やりましたやりました詐欺」がひどいので デモしまーす
  56. 56. デモします ● デモ環境での 特殊事情 KVMは、 Linuxカーネルに搭載された "仮想OSスーパーバイザ”です (VMWare等と同じ) 全ては、 この発表用ノートの中で 起きている出来事。 • 前提 Lan内独自 リポジトリ ・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 2012年版
  57. 57. デモします ● デモ環境での 特殊事情 Dockerは、 Linux上で動く "LinuxOSコンテナ実行機構”です 全ては、 この発表用ノートの中で 起きている出来事。 • 前提 Lan内独自 リポジトリ ・SVNは、 Javaプロジェクトが 多く登録された状態 シンク用SVNサーバ 172.17.0.2 主役のJenkinsサーバ この発表用ノートPC ・初期状態は 「ほぼピュア」 ・サーバ内のJavaは Docker任せ (OpenJDK8) ・maven-pluginの "scm2cisync-plugin”は、 都度ビルドして、 ローカルのmavenリポジトリ にインストール。 ・scm2cisync-pluginを 動かす用設定ファイル群は、 SVNサーバに登録済み。 有線 LAN ・Jenkins内のJavaは デフォルト (OpenJDK8) 172.17.0.3 コンテナ=jenkins:1.651.3 (公式のコンテナ1系最新版) コンテナ= mamohr/subversion-edge:latest (GUIも備えたSVNサーバのプロダクト “edge”の最新版) 2016年版
  58. 58. デモします • お品書き 1.DockerによるJenkinsインストール 2.SVNサーバからプロジェクト一つJenkinsに登録 お手本プロジェクト、模範的な設定に 3.「全ジョブキッカー」のようなジョブを登録 4.1つめジョブから config.xml を抽出してテンプ レート化、「変化してほしいところ」に変数記述 5.SVNに「テンプレート」「sync用設定」をコミット 6.scm2cisync-plugin蹴るジョブをJenkinsに登録 7.scm2cisync-pluginを実行 JenkinsにJobが増えていたら成功! 8.SVN上にプロジェクト1つを追加 9.Jenkinsで自動検知、自動ジョブ増殖 2016年版
  59. 59. これに • さらにプラスして – DBスキーマをリフレッシュしてくれる仕組み – 実行前にテスト対象プロジェクト最適化の仕組み
  60. 60. テスト スキーマ 完成!三代目!! DBサーバ ①①ソースの追加を監視ソースの追加を監視 自身自身JobJobに反映するに反映する ②②最新の最新のDDLDDLを取得を取得 テストスキーマ構築テストスキーマ構築 ④④プログラムソースをプログラムソースを 「テスト用」に最適化「テスト用」に最適化 ⑤⑤最新モジュール群最新モジュール群 を取得しビルドを取得しビルド ⑥⑥テスト実行!テスト実行! ⑥⑥テストの結果をテストの結果を 関係者にメールで報告関係者にメールで報告 ③③最新プログラム最新プログラム ソースを取得ソースを取得 Lan内独自 リポジトリ 「自ら肥え太る」「自ら肥え太る」 執事さん完成!執事さん完成!
  61. 61. 使い出は? • 使い方として想定できるもの –新規大規模案件での「日々全回帰テスト」 • 今回の例です • 序盤時点でプロセスに組込んでしまえば –お客様企業にて既存Javaプログラム資産がある 場合の自動回帰テスト • 「自動テスト実装済み」は必須 –中小企業の 「社内プロジェクトの全量回帰テスト」 • これも「自動テスト実装済み」は必須 • 自社でやってみる予定 2012年版
  62. 62. これを言うとかないと… やってみて…
  63. 63. やってみて解ったこと • 「1OS:1Jenkinsサーバ」が扱い易い – 今回の事情として • 「ジョブ大量増殖」することから「中央集権&クラスタ」より「根 元から別ける」でJenkinsを複数たてた方が管理しやすかった – 約100個のJob越えると、なぜか「起動」が2次曲線的に遅く – サブシステム別に何台か立てるがベター – Linux使ってリポジトリ足して自動or手動更新 • 起動・停止とインストールとアップデートの管理をOS側に任せる – 試行錯誤をした結果…(次ページ) • JenkinsとOS仮想化は相性が良い – 「良い」観点は「扱易さ」「簡単さ」「デリバる早さ」 – 試行錯誤が続くこと、水平展開を考慮すると有用 – Jenkins+必要な装備「デフォルトイメージ」用意、必要時に増殖 • CloudBeesさんがお手本&素晴らしいというステマ 2012年版
  64. 64. 余談-いくつかの運用と試行錯誤 • こんなのを試してみました 1台:1Jenkinsで、大量生産(仮想OS増殖) 1台に、tomcatを載せ、 Jenkinsを複数インスタンス 運用 1台に、1Jenkinsで、 Jobを多量に登録し、 タブを使って カテゴライズ管理 2012年版
  65. 65. 困っていること • 技術面 – 並列実行が出来ない(Executer複数化orクラスタ化) • Jenkinsサーバ1台=1つexecutorでしか動かせない • テスト用DBの都合「executorごとに接続先変える」出来れば… – テスト実行の終わらないプロジェクトがある – OS依存・端末依存・環境依存がしつこく駆逐出来ない – SCMのbranchへの対応 • 「本線より先行」が多くHotSpotが多く必要 • 「branch生存期間」的なのが解らない • 運用・プロセス面 – 観測者が居ないと意味ない – 観測者に「促す!」手段が必要 • 管理者メールを送るも不十分 • 「テストコケ始めた」「治った」等「変化」を「まとめて伝 達」な手段 2012年版
  66. 66. 困っていること • 技術面 – 並列実行が出来ない(Executer複数化orクラスタ化) • Jenkinsサーバ1台=1つexecutorでしか動かせない • DB仕込んだDockerを「クラスタ」として都度作成、動かす – テスト実行の終わらないプロジェクトがある – OS依存・端末依存・環境依存がしつこく駆逐出来ない – SCMのbranchへの対応 • 「本線より先行」が多くHotSpotが多く必要 • 「branch生存期間」的なのが解らない • 運用・プロセス面 – 観測者が居ないと意味ない – 観測者に「促す!」手段が必要 • 管理者メールを送るも不十分 • XFDで死ぬと「音」と「ひかり」で伝える 2016年版
  67. 67. 今後やるorやりたいな • お仕事 – 3,000プロジェクトへの全展開 • 600ごと、あるいはもう少し少ない単位での展開 – 全体成績収集&蓄積&分析&「促す」機構作成 – 平行化(クラスタ or Executor毎のDB振り分け化) • 個人的 – Jenkins Plugin 化!(普通そうでしょう…) • そもそも「CIサーバ」は世にあまり無い • 導入の敷居がある限り「便利」じゃない – 他SCM対応 • gitに「PJで横並ディレクトリ」有るか解りませんが 2012年版
  68. 68. 伝えたいこと • Jenkinsなんだし… – 「自動化の寵児(老人)」なのだから 「Jenkinsのメンテナンス」も自動化しなきゃ♪ • これは流行る! • よく考えれば「あたりまえ」ですよね • クラスタ化以外で 「管理用のJenkinsから他Jenkinsを弄らせる」 という考え方も… – すでにみんなやっている? 2012年版
  69. 69. と、 ここまでが 2012年の ハナシ
  70. 70. 2016年、 4年の月日は 世の中を どう進めた のか…
  71. 71. まず、Jenkinsプラグインのハナシ 三浦が maven-scm2cisync-plugin でやろうとしたこと 世界 が 開発 Jenkins Plugin群 Template Plugin(商用・非公開) Jobcopy Builder plugin Job DSL Plugin(+Script) Etc... 2016年版
  72. 72. まず、Jenkinsプラグインのハナシ 三浦が maven-scm2cisync-plugin でやろうとしたこと 世界 が 開発 Jenkins Plugin群 Template Plugin(商用・非公開) Jobcopy Builder plugin Job DSL Plugin(+Script) Etc... Jenkins側、 かつPlugin で 実現されていた!
  73. 73. さらに、
  74. 74. 祝!リリース 2016年、Jenkins2.0
  75. 75. 特徴的な進化として… 「As Code」 と「ジョブ内容の外部化」 Jenkins2.0従来のJenkins Jobの定義情報 Jenkins ソース管理 リポジトリ ソース(Project) ソースを取得 ソースの在り処(のみ) Jenkins2.0 ソース管理 リポジトリ ソース(Project) ソースを取得 コード化された Jobの定義情報 (Jenkinsfile) 2016年版
  76. 76. さらにさらに、
  77. 77. 俺の「やりたかった」ことが… 「GitHub Organization」というジョブ種が公式標準で追加 Jenkins2.0 GitHub Organization “A” ソースリポジトリ”01” Jobの定義情報(Jenkinsfile) ソースリポジトリ”02” Jobの定義情報(Jenkinsfile) ソースリポジトリ”03” Jobの定義情報(Jenkinsfile) 「GitHub Organization」ジョブ (Jenkins上はフォルダ) Organizationを指定し ジョブ定義 ビルドジョブ ”01” リポジトリの作成を 検知し、ジョブ生成 ビルドジョブ ”02” ビルドジョブ ”03” 2016年版
  78. 78. 俺の「やりたかった」ことが… 「GitHub Organization」というジョブ種が公式標準で追加 Jenkins2.0 GitHub Organization “A” ソースリポジトリ”01” Jobの定義情報(Jenkinsfile) ソースリポジトリ”02” Jobの定義情報(Jenkinsfile) ソースリポジトリ”03” Jobの定義情報(Jenkinsfile) 「GitHub Organization」ジョブ (Jenkins上はフォルダ) Organizationを指定し ジョブ定義 ビルドジョブ ”01” リポジトリの作成を 検知し、ジョブ生成 ビルドジョブ ”02” ビルドジョブ ”03” GitHub Organization より洗練 かつ 簡易に実現!
  79. 79. 時間…足りるかな? デモしまーす 2016年版
  80. 80. デモします • お品書き 1.Jenkins2.0をDockerでインストール 2.Githubに”Organizetion”を作成、 2つくらいリポジトリ作成、Javaプログラム登録 3.Jenkins上に”Github Organizetion”ジョブを作成 対を成すジョブが生成・テスト実行されるのを確認 4.先に作成したGithub上Organizetionに ソースリポジトリもう1つ追加 5.自動検知されジョブ作成、 テストが実行されることを確認 2016年版
  81. 81. 「組織」をマネージしてCIする リポジトリ→ブランチ→Jenkinsfile という構成なら… GitHub Organization = (日本語で)組織 ソースリポジトリ master ブランチ 2016年版 Jenkinsfile “何か” ブランチ Jenkinsfile ソースリポジトリ Jenkins2.0 登録すると… 自動検知 増殖&CI実行
  82. 82. 「組織」をマネージしてCIする リポジトリ→ブランチ→Jenkinsfile という構成なら… GitHub Organization = (日本語で)組織 ソースリポジトリ master ブランチ 2016年版 Jenkinsfile “何か” ブランチ Jenkinsfile ソースリポジトリ Jenkins2.0 登録すると… 自動検知 増殖&CI実行 「とある形」で モノ作りしていけば 「組織レベル」で CIをプロデュース してくれる!
  83. 83. やってみて • 以前作った「全回帰テスト実行環境」みたいにするには – 「Github Organizationの全ジョブを蹴る」というジョブ を追加 • PipelineScriptが使えるので自作できるか? • 要望 – 他「githubクローン」対応のよく似た機能が欲しい • 「Githubを採用可能」な現場は「Jenkins以外のCIを 使える」と推測する –逆に「Jenkinsを採用する」現場は「外のサービス が使えない」制約である事が多いのでは? »で「ソース管理はLan内限定」となりがち • Gitlab,gitbacket,etc… –上記2例とも”Organization”と類似の概念 “group”があるので、ムリがない感じで対応して いただければ…2016年版
  84. 84. で、 言いたいことは…
  85. 85. 以上 みんな! Jenkins2.0 使っていきましょう!
  86. 86. 参考文献/参考URL • MavenPlugin入門 – http://www.slideshare.net/guestd4898b/maven2 • Jenkins Remote access API – https://wiki.jenkins-ci.org/display/JA/Remote+acc ess+API • Jenkins-CLI – https://wiki.jenkins-ci.org/display/JA/Jenkins+CL I

×