「Jenkins ユーザ・カンファレンス 2012 東京 #juc2012」に参加してきた

発表者、運営スタッフ、法政大学関係者のみなさんに感謝の1日でした。

案内

Jenkins ユーザ・カンファレンス 2012 東京
 Jenkins ユーザ・カンファレンス 2012 東京 connpass

開催時時点で1016人の申し込み者数。

同時参照人数は、50人のようなので、Google Docsにアイコン載せる方式ではできない。
ということで、sekicoco使ってみた。

Jenkins ユーザ・カンファレンス 2012 東京 satta-1 : Jenkinsプロジェクト現状報告とこれから (基調講演) #juc2012 #juc2012_sattaのザセキ

大失敗〜
これの弱点は、その人にセキココ(チェックイン)してもらわないとだめなこと。
Googled Docsなら、知り合いなら配置できるのだが・・・
スクリーンにTweetが流れてたから、もう少しノッてくれるかなとも思ったけど。

Togetterセッション一覧

togetter隊長[twitter:@shinyaa31] 隊員[twitter:@kimukou2628] と僕で、togetterに
拾ってみました。
#juc2012_satta、#juc2012_S505、#juc2012_S406 は僕らがつけた、非公式ハッシュタグだったのですが
運営の方、発表者に気づいかいにより、スライドや開場ごとでも告知してもらえた。
ありがとうございます。

時間＼会場	さったホール (870名)	S505 (210名)	S406 (210名)
11:30-12:20	Jenkinsプロジェクト現状報告とこれから	-	-
12:30-13:20	Jenkinsによる自動受け入れテストから継続的デリバリーまで	Jenkins.rb で始める Ruby で Jenkins プラグイン作成	SIerのJenkins事情〜CI実践プロジェクト事例から超大規模プロジェクトの活用事例まで〜
13:30-14:20	飛行機を飛ばしながら直す方法教えます： JenkinsとGerritによる継続的デプロイメントの実践	開発以外でのJenkins活用方法	愛されるJenkins氏になるために
14:30-15:20	複雑な多段階ビルドに対処する: 事例紹介	Jenkins に XFD を追加してみると？	マルチステージ型継続的インテグレーションのすすめ
15:30-16:20	毎日が憧れの新築、反復可能なデリバリーによる常時新築システム	AWSで実現するSeleniumテスト高速術	開発者とディレクターの視点を変えていく方法
16:30-17:20	LT大会	-	-

どれに参加しようか迷うものばかりだ。

参加セッション

以下のセッションに参戦しました。

satta-1 : Jenkinsプロジェクト現状報告とこれから (基調講演)
satta-2 : Jenkinsによる自動受け入れテストから継続的デリバリーまで
S505-3 : 開発以外でのJenkins活用方法
S406-4 : マルチステージ型継続的インテグレーションのすすめ
satta-5 : 毎日が憧れの新築、反復可能なデリバリーによる常時新築システム
satta-6 : LT大会

satta-1 : Jenkinsプロジェクト現状報告とこれから (基調講演)

Jenkins user conference 東京 from Kohsuke Kawaguchi

Jenkins本体自体や500を越えるプラグインで、何ができるという点から、快適に使えるという点の改善に進んでいる。
執事さんがより人に優しく導いてくれるように進んでいるという印象

UIの改善、リンクをクリックするだけで目指す画面にたどり着けるようにしている
設定を微調整をしながら、ビルドをしやすいように、保存しても画面遷移をしないようにしている
目指すプラグインを探しやすくするためのフィルーター機能

執事さんがお世話する相手も拡大中。

C++のクロスコンパイル対応、プラットフォーム間で違うディレクトリに出力したりできるように。
背景いろいろなユーザーがJenkinsを部品として自動化しようとしている。それをやりやすいように REST API、コマンドラインクライアントの改善
Javaのクライアント以外にも汎用的にsshクライアントも用意

プラグイン開発にRubyの人などが入ることによって、異なる文化、考えの人達が増えることで、いい案はどんどんと入れられてる。

Rubyの人はコンソールに色がでるのが好きなので、ANSIカラーコード機能対応
Rubyによるプラグイン開発、Rubyの開発者は、Javaでコードを書いてることがバレるとまずいので、Rubyによる開発機構を作った
プラグイン開発者向けの改善今のHTML生成は評判が悪いのでGroovyによって生成するように。メリット：デバッガが使える、IDEによるコード補完

人はミスするもの、手を抜くものという前提で、どうしたら楽にやるべきことをできるかということが考えられてるな。

Build Hive：GitHubにあるものをJenkinsで簡単にビルドできるようにする
やりたかったもう1つのこと、Pull Requestをビルド、テストすること
プロジェクトの中の人も git push jenkins master でJenkins(Build Hive)に変更を送る。うっかり間違いの防止。先にテストをしてから、うまくいったらJenkinsがコミットしてくれる

コミュニティの維持、発展、は不可欠。

Jenkins CIA
- タモさんJenkisn登場
- Jenkinsの発表すると、ステッカーとTシャツを貰える。発表した場所はピンを立てて、世界制覇
プロジェクト憲章の制定
- 不文律の明文化、どういったライブラリは使用していいのか、GPLはダメとか。企業でお金もらって働いてるコミッターのためにも明確化
- 某O社とのこともあったので・・・
企業向け
- 通常は毎週月曜日にリリースされている。毎週アップデートする人はいないでしょうが、企業が導入しやすいよう長期サポートリリース版を用意
- 3ヶ月ごとに優良リリースを選択する
サーバの管理のOSS化。puppetの導入
- サーバの管理もプログラム化することで、誰でも見られるように。これによりPull Request経由で誰でも変更、提案可能に。
プラグイン開発者がより開発しやすいように
- Ruby開発者がスケルトン自動生成などコマンドラインで開発する機能について有効性を示してくれた。それを今度はJavaの方へフィードバック

大規模環境、複雑なワークフローも使えるように目指すのと、同時に、もう一方で、もっと簡単にと。
頼れる執事さんが更に頼もしくなるな。
(勤務先で言われたら、「二兎追うものは一兎をも得ずになるだろう！」「言うだけなら簡単だ！」と言いたくなるような
ことなんだけどね。)

Jenkinsがハマる(適用できる)ところの拡大
- より大規模環境への導入。例えば、マスター同士の連携。複雑なワークフローエンジンをJenkinsへの取り入れ。DSLでワークフローを書けるように。
もっと簡単に
- AntのBuildだったら、Antでビルド。
  - ダックタイピングならぬ、ダックビルドってことか！？
初期状態がSubversion、CVSだけはやめたい。
便利なプラグインをおすすめ機能
- このプラグインを入れてる人は、このプラグインも。ビッグデータと言ってる人が多いので、乗り遅れないようにw
自分があまり作業をしなくても、仕事が進むように。テスト実行の並列化。それらを支える優れた可視化

日本だと、計算機を大量に動かすというと、今は電力の問題があって寂しい感じに

電力だけではなく、計算機を確保するのも難し場合もある。
自分の勤務先だと、PC、サーバはなかなか新しいものを用意できない。
古いものは統合して整理しろ、サーバ借用を大量に、長期間してると減らせー減らせーと。
縦割りで、PCの経費を減らすミッションの人、サーバの経費を減らすのがミッションの人が生まれてるんかな。
計算機でできることをわざわざ人間がやることを推進されてる気がしてならない。。。

はじめの一歩にはちょっとした勇気が必要。

チケットは、日本語でも構わないので、どんどん送ってほしい
(質問がないので)景品が必要なんですかね

satta-2 : Jenkinsによる自動受け入れテストから継続的デリバリーまで

Continuous Integration, Continuous Quality, Continuous Delivery from Wakaleo Consulting

リアルタイム妙訳

“Continuous Integration Continuous Quality Continuous Delivery”
John Smart (@wakaleo)
8888888888888888888
コンニチハ
わたしはシャチョースマートジョンです
Jenkins Definive Guideの著者です
I’ll speak in English.
John Smartといい、コンサルティングの会社で
継続ビルド、自動テスト、自動受け入れテスト、自動リグレッションテストなどをやっています。
クリーンコードのベスプラクティスの提供とか。
だからJenkinsは私にとって非常に重要です。
今日は継続デリバリについて話したいと思います。
また自動テスト、自動受け入れテストなどについても。
継続デリバリとは自動化してビジネスの必要なタイミングでプロダクトを出荷することです。
製品がデプロイ可能かどうか判断できなければもちろん製品は出荷できません。
継続デリバリの重要な点は、・・・手動でテストをするのはもちろん時間がかかるし

手動テストは手軽似始められますが効率に問題があります。
もちろん自動化することが重要(すいませんネットワークとらぶるが・・)

典型的なアジャイルプロジェクトではハイレベルなビジネスゴールがあり、いろいろな要求があり、必要とされる機能が設定されています。
そしてストーリー、シナリオなども定義しておきます。

何をもってして受け入れ可能なのか定義しておくことがっじゅうようです。
書かれている情報も重要ですが口述される情報も非常に重要です。

最初の段階ではなにを実現しようとしているのかを
定義します。
そして、次の段階ではビジネスゴールとして何を達成・実装していくのかを定義します。
そしてビジネスに貢献（利益をあげるとか）するために何が必要なのかまで分解していきます。

製品がビジネスにvalueを提供しないという可能性もあります。

..(すいません、ちょとおっついてない）

コードをかくうえで、ナンのためにそのコードが必要であるか知っていなければコードを書くのは適切ではありません。
そのコードで実現するストーリー、リクワイアメントを理解しておくことが重要です。
全てのストーリーはビジネスに価値をもたらすもの（単位）でなければいけません。

たとえばcucumberではユーザーのストーリーに従ったテストシナリオをかくことになりますね。

それを通すコードを書けば自然とユーザーのストーリーを実現するプロダクトができあがることになります。

自動受け入れテストをするうえでOSSの製品”thucydides?”をつかっています。

たとえばキーワードで検索できるという機能が欲しいというストーリーあるとします。

(機器調整中・・・)
シナリオを実装し、それによりビジネスゴールを実現する
そしてそのシナリオを実装するまでの課程(コーディングではなくてユニットテストから受け入れテストまで）を自動化することが重要（とかとか）

そこで、Jenkinsをいかに活用するか。
もちろんコンパイルやテスト、品質管理、リリース候補の選定、レポートやドキュメントの生成などをします。
ローカルのマシンで受け入れテストを実行し続けたくはありませんね。
顧客によっては受け入れテストをjarファイルにパッケージしています。jarファイルをダウンロードして実行すればレポートが自動生成されます。なので出荷可能なクオリティに達していることに(簡単に）自信が持てます。
こういった要素が継続デリバリを構成します。
継続ビルドは特定のバージョンのソフトをとりだし、テスト、受け入れ検査などをし、そしてプロダクション環境へデプロイ（必要なタイミングで）します。

企業・組織によっては継続デプロイ（デプロイまで自動化）をしているところもありますが、エンタープライズの環境では継続デリバリ（デプロイてまえ）まで自動化するのが望ましいことが多いです。

この図では簡単なビルドパイプライン（流れ）を説明します。

テストにはビルドをして早くできるテストと、やや遅いテストがあります。
早いテストのセットを定義しておけばフィードバックを早く得ることができます。
早いテストも遅いテストもそれぞ(Jenkinsの)ジョブとして動かします。
その後、受け入れテストを実行し、コードのメトリクスを算出します。
これらが通るとリリース可能なバイナリのセットができあがります。
リリース可能なバイナリをできる限り早く作り上げることが重要です。
受け入れテストはその前段階のテストと同じように見えますが・・・、（おっと、追いつかなかった）

リリース候補ができあがればステージング環境にデプロイします。

皆さんはemailアプリケーションになじみ深いと思います。
色々な人に色々なトリガでemailで通知する性質のものです。
Jenkins的にはとにかく素早く実行し、フィードバックを素早く得ることが重要。
テストを早い段階で実行、メトリックス測定

ビルドを実行して結果を得るのに48時間とかかかっていたらそれまでのあいだチームメンバーは待たされてしまい、非効率。
ユニットテスト、受け入れテストについても同じです。
たとえばhtml publisher pluginがあります。
プラグインはとにかくたくさんあり、結果を通知してメンバー全員に周知を徹底させることができます。
コードのクオリティは重要。
Sonarはコードメトリクスをはかる良いツールです。
Jenkinsでプロダクトをproactive(積極的、前もって)悪い部分を検出することができます。
自分で事前にルールを設定しておき、その閾値を超えたらビルドを失敗とマークさせることができます。
たとえばコードのカバレッジは80%以上でなければいけないと設定したりできます。

これはCobetura Pluginとかを使った場合です。
Jenkinsにプロジェクトのルールを(自動的に)強制させることができます。

リリースについて。
リリース対象のバイナリを極力用意に識別できるようにすることが重要です。
mavenを使っているかたは？
mavenはリリースプラグインがあり、リリース候補を作るのが非常に重要です。
ただこのプラグインは非常に遅く、操作が難解なのが難点です。(Twitter4Jで使ってるよ！)

継続デリバリではmaven リリースプラグインはイマイチなことも。

私がオススメするのはコードをチェックインして、テストを通し、スナップショットビルドを作ります。
そして受け入れテスト、コードメトリックス測定をし、リリース候補の生成まですることです。
(Mavenのリリースプラグインでは人間が決めたタイミングでリリース候補バイナリを生成する)
mavenの場合はこんなフロー(スライド)になります。
場合によっては出戻りが発生してまたテスト実行に時間がかかることがあります(リリースプラグインの実行は手動なので)

別の戦略としては mvn version:set を使うこと。
常にsnapshotビルドを作り続けるけれども、これと決めたバージョンをリリースバージョンとしてしまうようなアプローチ。
snapshotビルドではなくリリースバージョンと決めたらあとはartifactory や nexus プラグイン(maven repositoryと連携させるためのプラグイン)を使って出荷できます。
バイナリーのアーカイブ（？）には簡単に(無償で）できるアプローチが２つあります。

copy artifact を使うこと。
個人的にはartifactoryにリリースするのが好み。
もちろんデリバリだけでなくデプロイまで自動することも可能。
デプロイメントチームもオペレーションチームも、デプロイメントプロセスを共有して同じことをすれば良い。
puppetなどを使えばそれはもっとシンプルに楽になります(さっき基調講演でふれてたやつ）

最後に言いたいのはビルドプロセスを可視化、見える化したいということ。
特定のコミットがどのプロセスまで進んだのか、どこで失敗したのかなどを見える化するのが重要。
まとめ：
高品質のテスト重要 =>それによって確信を得ることができる、出荷可能であると。受け入れテストが通っており、その受け入れテストはビジネス価値をもたらすストーリーに基づいている。なのでコードはビジネス価値をもたらすことが保証されている。
ありがとうございます。
Q&Aにしましょう。「アリガトウゴザイマス」

Q. 受け入れテストはどれくらいまで自動化できるか？
: 画面のレイアウトや翻訳のクオリティなどは難しそう
A. 経験的に自動化できないテストは、ユーザーシナリオ、受け入れテストで「マニュアル」とマークしておく。が、その「マニュアル」とマークされているテストの割合は非常に少ない。マニュアルテストの結果のフィードバックを自動化することなども重要。

Q. maven、NexusをつかったJavaプロジェクトに関わっています。リリースをするにあたってversion:setを使ったり(リリースプラグインが使いにくいので)してる。それだけでは解決できない問題があって、たとえばWebサービス固有の環境依存設定をアプリケーションに閉じ込められない(JDBCURLとか)場合はどういうアプローチがいいか？
Ａ.設定を外だしするよう心がける。同じバイナリをデプロイしつつ、デプロイ環境ではそれぞれ別の設定を適用するような。

Tweetしたり、まとめたりするには、案の定英語力が足りんかった。。。

S505-3 : 開発以外でのJenkins活用方法

JUC2012 from Kiyotaka Oku

裏番組をするめる @kiy0taka さん、そしたら自分も見に行くからと。
資料ができてないから、スタッフを手伝うことはできなかった。きっと直前まで作ってたんだろうな。
JQuery plugin、MongoDB pluginを作ってる。使ってる人ノ(1人？)
この内容か、ネタ系プラグインを作る案があったが、ネタ系は却下された
開発者以外の人にJenkinsを使ってもらうために、こういうことをしたよっていう話
資料みにくくないですか？たいした資料なので(ry
drooFSのデモ中。裏でJenkinsがPDFの差分を出しているというのが今日の話。
もし使いたい人がいたら、名刺交換させてください。(2回目)
NEW CASTの事業説明
社内 30人ぐらいJenkins インスタンス4(2)、ノード8(5)、ジョブ195(59) ()はDTPが使ってるもの、ノードは開発よりも多い。
DTPと開発の共通点。人間がやらないとならいこともある。人間がやらなくてもいいこともある。
DTPと開発の異なる点パソコンに詳しくない(オカンほどではない)、シェルを渡しても・・・バージョン管理しない、自動テストしない(できない)
人間がやらなくてもいいこと、DTPは自動化されていない、やろうとすると高価なソフトが必要だったりする。そこでJenkins
DTP用のスクリプトを書く。でも、実行方法が分からない人もいる。環境が違うと動かせない。エラーがでてもなんだがわからない
でも、これって開発環境でも同じだよね。build.xmlがあってもantを知らなければ読めない。後も同じようなことあるよね。でも、このレベルの開発者だと・・・
そこでJenkins

Jenkinsの利用方法
1.標準機能とプラグインの組み合わせ
- シェルの実行。シェルスクリプトはJenkins上で書くのではなく、ファイルでバージョン管理しておく方がいい。
- ビルドのパラメータ化ビルドに必要なファイルを実行時にしてもらう。PDFをバージョン管理してないので、実効するたびにフィアル名を指定してもらう必要がある。 ☑ビルドのパラメータ化を使う
- バージョン管理できればいいのだが、それができなければ、パラメータで指定。ちょっと面倒だけど。
- プラグインの活用 IRC Plugin 。書籍1冊とかだと、時間がかかるので、IRCで通知。全員つながってるのでIRCで。メールを送ることもできるが、めんどくさいですね。
- Groovy Postbuild Plugin いろいろできるので使ってみるといいですよ

2.APIを使って独自
- Webアプリをフロントエンドにして、バックエンドにJenkinsを使う。 Webアプリ側では使いやすいUIの提供やJenkins側で管理しないデータを扱う。
- JenkinsだとXMLだけだけど、DBで永続化したりする。
- サーバさえあればスレーブは簡単に増やせる
- システム構成を見て、昔のEJBみたいと言ったら、画面の色がおかしくなった。
- 簡単といってもWindowsだとちょっと面倒かもしれないですが
- 夢は広がる。Jenkinsを使えばできる。今やってるわけではない。
- 川口さんがいるのですごくやりずらい・・・
- Remote API ちょっとことしたいなら、これだけでできてしまう
- CLI GroovyコマンドとJenkins内部APIを使えばもっといろいろなことができる。
- Jenkins CLIの所に説明がある。
- GroovyとJenkins 内部APIのデモ Jenkinsのバージョンを取得して、表示するGroovyで書いたもの
- Javaで書くともっとコード増えるんですけど、これはGroovyなので。Groovyスゴイですね。

3.特定の処理をプラグイン化
- プラグインはすぐに簡単に作れます。プラグイン作ったことがある人〜シーン。簡単に作れます！！
- 独自プラグインのメリットほんとどない。シェルで書いたほうが扱いやすい
- 開発用プラグインの様に万人向けではないので
- それでも僕はプラグイン書いてる(キリッ

Groovy Remote Control：Jenkinsとの連携をよりやりやすくする
- シリアライズ可能なオブジェクトなら、Remote に渡せて、Remoteから受け取れる。
- デモを見たらなんとなく分かってもらえるかな
- remote{}のクロージャーがJenkins上で実行される
- リモートとローカルの操作が1つのコードの中でできる

アプリケーションからJenkins

import groovyx.remote.client.RemoteControl
import groovyfx.remote.transport.http.HttpTransPort

def transport = new HttpTransport('http://jenkins-server/')
def remote = new RemoteControl(transport)

def result = remote {
    //ここの処理はJenkins上で実行される
    //シリアライズ可能なオブジェクトを返すことが可能
    return 'hello'
}
println resutl

デモ失敗ｗｗｗ

ニコ動ちょっととめてもらっていいですか
なかったことにしたｗ
一番の見せ場が
これ公開しても俺得でもないんですが・・・
Jenkinsからアプリケーションのコードを実行
ろくろ回し過ぎ
弊社では、DTPのバイトの人でもJenkinsは知ってます

Q.動くデモはどこでみられますか？

プレゼン資料の順番を見て、本人も驚いてたり、
プロジェクトの表示で色がおかしくなろうとも、
デモに失敗しようとも
何があっても動じない @kiy0taka さん

確かに何があっても慌てることはなさそうだ。
今回のプレゼンの見所はそこかな。
僕には真似できないな。。。

S406-4 : マルチステージ型継続的インテグレーションのすすめ

1.CIのメリット
- メリット手戻りのさあ削減、品質の維持。最後に結合するのではなく、変更を起点にビルド。
- いつでもリリース可能。なビルドを持つことができる。
- いつでもリリース可能なビルドを持つことができる。
- 作業コストの削減知的な作業に注力
- 作業の正確さ、曖昧さの排除
- 開発データの蓄積

2.メリットを享受できていますか？
- Aチーム：実装→テスト→結合
- Bチーム：実装テスト→レビュー →結合
- チームC：受け入れテスト→結合→テスト→結合
- 例チームA の結合レベルに達していないソースが構成管理に格納されている。その調査に無駄な工数が発生する
3.マルチステージ型CI
- 改善策次の視点で見直すことが必要。
- チーム、モジュール構成がどうなっているか
- 開発プロセスが現状どうなっているのか
- どのような開発プロセスも段階的に成熟していく。同じようにCIも段階的に構成されていくべき
- ビルドパイプラインなども、段階的に、ある程度区切った形にというのは似ている。
- プライベート、チームビルド、結合ビルドと多段階の構成をとる
- ビルドエラーの影響度が小さくする、にチームビルドで検出

4.デモムービーによる説明
- デモ環境：4チーム実装 → レビュー → QAテスト → リリースをAccuRevで表現したもの

Q. デモ環境を最小構成でそろえたらどれくらいか？ PC、車、外車など表現はいろいろありますが
A. 構成など様々で要相談だが、車にはならない。軽ぐらい

satta-5 : 毎日が憧れの新築、反復可能なデリバリーによる常時新築システム

https://skydrive.live.com/view.aspx?resid=968A39D3BD051DA!460&cid=0968a39d3bd051da&app=PowerPoint

1.背景見慣れているもの。
- 0X-サーバXXX.xlsx
- 変更があっても更新されない
- cleanの既存プラクティス失敗しやすい:make all 、失敗しにくい：make clean all
- かわいいキャラクター(るびーちゃん？)大好き
- 宣伝：Paas1.0 Sourcefogeのクローン→Hudson→自動デプロイ。アプライアンス製品なのでこんなサーバを買えば使えます。いくらなんですかね。値段確認するの忘れました。
- 1年前のデプロイの状況手順書による手動デプロイ、複数クラウドへデプロイ(複数バージョンの手順書、なければ開発者の想像で)、常時結合しておらず
- こうなるとデプロイが面倒なので、差分デプロイに、新規顧客をとりにイカなくなる
- 自動デプロイいいよと言ってるのに、自分たちが使えてない。Jenkinsを使おう
2.まずは愚直に自動化
- 手順書→Chef Solo。RubyのDSLで記述が簡単。Chef Soloなのでサーバも不要。
- パッケージの集約。マトリックスジョブ。ms-gcc5632、ms-gcc5764・・・MSはプロジェクト名、MS社とは関係ない。RHEL5.6 32bit、RHEL5.7 x64 でビルドする
- Parameterrized Trigger Plugin：ビルド後にパッケージ集約ジョブを呼び出す
- Java(Jenkinsのため)、Git(Jenkinsがリポジトリから取り出すため)、Ruby(Chef-soloのため)、Chef-soloをインストールしたテンプレートVMを用意した
- GitoriousというGithubクローンを使用している。
3. "スローデプロイ問題"
- デプロイに60分かかる。似たような問題にスローテスト問題。スローテスト問題は、テストケースを分割するのが1つの一般的な解
- デプロイは、並列実化できない。純粋に実行を早くすることが必要。
- 1.VMスナップショット：VMをテンプレートから作る代わりにスナップショットへの復元。10分から3分へ。
- 電源をいきなりブチッとしてしまうとJenkinsがマスターとスレーブが混乱する場合があるので、シャットダウンしている。
- インターネットからの分離：rpmやgemのダウンロードしてたので遅い。事前にまとめておく。ここでも、Matrix job Pluginが活躍。
- Jenkins自体をyumのリポジトリに。
- 外部影響の原因追求、Jenkinsには、ファイルのMD値を持つ機能があるので、いつからJenkinsにあるかを確認することができる。
- インターネット環境がないようなところにデプロイできる
- 冪等性 f(f(x)=f(x) 今回の場合は、xマシンの状態、fはデプロイをした後のマシンの状態。複数回デプロイを実行しても1回実行した状態と同じことを示している。
- 冪等の読み方「べきとう」
- 自前と既成の性質がことなるので、デプロイスクリプトを分割
- 冪等ではない例 tar zxf foo.tar.gz、冪等の例 rm -rf foo;tar zxf foo.tar.gz
- チームの変化
- 早い失敗を目指す。パイプラインの早い段階(結合テストよりも前に単体テストで)で赤や黄色になる
- 設定ファイルを作るアプリを作る。Chef→bash→Java。この場合は、Javaアプリでパラメータチェックができるので、失敗することができる。
- ブランチごとにデプロイ。ブランチに新機能をいれるときでも開発者が勇気をもって作ることができる
- 自動化できるものは自動化
- クリーンと冪等性がコツ

Q.PaaS上の環境を作るときまではわかるが、テストに工数がかかると思うがその辺りの自動化はどうしているか？
A.今回の資料からは省略してるが、やってはいる。それは、言うなといわれてるので、ごめんなさい。

PaaS環境を作成するというのもなかなか厄介なもんだな。
0X-サーバXXX.xlsx という更新されない仕様書をガリガリ書くのは・・・似てるなｗ

Chef、Chef-Soloは最近よく聞くな。どんなもんなんだろう。テスト絡みも含めてもう一度話を聞きたいな。
スローデプロイ問題のコツとして、クリーンと冪等性がでてきたが、これは自分がやりたいテスト周りでも
この辺は考えておいた方がよさそうだ。

satta-6 : LT大会

省略。

スライド

時間＼会場	さったホール (870名)	S505 (210名)	S406 (210名)
11:30-12:20	Jenkinsプロジェクト現状報告とこれから	-	-
12:30-13:20	Jenkinsによる自動受け入れテストから継続的デリバリーまで	Jenkins.rb で始める Ruby で Jenkins プラグイン作成	SIerのJenkins事情〜CI実践プロジェクト事例から超大規模プロジェクトの活用事例まで〜
13:30-14:20	飛行機を飛ばしながら直す方法教えます： JenkinsとGerritによる継続的デプロイメントの実践	開発以外でのJenkins活用方法	愛されるJenkins氏になるために
14:30-15:20	複雑な多段階ビルドに対処する: 事例紹介日本語妙訳	Jenkins に XFD を追加してみると？ Jenkins に XFD を追加してみると？原田騎郎 XFD導入体験記 @_nishigori 福岡XFD導入記高橋剛 XFDを導入してみると？川路義隆	マルチステージ型継続的インテグレーションのすすめ
15:30-16:20	毎日が憧れの新築、反復可能なデリバリーによる常時新築システム	AWSで実現するSeleniumテスト高速術	開発者とディレクターの視点を変えていく方法
16:30-17:20	LT大会書籍執筆における継続的デリバリー英語Jenkinsコミュニティの解説 Flash(ActionScript3.0)開発でもJenkinsを導入しようふつうのSIerのJenkinsのある暮らし運用でも使えるjenkins	-	-