Jenkinsユーザ・カンファレンス2012 Tokyo http://connpass.com/event/467/ に参加してきたのでメモを載せます。
Jenkins 新機能の紹介 by Jenkinsの父 川口さん
- 金曜から日本にきて大阪いったりいろんなところいったり
- 世界中で使われています
新機能の紹介
フロントエンド
- 右クリックですぐコンソール出力みれるようになった。
- ナビゲーションバー、保存ボタンなどをstickyにした
- ビルド手順。ドラッグで順番並び替え。前からできるんだけど見やすく
バックエンド
- マルチ構成プロジェクトの改善
- REST APIの改善
- コマンドラインクライアントの改善
- rubyのANSIカラーコードのコンソール対応
プラグイン開発環境の改善
- buildhive.cloudbee.com
- github連携。フリー
Jenkinsプロジェクト運営体制の整備
- SPIに参加した. jenkins-ci.org の管理を個人ではなくSPI経由で.
- Jenkins CIAプログラム
- Jenkinsについてどこかで発表してください
- 制覇した街をPINで止める
- IRC上で毎週、意思決定
- 開発者ライセンス契約(CLA)
- 長期サポート(LTS)ブランチ。毎週ではなく3ヶ月ごとなど。
Continuous Integration Continuous Quality Hohn Smart (@wakaleo)
Continuous Quality
- Automate Testing, Automate Acceptance test
- Contnuous Delivery requires Continuous Quality
- Agile: High level Goal > Capapilities(要求) > Features > Stroeis > Examples
- We need to define acceptance criteria
- 最初の段階ではなにを実現しようとしているのかを定義し、
- 次の段階ではビジネスゴールとして何を達成・実装していくのかを定義します。
- そしてビジネスに貢献するために何が必要なのかまで分解していきます
- コードを書く上で、なんのためにコードを書くのかを知っていなければコードを書くのは適切ではない
- そのコードで実現するストーリー、requirementを理解していなければいけない。
- すべてのストーリーは顧客に価値を与えるものでなければならない
- cucumber で受け入れテスト自動化できます
- thucydides?を使っている
- corresponding feature が部分的にどのぐらい完了しているのかが見れる。(pending をいれているかいないかでわかる)
How to exploit Jenkins
- Quality Gateways
- Release Candidates の選定
- Reporting and Documentaion の生成
- 顧客によってはパッケージしたjarファイルに対して受け入れテストを実行したい。jarファイルの品質を確保したい。
- Build Pipelines を使う
- Test -> UAT (User Acceptance Test) -> DEPLOY
- 組織によっては継続デプロイまでやっているところもあるが、エンタープライズでは継続的デリバリ(デプロイ手前)までは自動化することが望ましい
テストの分離
- テストには早いテストと遅いテストがある。遅いテストを切り分けておけばフィードバックを早く得る事ができる。
- 早いテストも遅いテストもそれぞれJenkinsのジョブとして動かします。
- その後、受け入れテストを実行し、コードのメトリクスを算出します。
- これらが通るとリリース可能なバイナリのセットができあがります
- 感想:うちも遅いテストジョブ、と早いテストジョブに分けて、早いテスト => 遅いテストのパイプラインにするか。
- 感想:カバレッジ目標を超えたら合格、というジョブも追加したいね。Cobetura Plugin
- HTML Publisher pluginを利用して、受け入れテストの結果をpublishする
- リリース対象のバイナリを極力容易に識別できるようにすることが重要です。
質疑応答
- Q. Acceptance Test のライン。コンサルタントとして。
- depends on Project. でも自動化テストの結果に manual とマークしておく。
- Q. 設定ファイルなどはどうすれば?
- 設定は外だしするように心がけている。そうすることでバイナリは変えずにすむ。設定ファイルはターゲットのサーバにあらかじめ置いている。
飛行機を飛ばしながら直す方法 R. Tyle Croy @jenkinsci の中の人
継続デプロイメント
- サーバサイドで継続デプロイメントの実施をしている。とにかくワンクリックでできてしまう。
- ただ、リリースを早く、早くする、ということについてはまり賛成しない
- 受け入れテストを自動化するということはQAチームがいらないということではありません
- ユーザがテスターだ、ということでもありません
- デプロイしたら、ユーザから、または自動化されたフィードバックを受ける仕組みが必要(ログ解析)。それが継続デプロイの鍵
改善プロセス
- 継続デプロイは組織をいろいろな側面で改善する
- リリースブランチを切って10-18日様子をみて問題なさそうならリリースする
- マニュアルでコードレビューも実施している
- 継続デプロイのファンではあるが、36%が失敗している。
- そして多くのビルドは中止される。
- バグがある、修正できる、でもいつ修正がおわるか予測できない、という状況が困る
- とにかく修正せねば
- 開発をつづけながらプロセスを改善していくというチャレンジがあった。
チャレンジ
- 1つはJenkinsを導入すること。Jenkinsを導入すればすぐにフィードバック(テストの失敗)がある。
- よりよいツール、プロセスの導入について。
- svnを使っていたが、gitに。Gerritが対応していなかったし。
- Gerritはオンラインコードレビューができる。
- JenkinsとGerritが連携すると、検証済みマージが可能になる。
manually automatedというコンセプト
- 自動化プロセスの中に人間系(コードレビューとか)が組み込まれている概念
- とにかく自動的にいろいろやってくれるロボット(マシン)が必要
- OpenStack/jcloudsプラグイン/salve management with puppet
ToDo
- no automated rollback。自動ロールバックがあれば、デプロイメントの心配がいらなくなる。失敗すればロールバックされるので。感想: うちもこの仕組みがなくて困っている
- feedback mechanism (バグ報告だけでなく、イイネ!的なもの)
- プロダクション環境への受け入れテストは自動化できていない
- テストが遅い。今はある程度並列化しているが15分かかる。直列だと数時間。
- 例えば本番環境で問題があって、緊急対応したときに15分というわけにはいかない。
- デプロイの自動化を頑張った結果、失敗は3%までに減った。
質疑
- Q migrationに関してはどうしている?
- data migrationの自動化は無理だと思っている。なぜなら、テスト、ステージング環境のDBはプロダクションにくらべて完全に小さいから。そこが手動の部分だと思っている
Complex Build Workflows and Jenkins, Andrew Bayer (@abayer)
ジョブが複数になり、組み合わせが複雑になってきた
- 昔:1つのジョブのなかでpythonスクリプト呼んでやっていた。1つのpythonスクリプトでやっていた。
- 今:プラットフォーム毎、コンポーネント毎にジョブを分けている
プラグイン紹介
- Parameterized Trigger Plugin, Conditional build Step Plugin
- 条件によって別のビルドを走らせる
- jclouds plugin
- like EC2 plugin, but for any cloud
- Multi-SCM plugin
- 1つのビルドで複数のレポジトリをチェックアウトしたい場合
- Description Setter Plugin
- 正規表現でビルドログをさらい、job のdescriptio を設定できる。Hadoopが原因で失敗、とか簡単にわかるようになる。
- Associated Files Plugin
- ステージング用のファイルはここにあるとか、ビルドが削除された場合、関連するファイルも一緒に削除してくれる。
- Cloudbees Jenkins Enterpreise Template Plugin, All changes plugin
- ビルド結果の違いのある部分をまとめて一覧表示してくれる
- github plugin
- ビルドをポーリングベースではなくpost hookでやってくれる
- job config history plugin
- job del plugin
質疑
- Q. Jenkinsの設定はどうやって管理している?SCMにいれてる?
- A. job config history プラグインが好きで、それで管理できる。スクリプトはgitにいれている。満足していない。
- Q. cloudbees template plugin は高いの?
- A. 隣の川口にききなよ。高くはないらしいよ。
- Q. スクリプトは別のレポジトリにいれてるの?
- A. 別のレポジトリですよ。最近友達が書いた job dsl pluginを使うとjenkinsの設定をgroovy スクリプトにして、ジョブの設定を管理できる。