NBM2

natural born minority

about

勉強会行ってみた「Jenkinsユーザ・カンファレンス2015東京」(中編)#juc2015#jenkinsja

うん？遅いって？違うよ「資料が出るまで待ってた」んだよ！(詭弁)

(結局3部構成です…トホホ)

前回までのあらすじ…は [ここ(/study-meeting-repo/2015/01/14/jenkins-user-confarence-2015-f)らへん]を見てくだせえ。

内容

3コマ目:メインホール 「JenkinsとPuppet+ServerspecでインフラCI」

常松伸哉 (@tnmt, GMOペパボ株式会社) さん

風景

拝見したセッションです。。

2013年頃から「Infrstracture as Code」に取り組んでいらっしゃる、ペパボの常松さんの発表でした。

DevOpsと言う単語が席巻して数年、インフラエンジニアからプログラマ、プログラマからインフラエンジニアと行き来する「スーパープログラマ」が一定数いらっしゃるようになりました。

だから今「サーバ構築業」も「プログラミング」も「コードにて表す」ということにおいて垣根が薄くなってって行っていると思います。

「コードならばテスト出来るよね」「テストするなら自動テストだよね」と言う「プログラマーの文法」もおいしいとこ取りできるわけで…

  • サーバ構成管理コード = プロダクトコード
  • サーバ完成検査コード = テストコード

と見立て、それにCI回すのも頷ける話。

…の具体例でPuppetとServerspecとJenkinsで、というのがこの発表でした。

全然やってないのですが、凄く理想的に思え興味を持ちました。

で「大事なのは概念」と思いまして…

「ChefでServerspecでJenkinsでDockerな環境」

という自分が今戦ってる土俵でやってきたいと思いました。

「Serverspecいいなー、俺もやりたいなー」と思って、スライド内の入門本の発売日をみるとなんと昨日！是非買いたい！w

3コマ目:S505教室 「クックパッドにおけるJenkinsの活用」

高井直人 (クックパッド株式会社) さん

実際には見ていないセッションですので、資料を参考に書きます。

上の”まとめ”を見ていますと「資料よりその場で説明したモノ」が多く思えます。くー残念！見たかった。そっちも参考に書きます。

「おむきんす」さん…なんですねｗ

内容…の前に

クックパッドさんは、自社のブログにて技術情報を開示、有用なものはOSSとして公開されています。

当日見てない自分としては「ここらへん読んどく」と理解が早かった…かなと。

クックパッドさんは「量とスピード」にずっと戦って来たのですね。

CIの構成

序盤は「普通に(CI)している」ということで、自社のCI構成の説明されています。拾えるのは…。

  • ほぼ全てAWS上
  • Jenkinsのマスター・スレーブ構成
  • スレーブ中にDockerを使ってるヤツが居る
  • スレーブ中にAndroid/iOS用があり自社サーバルームで動いてる

という感じ。(自分には出来なそうな…ｗ)

…世の「普通」は、難度の話でなく「世のCIの原理原則に乗っ取って」すると、こうすべき…なんだろうと思いました。(資料の最後に答えをくれる構成ですが)

「なぜCIをしているのか」の話

「”CIで守るべき価値”があるから」という話で、そこを掘り進めて「そのために実際に行なっている事」を説明、という流れでした。

「ドリルダウンして説明」しているのですが、当たり前ながら「資料は平面的」なので、自分のためにアウトラインを画像にしてみました。

アウトライン

これを意識できれば、自分も「いっちょ前のCI-erになれる！」…かなぁ？

キーワード

整理したら満足したので、印象強かったキーワードだけ取り出して感想を言って見ます。

  • 開発者は遅いとキレる

ありますねｗ そうすると「最終的に見なくなる」だったりするので、「意識のある間」の「クイックフィードバック」と「嫌が応でも知る仕組み」、てのは重要かなと。

  • 長時間掛かるテストの投機的実行

これは「そういうのもあるのか！」と感心しました。

まとめに意見がありましたが、自分も「スポットインスタンス怖い」みたいな考えだったので…。

でも、スポットインスタンスでなくとも「考え方と仕組み」は脳内に置いときたく思います。

  • 偽陽性を避ける、割れ窓理論

これは強烈に同意ですね。

CIの最大の敵は、「当たり前になり無関心になってしまう」なので。

〆の言葉

「ふつうにしている = やるべきことをやる = 常にそうあるようにする」

うーん、そうなんですよねぇ。

特別事にしない->日頃からやっておりあたりまえにしとくっての、いろんな局面で出くわす教訓です。

3コマ目:S406教室 「Jenkinsを使ったコンシューマゲームでのデプロイとテスト」

田中宏幸 (@swiftnest,株式会社イリンクス) さん

  • 資料:
Jenkinsを使ったコンシューマゲームでのデプロイとテスト from Hiroyuki Tanaka

</div>

こちらも、実際には見ていないセッションですので、資料を参考に書きます。

同じソフトウェアでもプロダクト種が違えばコンテキストが変わる話

「デプロイに14時間34分かかる」という話、自身は業務アプリの世界に身を置いているので、そうなんだなと思いました。(大規模だと時間掛かる例はありますけど、ここまでは行かない)

しかし、横並び違うセッションでも、やはり「テスト・ビルド・デプロイ時間掛かる問題」に戦っているというのは、普遍的な問題なのだなと思いました。

Build Flow Pluign

ビルド(デプロイ)パイプラインを「Job自体に「後続はコレ！」みたいな依存を書かずに」実現するには、このプラグインになるのですが…

  • とあるJobに書かれたDSLに依存することに成る
  • DSLの構成管理がVCS等で出来ない
  • 事前にフローが視覚化出来ない(チャートでここまで来てるとか出来ない)

っていう運命を背負います。

ご多分にもれず問題と捉えられてるようですが、解決策が「Workflow Plugin」とのこと。

基調講演のアイツは「多くの人の期待を背負ってる」ってことがわかりますねｗ

スモークテスト

まとめから拾いますと…

「コンシューマゲームではSeleniumみたいなツールがないけど品質を保つために」

  • 全エフェクトを再生するテストを書いて、制限時間内に終わるか(刺さってないか)をもって確認
  • 引数で特定の部分だけを動くようにして、一定時間内に終了しなかったらエラーに

としているとのこと。

後者は「対象問わず有用」ですんで、自分が仕組みを作る際に頭に置いておきたいと思いました。

モンキーテスト

これは凄いと思いました。

  • ゲーム開始からエンディングまでの通しプレイを自動で行うAI作成
  • 戦闘中がガチャ押し、次エリアが開放されたら敵AIが使ってるパスを流用して移動
  • 画面の状態を見て挙動変更
  • 3回ミッション失敗で無敵＆攻撃力100倍

ギョームアプリで言うと

  • Selenium/Sikuliで「一日分の代表的な業務」をやるエージェントプログラムを作成
  • あまりにもシステムエラーが出まくるなら「特権アカウント」に移行して実行

みたいなものを作成した、ということでしょうか。

パターンにもよるとは思いますが、凄い事で…この考え方を明日の仕事に生かせないか考えたいと思いました。

動画…観たかったなぁw

まとめから

「Jenkinsでの環境構築を開発スケジュールに入れておく」

自社の組織レベルで、CIをコモディティ化したいなら、重要飛び越えて必須なことだと思います。

長い目で見ると、

  • 忙しくなってくる(事後作業)だと暇ない
  • 投入してからはコンスタントに成果が出る
  • 他プロジェクトや派生開発でも使える

という特徴から、コストは回収出来るはず…です。(数字出されろつうと辛い所で、そこが課題ですが)

所感

Jenkins(ひいてはCI)の開発プロセスへの浸透は、その職種問わずコンスタントにしているのだなと感じます。

なので、カンファレンスや勉強会でも「個々の使い方」に話がシフトするのは、当然の話で…。

であるなら、事例発表からは、「その考え方」や「自分の身に置き換えて明日どう使えるのか」を抽出するのが重要だなあと感じました。

もうちっとだけ続きます。 (次回で終わらすぜ)

blog comments powered by Disqus