Railsをアップグレードするということ

f:id:koichiroo:20160706175639j:plain *1

大場です。

先週はRails5リリースされたように大きな動きのあったRails界隈ですがいかがお過ごしでしょうか。

2016年3月に弊社セミナールームで開催したRails Upgrade Casual Talksの中でも話題にしていたようにCrowdWorksでは、Rails3からRails4へのアップグレードに取り組んでいました。

Rails5がでたところ今さら感も漂いつつあるかもしれませんが、さる2016年6月13日からCrowdWorksはサービス全体がRails 4.2.6で稼働していますことをここにご報告いたします🎉 *2

根幹となるフレームワークを古いまま使い続けることは、洗練された記法が使えなかったり、高速化最適化が進んだモジュールが使えなかったり*3、周辺gemの対応についていけずに置いていかれるリスクなどが負債となって積み上がっていきます。また、セキュリティの問題が修正されなくなるリスクもあるため長い目でみてユーザーに不利益になり、生きたサービスを開発し続けるためにはフレームワークのアップグレードが不可欠と感じています。

CrowdWorksがやったこと

稼働中のサービスのRailsをアップグレードするということは、単に bundle update するだけでは終わりません。ましてやCrowdWorksのような10万行を超えるサービスの中心となるフレームワークを更新していくことにはいくつもの課題があります。社内では「車を走らせながらエンジンを取り替えるようなもの」と課題の大きさを比喩しています。

稼働したサービスを止めずにRailsのアップグレードをするにあたって、段階的な移行を実現するためにRails3とRails4が共存できる環境を構築しました。これによってサービスの特定の機能だけRails4にして公開することが可能になります。問題の発生箇所を絞り込んだり、即座に切り戻しできたり、いちどにたくさんの(制御しきれないほどの)問題が起こることを避けることができました。

このような取り組みのお陰で大きな障害を出すこともなくユーザーへの影響も最小で移行しています。その他、実際にどういう課題に取り組んでどう解決していったかというお話は次回以降に取り上げていきます。