Jenkinsカンファレンスに参加してきました
法政大学で行われたJenkinsカンファレンスに参加してきました。
http://connpass.com/event/467/
以下、参加してのメモになります。
何書いてるのかいまいち分からない部分もあるかもですが、とりあえず。
Jenkins カンファレンス 20120729
**********************
12:30 - 自動受け入れテストから継続デリバリーまで
html publisher plugin
結果を通してメンバ全員に周知を徹底させる
Cobetura Plugin
Jenkinsにプロジェクトのルールを自動的に強制させることができる
コードをチェックインして、テストを通し、スナップショットビルドを作ります。
そして受け入れテスト、コードメトリックス測定をして、リリース広報の生成まですること。
mavenのリリースプラグインでは人間の決めたタイミングでリリース候補バイナリを生成する
mavenのフローでは、場合によっては出戻りが発生してまたテスト実行に時間がかかることがあります
戦略としては、mvn version:set を使うこと
snapshotビルドを作り続けるけれども、これと決めたバージョンをリリースバージョンとしてしまうようなアプローチ
snapshotビルドではなくリリースバージョンと決めたあとは、artifactoryやnexusプラグイン(mavenリポジトリと連携させるためのプラグイン)を使って出力できます
ビルドプレセスを可視化、見える化したい
一定のコミットがどのプロセスまで進んだのか、どこで失敗したのかなどを見える化するのが重要
まとめ：
品質のテスト重要 => それによって確信を得ることができる。出荷可能であると。
受け入れテストが通っており、その受け入れテストはビジネス価値をもたらすストーリーに基づいている。
なのでコードはビジネス価値をもたらすことが保証されている。
----
経験的に自動化できないテストは、ユーザシナリオ、受け入れテストで「マニュアル」とマークしておくが、
その「マニュアル」とマークされているテストの割合は非常に少ない。マニュアルテストの結果のフィードバックを自動化することなども重要。
アプリケーションの中の設定(log4jとか)に依存をアプリケーションに閉じ込められない場合、どういうアプローチが良いか？
ｰ> 設定を外出しするよう心がける。同じバイナリをデプロイしつつ、デプロイ環境ではそれぞれ別の設定を運用するような。
**********************
13:30 - 開発以外でのJenkins活用方法
開発者以外の人にJenkins使ってもらう話
DTP -> 割付などの作業をコンピュータ上で行い、プリンタ出力すること
dprooFS
PDFをドラッグ＆ドロップ
PDFの差分が見える
DTPと開発の共通点
人間がやらないといけないこともあるが、人間やらなくてもいいこともある。
イテレーションする
プラグインの活用
実行結果を通知：IRC Plugin
成果物をアップロード：Publish over XXX Plugin, Groovy Postbuild Plugin(ビルド履歴にアイコン表示とか)
権限周りの設定
APIを利用する
WebアプリをフロントエンドにしてバックエンドにJenkinsを使う
Webアプリ側では使いやすいUIの提供やJenkins側で管理しないデータを扱う
Jenkinsのスレーブ機能で処理が増えても簡単にクラスタを増やすことができる
CLI(コマンドライン・インタフェース)
$ java -jar jenkins-cli.jar -s http://jenkins-server/ groovy hello.groovy
プログラムからの利用
プラグインを作る
特定の処理をプラグイン化
hudson.tasks.Builderを継承して実装
Builderの実装はたくさんあるので、他のプラグインのソースを見ればわかるはず
Groovy Remote Control
Jenkinsとの連携をよりやりやすくするためのプラグイン
**********************
14:30 - 多段階ビルド事例
たくさんのプロジェクト
gitプラグインを使ってなかったので変更の検出が難しかった
変更がないコードなども繰り返しビルドしたり、記録が残るなどしてしまった。
→ ビルドの状況が「見える化」されていなかった。問題発生した際のトラブルシューティングが非常に難しかった
今ではコンポネントごと、プラットフォームごとにジョブを分けている。
現在のパッケージはすべてのコンポーネントの最新状態が必ず反映されている。
今でもすべてのコンポーネントを週次でフルビルドしている。コンポネントの依存順に。
可能であれば、依存関係のないコンポーネント同士を並行してビルドしている
フルビルドが完了すれば新しいリポジトリが作成される
新しいプロセスで助かっているのは、これまではPythonの巨大な１スクリプトであったが、
今では個別にビルド方法を調整できる。
以前より素早くチューニングできる。コードが変更されたらそれだけを個別に自動的にビルドできる。
１つのスクリプトになっていないので、何か失敗したらそこから開始することが容易
ジョブを分けることで何が起きているのか、どこに不具合があるのか「見える化」されるのが良い
ビルドの並行化でフルビルド時間が大幅に短縮された。結果、より改善にそそぐ余裕が生まれた。
可能な限り、広く使われている実績のあるプラグインを使っている。オレオレスクリプトではなく。
ローカルビルド環境を作ってしまえばEC2よりも安い
- Parameterized Trigger Plugin
汎用のパッケージングジョブを定義することができる。
コンポーネント×プラットフォームの組み合わせごとにたくさんジョブを定義する必要がない
このプラグインのすごく便利なのは、ビルドステップを定義すれば下層のビルドが自動的に走り、それが終わるのを待ってくれる
→ そして新しいアクションをまた自動的に実行してくれる
我々はすべてのプラットフォームでテストを実行し、その実行結果をまたなければならない。
このプラグインで非常に効率化できる
- Conditional Build Step Plugin
条件によって異なるビルドステップを実行させることができる。
色々なプラグインが個別の「token」を持っており、条件によって「token」で識別されるプラグインを実行できる
parametarized trigger plugin で色々なプラットフォームのビルドをするのは楽になったが、
例えばフルビルドでなく特定のコンポーネントだけをビルドしたい場合など便利
- jclouds plguin
EC2プラグインと似ているが、あらゆるクラウドプロバイダーに対応している。EC2を使わずプライベートクラウドでテストすることも。
"node pooling"機能でビルドごとにインスタンスをあげたりすることなく、既に起動済みのインスタンスでビルドを
走らせることができ、時間をセーブできる。
- Muti-SCM plugin
jenkins git plugin は一つのjobから複数のgitリポジトリからcheck outできない
multi-SCM pluginでは一つのJenkins jobから複数のSCMを参照できる
gitのsubmoduleで別のリポジトリを参照してる場合などに便利
- Description Setter plugin
正規表現でビルドログをさらい、jobのdescriptionを設定できる。
単に失敗した、ではなくHadoopが原因で失敗、とか簡単にわかるようになる
- Associated Files plugin
ビルドページから、そのビルドに紐付くファイルがどこにあるか一覧できるようになる。
ステージング用のファイルはここにある、とか。
ビルドが削除された場合、関連するファイルを一緒に削除してくれる。
Jenkins固有の話ではないが、、
S3を使わないのでバイナリのステージング環境は自分で容易しなければいけない。
- Cloudbees Jenkins Enterplise Template plugin
jobのテンプレートを定義できる。テンプレーを変更すればそれが既にあるjobに反映される。
コンポーネントは違うが、ほぼ同じ設定のjobがたくさんある場合便利
- All Changes plugin
parameterized Trigger plugin で実行されたビルド結果(の違いのある部分)をまとめて一覧表示してくれる
- Github plugin
ビルドをポーリングベースではなく、post-service hook(git pushしたら発動する)で、Jenkinsのjobを開始できる。
Q. Jenkinsのバージョンはどこかに記録してますか？
job config history plugin が好きで、どんな変更が行われたのか、誰が変更したのか記録されます。
それと、gitのスクリプトがあって、jenkinsのconfigの履歴を管理します。ただ、そこは改善の余地があると思っています。
Q. Cloudbees templateプラグインについて便利そう。高そう・・・
川口さんに聞くべし。高くないはず。他にもCloudbeesから色々便利なのが出てます
Q. job config history plugin、jenkinsのconfigをgitで管理する場合、その保存先は？
ソースコードとは違うリポジトリに保存している。Job DSL pluginではgroovyでジョブの設定を管理できる。
それを使わなければいけなかったのは、一箇所に設定を保存しておけば良くなるので楽だから。
単純に設定を保存してgitに保存するだけでは、履歴を確認するのが難しい。
**********************
15:30 - 反復可能なデリバリーによる常時新築システム @ohtaket
手順書がExcelにあって人間が作業する。。。。のがよく見られる
→ 変更があっても更新されない
cleanの既存プラクティス
$make all -> $ make clean all (失敗しにくい)
Win 9xをN月おきにクリーンインストール
デプロイ工数がめちゃかかってた
→ さぼり
→ 既存のデプロイには差分だけ適用。新規顧客を探しに行きにくくなる。
→ Jenkinsをデプロイで使うぞ！
ExcelをChefに置き換えた(Chef Solo)。記述が簡単。セットアップが簡単。
Jenkins側で必要な事項
1. パッケージの集約
OSバージョンとビットごとにビルドサーバ容易
Matrix Jobでビルド
ビルド後にパッケージ集約ジョブを呼び出す（Parameterized Trigger Plugin）
buildジョブからアーティファクトをコピー（Copy Artifact Plugin）
2. マシンの容易
・各種Cloud Plugin
- Amazon EC2 Plugin , Delta Cloud API Plugin, jClouds Plugin , vSphere Cloud Plugin ...
任意のタイミングでのVM制御が必要
Java, Git, Ruby, Chef-soloをインストールしたテンプレートVMを用意
テンプレートからVMを作りそこにデプロイ
電源を入れるジョブの例(Windows PowerShell）
3. デプロイの実行
ノードをまたがって逐次実行するジョブ
Parameterized Trigger Plugin + NodeLabel Parameter Plugin
親ジョブと子ジョブのパラメータの定義
PaaSバックエンドシステムは複数台
Parameterized Triggerで各スレーブにデプロイ
開発環境以外の環境にも同じスクリプトでデプロイ
"スローデプロイ問題"
デプロイに60分かかる
スローテスト問題はテストケースを分割して並列実行が一つの解
4. VMスナップショット
VMをテンプレートから作る代わりにスナップショットへの復元
10分から３分に。
制約は増えるが速度のほうが重要
5. インターネットからの分離
インターネットからのrpmやgemのダウンロードが遅いので、事前にアーティファクト化
45分から2分に
外部影響の原因追求
インターネット接続がない環境へのデプロイ
6. 自前と既成の分割と冪等性
自前パッケージ - 自前のソースからbuildするパッケージ
既成パッケージ - 他者が作ったパッケージ
自前と既成で性質が異なるため、デプロイスクリプトを分割
冪等なデプロイスクリプト
[冪等でない]
$ tar zxf foo.tar.gz
[冪等]
$ rm -rf foo
$ tar zxf foo.tar.gz
7. 早い失敗を目指す
パイプラインのなるべく早い段階で黄や赤になるように（Fail fast）
設定ファイルではなく、設定ファイル作成プログラムを作成（Chefのレシピとテンプレートでconfigに失敗が起きない）
8. 環境の使い捨て
本番と同じ環境で開発
高速なデプロイと冪等なスクリプトのおかげ
9. ブランチごとのデプロイ
毎回新規に作られる環境による安心感
デプロイまで行うので試用ができる
まとめ
自動化できるものは自動化
・buildだけでなくデリバリーも自動化しましょう
・クリーンと冪等で反復可能に。
・自動化だけで終わらずに、高速化を検討すべき
・迅速なフィードバック
・速ければ使い方も変わる
・本来はCIサーバだが、CI以外もこなせる。執事を遣い倒そう
**********************
16:30 - LT大会
■ 書籍執筆で継続的デリバリー @kaorun55
SPHINX - Python Documentation Generator
JenkinsでPDF化とかを。
CloudBeesで。Javaしか動かない。Virtual Python というのがあるらしい。
■ The Jenkins English Community
英語圏のコミュニティは英語圏と西ヨーロッパが多い、アメリカ、フランス、ドイツ。
IRCでコミュニケーションが多い。あとML。jenkins-user-devも。
↑ プロジェクトMTGがIRCで行われているから。twitterは英語圏ではコミュニケーション用途としては使われにくい
■ Flash[AS3]でもJenkins @uzzu
Jenkins環境で動くの？動く。
Maven3プロジェクト
JenkinsサーバにFlashPlayerインストール
Flexmojosというmavenのプラグインを利用
コンパイルオプション、依存関係はpom.xmlに書く
Headress Serverでは追加作業。ソフトウェア入れたりPlugin追加したり。
vncserver + xvfbを利用
ジョブ開始時にjenkinsユーザでVNCサーバにリモートログイン。FlashPlayer実行
テスト実行時間遅い、64ビット環境で動作が不安定
■ ふつうのSIerのJenkinsのある暮らし @setoazusa
ビルドパイプライン
サポートしている環境の組み合わせが多少なことが特徴
Join Pluginを使ってる
WebコンテナへのデプロイはCargoを使用
Seleniumによるテスト実行。スキーマのマイグレーションも実施。リリース後Seleniumでのスモークテストも。
成果物が1回のビルドで500MB。バックアップのアーカイブが展開できない。。。
■ 運用でも使えるJenkins @cynipe
Jenkinsのイメージ
開発、ビルドに使うもの。テスト走らせるもの
なんらかのイベントトリガーで実行：記録してくれるもの
運用って日次、月次のバッチやバックアップをとったり。
cronでよくあること：エラーが起きてたのに気づかないとか。。処理時間の統計知りたいとか。。
エラー通知：メールはもちろん。IP Messanger、IRC、Yammerでも可能
スレーブ機能を活用することで各ジョブを回すことができる
Join Plugin, Build Flow Pluginとかで色々できる
jenkins-capistrlo？を作ってます
