メドピア開発者ブログスマートフォン用の表示で見るメドピア開発者ブログ集合知により医療を再発明しようと邁進しているヘルステックリーディングカンパニーのエンジニアブログです。Tumblrこんにちは。Rails(以下Rails)のリードエンジニアを担当している橋本と申します。5.1での開発についてというイベントを開催しました。5.1の新機能や開発環境に関してさまざまな発表が行われ、来場したエンジニアの方からも好評のうちに終えることができました。5.1へとアップグレードを行い、当日、その内容の発表を行いました。今回のブログ記事ではその発表を元に、アップグレードのためにやった6つのことについて紹介を行います。5.1をはじめ、アップグレードされたGemを安全に本番環境に投入できるように、以下の2つのブランチを作成しました。5.1で動かせる状態にするためのブランチで、アップグレードに必要な作業量と、コード修正の見通しをつけるためのものです。5.1に依存するGemのみ手早くアップグレードを行いました。railsを実行します。5.1'コマンドの実行後に、下記のようにRails本体に含まれるGem(具体的にはactivesupport、activerecordなど)へ依存関係のあるGemの競合解消に失敗したというエラーが表示されるので、1つ1つアップグレードしていきます。act-fluent-logger-railsを実行します。5.1で動作できる状態になります。(コードの修正は別途行う必要があります。5.1を動かすためのブランチで、調査用ブランチと異なり、(可能な限り)全てのGemのアップグレードを行なったものです。次節のようなGemのグループ分けを行い、各グループを順番にアップグレードを行いました。updateを行わず、グループに分けたGemのアップグレードを行ったのは、後述のデプロイの差分を小さくするためと、グループごとに利用する環境や検証の作業が異なるためです。本番リリースに必要なコードの修正も最終的にこのブランチにコミットを行いました。Gemのグループ分け本番用ブランチでのGemのグループ分けは以下のようにしました。railtiesなどを含む)グループ分けしたGemはアップグレード後に、各環境のサーバーで検証が行われました。5.1アップグレード用の検証環境を用意しました。Rails本体」の場合は、検証環境で手動テストを含む十分な検証を実施してから、本番環境へのリリースを行いました。デプロイ時の差分を小さくしておく本番環境へのリリース(デプロイ)の際には、できるだけ以前のリリースとの差分が小さくなるようにしておきました。理由としては、差分が大きくなると不具合が発生した際に、原因(どのGemのアップグレード・どのコードの変更によるものか)の判別が難しくなるからです。Rails本体を5.0から5.1へアップグレードしてデプロイする際にはリリースの差分が以下のようになるようにしました。Gemfile.lockの変更がRails本体に含まれるGemのアップグレードのみとなっている。他のコードも、5.1でしか動かないコードの変更のみとなっている。5.1でのリリースでの変化を小さくしておくようにしておきます。アップグレードガイドとリリースノートに目を通すアプリケーション側でどの部分のコードを変更するか把握するために、以下の公式のアップグレードガイドをチェックしました。5.1へのアップグレードに関する部分に目を通しておきます。5.1の変更内容や新機能の詳細に関しては、リリースノートに書かれているので、こちらもチェックを行いました。5.1リリースノート(上記の日本語訳)ここで非推奨や廃止となったメソッドなどの記述についても詳しく書いており、アプリケーションで使用していないかチェックを行いました。アップグレード前後でコードを正しく修正する上記のアップグレードガイドとリリースノートの内容を元に、コードの修正を行いました。5.1へのアップグレードの前後で行う必要がありました。WARNING(非推奨の警告)が出力されている場合は、該当する記述を修正する必要があります。has_manyのclass_nameオプションにクラスを指定している部分を修正モデルのhas_manyのオプションのclass_nameにクラスを直接渡していた部分で上記の警告が出力されていたので、文字列に変更を行いました。5.0からActionController::ParametersがHash(のサブクラスのActiveSupport::HashWithIndifferentAccess)から継承されなくなったのに伴い、コントローラのparamsに対して、symbolize_keysを実行している箇所で警告が発生していたいので、修正を行いました。各種設定ファイルを5.1に合わせて更新していきました。app:updateを実行します。このタスクを実行すると独自にカスタマイズした内容が上書きされる可能性があるので、実行の前後のファイルの差分を確認して妥当な内容にする必要があります。5.1からconfig.load_defaultsというメソッドが提供されるようになり、バージョンごとの推奨の設定を読み込めるようになりました。今回は、config/application.rbに以下の内容の記述を行いました。5.1からはシンボルにする必要があります。5.1からは、以下のようにシンボルにしないと参照できなくなっています。アップグレード時に大きな変更を行わない今回は、Railsのアップグレードと同時に工数が発生するような大きな変更を加えないことにしました。具体例として、プライマリキー(id)をBIGINT型にしないようにしました。5.1では新しく作成されるテーブルのプライマリキー(id)の型がBIGINTになるという大きな変更が加えられました(PostgreSQL/MySQLの場合)。(integer)を使うという選択を行いました。5.1で作成した新しいテーブルでidがINT型になるように以下のような対応を行いました。:integerのオプションがつくようにしました。エラーになってしまっていたので、ActiveRecord::Migrationの部分に例えば以下のようにバージョンを付与しました。:integerのオプションをつけるようにしています。...まとめRailsをスムーズにアップグレードするために上記の6つのことを実施しました。5.1環境で安定して稼働しており、フロントエンド周りの新機能を生かした開発なども進めることができています。今回のアップグレードを通して、古いRailsやGemを使い続けることによるセキュリティへのリスクを回避でき、また、チーム内のメンバーのRailsに対する意欲や関心を高めることができたのはよかったと思います。5.1を題材に取り上げましたが、内容としては過去や将来のRailsのバージョンに対しても適用できる内容だと思うので、参考にしていただけると幸いです。́)งメドピアでは一緒に働く仲間を募集しています。Tumblr関連記事2019-04-26RubyKaigi2019にプラチナスポンサーとして参加しました!👉🍻サーバーサイドエンジニアのhirapi(@chmv71)です。エンジニアの宮原です。chromeへ移行する時に気をつけることこんにちは。月別アーカイブリンク医師専用サイト「MedPeer」エンジニア採用はこちら!スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。