クックパッド開発者ブログスマートフォン用の表示で見るクックパッド開発者ブログ2016-03-29安心してRailsアップグレードを行うための工夫こんにちは。Talksで、Railsアップグレードの際にクックパッドが行なっている工夫について紹介しました。影響範囲の予測が難しいRailsのアップグレードを安全に行なうための動作確認のやり方について参考になればということで、本記事でも改めて紹介いたします。4.1から4.2にアップグレードした際の例を紹介します。4.2にアップグレードするためのrails42ブランチでテストを通します。リリースするまでこのブランチはmasterからrebaseし続けるので、リリースまでテストを通る状態を保つため、CIにrails42ブランチ用のジョブを用意します。このジョブはCIサーバーのリソースが空いている早朝に実行します。Requestを分割します。4.2両方で動く修正やgemのアップグレードを先に行います。Tokenという、セッションに後方互換性のない変更を加える機能があります。4.2アップグレード時には以下のようなモンキーパッチを行なってリリースしました。4.2のリリース後落ちついてから外しました。@minamijoyoさんの発表にあったbreach-mitigation-railsを使うのも良いかもしれません。複数の部署が関わるアプリケーションであり、私一人では全ての影響範囲の確認が困難なため、関係部署が動作確認できる期間を2週間設けています。後述しますが、これと並行して本番に近い環境でエラーが出るかの確認も行います。リリース直前に動かなくなるリスクを抑えるため前日夜からコードフリーズし、デプロイの影響を小さくするため、午前7時に出社して8時にデプロイを行います。トラフィックが低い時間帯にデプロイしたいものの、関係者全員に深夜の出社を要求するほどではないためこの時間になっています。デプロイして終わりではありません。間を開けずにリリースすると問題が起きた時の対応が大変になるので、約1週間かけて段階的にデプロイします。4.1用のrails41ブランチを作りmasterの変更をバックポートし続けるため、あまり移行期間を長くするとその作業が大変になってしまいます。デプロイ後の監視デプロイ後はSentryを使ってエラーの確認を行い、自社製のモニタリングツールを使って各サーバーのレスポンスタイムを監視します。複数のアプリを1週間かけて段階的にリリースするデプロイ後、レスポンスタイムとエラーを監視リリース前の4段階の動作確認Railsのアップグレードをリリースするまでに以下の4段階の動作確認を行なっています。4.2のブランチをデプロイします。Railsアップグレード関係なく、もともと任意のブランチをhttps://rails42.staging.~/のような任意のサブドメインにデプロイできるようになっていて、この環境を使って各部署に動作確認を依頼します。4.2のブランチをデプロイし、リバースプロキシの設定を変更して動作確認を行なう人だけがそのサーバーにリクエストを飛ばせるようにして、手動で動作確認を行います。4.2の環境にプロキシされるようにし、適当にクッキーをセットした上で手動で動作確認を行ないます。4.2の環境にプロキシされるようにし、mitmproxyでアプリの全てのリクエストにそのリクエストヘッダーを付加し、手動で動作確認を行ないます。4.2をデプロイしたものにも流し、そこではDBなどへの書き込みや外部サービスへのリクエストを抑止します。実際の様々なリクエストが流せるため、手動では見つかりにくいエラーを発見したり、パフォーマンスの変化を確認したりすることができます。Test」と呼ばれるほぼ本番の環境に自動的にデプロイされます。リリース直前で再度本番と同じ環境で動作確認をすることで、より安心してデプロイを行なうことができます。4.2のアップグレードではリリース後にエラーが大量に出るようなことはなく、これまでリリース後に発見されたRails自体のバグは以下の2つだけでした。Requestを投げて修正するようにしています。Requestを投げ、4.2.5に取り込まれましたhttps://github.com/rails/rails/pull/21402まとめクックパッドがRailsアップグレードの際に行なっている工夫について紹介しましたがいかがだったでしょうか。4.2.6で動いています。開発しやすく、バグや脆弱性の少ない最新のRailsを使い続けることで、より良いサービスを届けられるようにしたいですね。