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

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

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