こんにちは。開発Div. エンジニアの所です。
先日クラウドワークスではRailsのアップグレードに関するTech Talkイベント Rails Upgrade Casual Talks を開催いたしました。
100人の参加枠に対してキャンセル待ちが60人を超える大盛況の中、具体的な事例も交えながらいかにして Rails をアップグレードしていくべきか、その戦略をみなさんと一緒に真剣に考えました。 本記事ではイベントの模様をお伝えしたいと思います。
基調講演: 「Rails側から見たバージョンアップの歴史」
基調講演として、Ruby on Rails における唯一の日本人コミッターである松田さん（@a_matsuda）による「10年戦えるフレームワークのバージョンアップ戦略」をご講演いただきました。
2008年からRailsのコミッターとして関わっている松田さんが見る Rails の10年に及ぶ歴史から、Railsが未だに人気のフレームワークである秘訣、またOSSコミュニティとして Rails と Ruby の比較/違いも交えながら興味深いお話をご講演いただきました。
「Railsバージョンアップを段階的に行うためにRails3/4並行稼動させる仕組みを作ってる話」
弊社エンジニアの森田（@minamijoyo）による「Railsバージョンアップを段階的に行うためにRails3/4並行稼動させる仕組みを作ってる話」をお話させていただきました。
クラウドワークスでは現在進行形で Rails4 へのバージョンアップを進めている段階であり実はまだ本番投入していないのですが、現時点での知見を交えて具体的な内容をお話させていただきました。
「activerecord 3.2 -> 4.1 」
クックパッド社技術部の鈴木さん（@eagletmt）に「activerecord 3.2 -> 4.1 」をご講演頂きました。
ActiveRecordのバージョンアップに特化した内容で、具体的にハマった事例やリリース後に発生した問題点を中心にご講演頂きました。
「安心してRailsアップグレードを行うための工夫」
クックパッド社技術部の国分さん（@k0kubun）に「安心してRailsアップグレードを行うための工夫」をご講演いただきました。
こちらはクックパッド社のエンジニアブログに詳細な記事が掲載されております。
パネルディスカッション
弊社CTO大場（@koichiroo）がモデレーターを努めさせていただき、予めゲストの皆さまから頂いた質問をテーマに講演者同士でのパネルディスカッションを行いました。
実際のディスカッションでは会場の皆さまからの発言も交えながら、双方向で議論を深めていきました。活発な議論が行われましたが、ここではいくつかの質問をピックアップしてご紹介したいと思います。
Railsをアップグレードするときにはまった罠はなんですか？
前半の発表でかなりカバーされていたのではないか、と皆さんが頷きながらも会場からは Rails 本体の巨大化によるパフォーマンス劣化の指摘がありました。
先述の松田さんの発表の中でも ActiveRecord はメジャーバージョンが上がる毎に大幅なリファクタリングに加えてパフォーマンス劣化が起きているとありました。 その対応について根本的な解決ではありませんが、パフォーマンス向上が期待できる ruby のバージョンアップも同時に行うことで影響を小さくする案などが示されました。
また、公式ドキュメントである Rails の変更点が書かれているリリースノートとアップグレードガイドについての話題では、簡単にしか書かれていない変更内容があったりするので、ドキュメントだけですべての影響を把握するのは難しいというのが皆さんの共通認識でした。ドキュメントに書かれていることだけではなく、実際に変更された Rails のコードを確認している登壇者も多かったです。
サービスが動作することに関してどの程度の確信を持ってプロダクションデプロイしていますか？
クックパッドではアップグレード担当者だけでなく、各部署で動作確認を行ってからリリースを行いました。それでもリリースしてみないとわからない部分は最後まで残っており、本番で起きてしまったエラーはユーザー影響が少ないうちに早めに直すというアプローチを取ったそうです。
ただし、これはあまりミッションクリティカルなアプリケーションではないから取れたアプローチであり、どこまで動作確認の確信を持ってリリースするべきかはアプリケーションの性質によって変わるであろうという意見でした。
全くテストがない状態のアプリではえいやでアップグレードしてしまうのか、まずテストを書くのかのどちらでしょうか？
過去のクックパッドの具体的な事例によると、テストがほぼなかった昔のクックパッドではまずテストを書いたそうです。
各部署にテストを書くようにお願いして、中にはテストをひたすら書く開発合宿を行った部署もあり、そうしてテストを揃えた上でアップグレードを行ったそうです。またテストの中でも feature spec の重要度が大きかったそうです。
Railsの新バージョンがリリースされてどれぐらい経ってupgradeしますか？(特にメジャーバージョンが上がったとき）
現実的にはプラグイン(Gem)の対応次第であろうという意見が多数でした。Railsが beta、rc の段階ではまだまだプラグイン開発者の対応が追いついていないことが多く、 x.0.0 の段階ではまだ様子見の方が良いかもしれません。
また、次のRails5.0に対応しているかどうかの視点としてコードに alias_method_chain が残っているかどうかを確認すると良いかもしれません。*1 また、合わせてプラグインが互換性を残す方向なのか、最新版だけを追随する方向なのかは確認した方が良いという意見も出ました。
新しいRailsにgemが未対応だった場合などありますか？あった場合、それらを含めたアップグレードの方針はどうしますか？
この場合は未対応の gem を fork して修正し、upstream にプルリクエストを送ってマージされるまで fork を使う方針が良いという話になりました。ただ fork して修正するだけだと、自分達で保守し続けるのは辛くなるのでなるべく本体に還元したほうが良いという共通見解でした。
ただし見込みがないgemを使っていて、仕方ないので似たようなプラグインを自分で作るという選択肢もあり、具体例として松田さんが作成した kaminari や最新作の stateful_enum はそういう背景で作られたそうです。
Rails5にアップデートするためにやろうとしていること
今回の Rails5 では Sprocketsは3系へ Turbolinks は5.0系へ変わりますが、 Turbolinks を使っている所は多くないでしょうし、 ActionCable をすぐに使わないのであれば特別な対応は必要なさそうです。
ただ、今の Rails5 beta の段階ではまだまだプラグインの対応も進んでおらず bundle install も通らなかったりするので、自分でプラグインを積極的に直してコントリビュートする気概で進めたいですね！
www.flickr.com 弊社CTO大場の可愛い娘さんも参加! *2
懇親会
イベントのあとは飲み物と軽食と一緒に皆さんと懇親会を開催し楽しく交流いたしました。
実際に直面している問題について真剣に話し合っている人たちもいれば、談笑している人たちもいて、皆さんに楽しい時間を過ごしていただけたようです。
また、 @toshimaru_e さんがまとめてくださった本イベントのtwitter反応まとめはこちらです。ありがとうございます！ togetter.com
みなさんからご好評いただき運営としても嬉しい限りです。 クラウドワークスでは今後もこのようなMeetupを主催していきたいと考えております。
また、クラウドソーシングのクラウドワークスでは一緒にフレームワークのアップグレードを行う仲間も積極的に募集しております！
*1: Rails5 から alias_method_chain は Deprecated 扱いになりました。Deprecate alias_method_chain in favour of Module#prepend by kirs · Pull Request #19434 · rails/rails · GitHub
