https://github.com/ruby-no-kai/rubykaigi/wiki/VideoSubtitleJobs

16m03ja05.txt

で、これらのすごい細かい事については、「大江戸Ruby会議」の０１で、「高速なテス
トサイクルを回すには」ってことで話していた…、話したので、ぜひ、テストの高速化
に興味がある人は、この辺を読んでみてください。

次にデプロイについての話なんですけど、COOKPADでは、デプロイについてルールをいく
つか設けていて、１個目はCIのビルドが通ったらっていうのと、２個目はその、デプロ
イするときにきちんとnotificationを送る、３つめはデプロイが終わった後に、問題が
ないか、正常かどうか確認するというフェーズを取り入れています。

で、CIが通るかどうか、まあここは継続的インテグレーションで行っていて、継続的イ
ンテグレーションのサーバーではJenkinsを利用しています。

で、テストをガンガン行っているんですけど、COOKPADにCI、継続的インテグレーション
でテストを日々サーバが行うってことで変わった開発パターンっていうのがあって、１
個目はさっき言ってたCIを通ったコードのみをリリースっていうことで、そもそも通ら
ないとリリースできないよ、ってフェーズが入ったのと、そうするとそもそも自分が作っ
た成果物をユーザーさんに出すには、テストを通っていないといけないので、みんなけっ
こう真面目にテストを書くんですよ。

で、CIがないと、なんだかんだテストがあってもわりと放置しがちで、いつしか壊れて
るっていうのを後からみつける…みたいになって、非常に効率が悪かったのが、みんな
テストを書いて実行するっていうのがCIサーバがあることによって、なんか、透過的に
意識してやるようになりました。

また、CIで動かないテストっていうのは、将来的に価値のないテストにつながるって認
識がエンジニアの中で産まれて、けっこうその、なんとなくJavaScriptのテストを自分
のローカルで動くだけで書いたんだけど…っていって満足すると、いつのまにかもちろ
んそれは動かなくなっていて、やっぱり、新しい技術を導入する…要するにJavaScript
でテストを書きたいとか、あとはさっき言ってた、Solrで検索技術を導入したいって時
に、そもそも、CIで動くテストを書くって前提がバックであって、それがないとそもそ
もリリースができないので、今は「何か新しい技術を導入する」＝「CIで動くテストを
書く」＝「みんながテストを書く」というサイクルを開発パターンの中に取り入れて、
うまく回すことができるようになりました。

これらについて、継続的インテグレーションについても、RubyStudy@Sapporo#18でこな
いだ話してきたので、興味がある人は、もうちょっと詳しい事はお読みください。

続いて、デプロイのNotification、デプロイの通知なんですけど。

COOKPADではデプロイにはCapistranoを使っているんですけど、ここでちょっといくつか
やってることがあって、デプロイする時にメッセージを記入っていうのをまずやってい
ます。

これはやっぱりその、COOKPADってエンジニア以外の人もいろいろ使ってるんで、そもそ
もどんな機能が追加されたのか？っていうのを受け取るためにSkypeで普通のCOOKPADの、
エンジニア以外の人が、Skypeとかメールとかで変更点を知る事によって、そもそも、こ
ういう変更があったからここの部分が変わったんだね、っていう要するに、お客さんが
僕らはけっこう社内の人たちだったりするので、社内の人たちにこういうところが変わっ
たよ、っていう通知をNotificationで行っています。

続いて、エラーのモニタリングなんですけど、やっぱりリリースした後、なにか問題が
起きたらマズいので、もちろんエラーのモニタリングというのを行っていて。

１個目はまずモニタリングとして、インフラモニターとかって僕らが呼んでいる、モニ
ターですごいたくさんいろんな情報が流れている所があって、ここでなんか、サーバー
がそもそも何かが起きると画面が真っ赤になるので、なにか起きてないかっていうのを
チェックします。

で、ここの所に席が近くない人は、そもそもVNCで繋いでこの画面を見る事ができるので、
この画面をみながらチェックなど行ってます。

続いては、エラーログの監視システムを自分たちで作っていて、実際にRailsとか
JavaScriptのエラーが起きた時に、このエラーログの監視システムに記録をしています。

で、実際、例外っていうのは、なんかもう完全に０にするというのは非常に難しいんで
すけど、バーストっていうのを検知するのはすごい簡単で、なんか問題が起こると、い
きなりその、エラーの通知件数っていうのが跳ね上がるんですよ。

で、跳ね上がったときに、すぐ問題にある、っていうそういうふうに、なにか、要する
に平常時に例外を０にするのは非常に難しいので、なにか問題が起きた時にすぐそれが
分かるっていう所が、重要だと思っていて、それがわかるっていうのを見える化などし
て通知など受け取っています。

最後に、ユーザさんからのフィードバックをどう開発に活かしているのか？っていう所
の解説をしたいと思います。

COOKPAD社内では、Extensionsっていう社内で使っているRails拡張のライブラリを使っ
ています。

で、これはRailsのコントローラとかモデルとかヘルパーとかを、どんどん拡張すること
ができて、その拡張を条件指定で一部ユーザーにのみ有効化などを行う事ができます。

だから、特定の何かが２０件以上あるユーザさんだけに表示…とかいうような感じで、
けっこう、どういうユーザーにどういう風に当てるかなどを決めて、それをExtensionの
機能を有効化することによってユーザーさんにあててます。

で、これが…社内でけっこうプロトタイプ開発を行っているんですけど、すごいそれで
有効に効いていて、１個「Specを書かなくてもよい」っていうルールが、このExtension
の中にはあって、要するにプロトタイプってどんどんどんどん仕様が変わるんで、仕様
をまず書く…ってよりかは、まず作ってあてるって所が重要になるので、ここを書かな
くてもよいルールということを定めています。

で、実際そうすると、じゃあInternal Server Errorが起きたらどうなるんだよ？ってい
うときには、えっと、Rubyの例外catch機能を利用して、例外が発生したとき、
Extensionからの例外だった場合は自動で無効化するような実装が入っています。