Railsのバージョンアップ方法
この記事は何?
Railsのバージョンアップ方法について
対象読者
参考資料
公式ドキュメント
https://railsguides.jp/upgrading_ruby_on_rails.htmlもんセレクション@Railsを5.2.3から6.0.1にアップグレードする手順
https://mon-sele.com/post80/Qiita@永久保存版!?伊藤さん式・Railsアプリのアップグレード手順
https://qiita.com/jnchito/items/0ee47108972a0e302caf
大まかな手順
Rubyのバージョンを上げる
下記よりもRubyのバージョンが低い場合は、事前にRubyのバージョンを上げる
バージョンアップによる変更点の概要を知る
公式ドキュメントのリリースノートやチェンジログを読み、変更点の概要を知る
Rails 5.1からRails 5.2へのアップグレード
などとまとめられている
https://railsguides.jp/upgrading_ruby_on_rails.html
Railsのバージョンを上げる
- gem 'rails', '5.1.x.x' + gem 'rails', '5.2.x.x'
古いgemを洗い出す
Railsと依存関係にあるgemのうち、アップデート後のバージョンと依存関係が合わないgemを洗い出す
bundle update --conservative rails
Bundler could not find compatible versions for ...などとエラーが出る
gemが依存しているRailsのバージョンが古いとエラーになる
gemのUpdate
dependabotを使うなどして、エラーが出力されたgemのアップデートを行う
あるいは、Rails Updateのタイミングで利用するgemをすべて最新にするでもOK
(注意)
gemが特定のRailsのバージョンまでしか対応しておらず、保守運用されていないことがある
その場合は、updateしても解決しないためgemを使わないように対応が必要
設定ファイルの新規作成や変更
アップデート後のRailsに必要な設定ファイルや記述を作成する
rails app:update
新規作成されたり、既存ファイルに変更が入るため、差分をチェックして問題ないことを確認し、必要分を選択してマージする
※ バージョンアップ後のRailsで導入されたgemは自動で追加してくれないので、必要に応じて対応 railsdiff.orgを参考にして、新しく追加されたgem等を確認する
Railsをバージョンアップ
4.の手順だけではまだ新しいバージョンが反映されてない
config/application.rbにある config.load_defaults
で設定を変更
- config.load_defaults 5.1 + config.load_defaults 5.2
エラーに対応する
(1) RSpecを実行すると大量にエラーが吐き出されるはずなので対応
バージョンアップすると様々な変更箇所が反映され、テストが失敗する
エラー内容、下記のChange logなどを確認しながら対応する
https://railsguides.jp/5_2_release_notes.html
(2) new_framework_defaults_x_x.rbで設定が変更された箇所を確認し対応
4.の手順でconfig/initializers直下に new_framework_defaults_5_2.rb
といったファイルが新規作成される。このファイルにはバージョンアップで大きく挙動が変更される箇所の一覧が記載されている。
このファイルでは、下記ができる
- 仕様変更の確認
- 旧バージョンの挙動の引き継ぐ設定
内容を確認し、最新バージョンに対応させる、または旧仕様を引き継ぐことでエラー解消する。コメントアウトされているのは、バージョンアップ後の仕様で、旧バージョンの仕様を引継ぎたい場合はコメントアウトを外し、booleanの値を反転する必要がある。
new_framework_defaults_x_x.rb
については下記が詳しい
https://qiita.com/jnchito/items/cce3b2795e1c66735310
また、コメントアウトされている場合にも バージョンアップ直後は旧バージョンのままでの運用を推奨 などと書かれている場合もあるので注意が必要
最後にSTG環境で手動確認
最後は手で色々叩いて確認する
画面上でのログイン、主要機能に加えて、APIなども一通り叩いて確認
specの記載漏れや、情報がほぼないような箇所でコケてたりするので抜かり無く!
本番環境へデプロイ
多分エラーが出る
そのため、revertコミットを事前に準備するなどして緊急時にもすぐ戻せる万全の体制でデプロイ
5.2へのUpdateでハマった箇所、ポイント
CSRF対策(protect_from_forgery)がデフォルトでActionController::Baseに移行
# Add default protection from forgery to ActionController::Base instead of in # ApplicationController. # Rails.application.config.action_controller.default_protect_from_forgery = true
従来ApplicationControllerに設定されていた protect_from_forgery
がActionController::Baseに移行された。APIのcontroller等でActionController::Baseを継承していたりすると落ちるため、ActionController::APIを継承したり、skip_before_action :verify_authenticity_tokenを足したりする対応が必要
Rails Updateに向けて普段から気をつけること
下記を普段から意識するとRails Updateがより簡単になる
- Dependabotなどを導入し、gemのバージョンを最新に保つ
- DeprecatedなどのWarningは、放置せずに対応する
- gemを使う場合、保守運用されるものを使う
- テストはしっかり書くべし
など
ゼロからのDocker入門
この記事は何か
Dockerを全く知らない段階から、下記を目指すためのロードマップです。
- Dockerとは何か?全体像を理解する
- Dockerで開発環境を構築できる
- 開発現場で既存のDockerfileやdocker-compose.ymlを理解し、編集できる
- その先にあるKubernetesやAWSなどに興味を持つ
TLDR
公式Docのチュートリアルをやると理解が捗ります。
https://docs.docker.com/
英語の文章を読むのが辛い時は
最近話題のDeepLで翻訳すると日本語で読めます。
英語は読めるが日本語の方が理解が早いという方も是非。
https://www.deepl.com/translator
Dockerとは
Docker overview | Docker Documentation
Dockerが従来の仮想化ソフトウェアよりも優れている理由
- 軽量である(容量が小さい)
- 高速である(起動や処理が早い)
軽量、高速である理由は下記を参考にしてください。
Dockerとは何か、何が良いのか
Docker入門(第一回)~Dockerとは何か、何が良いのか~ | さくらのナレッジComparing Containers and Virtual Machines
What is a Container? | App Containerization | Docker
Dockerを導入するメリット
- 開発環境構築が簡単になる
- Dockerfileやdocker-compose.ymlを用いて、開発環境をコード管理できます
- プログラミング言語やデータベースの手動での導入...といった煩わしい作業から開放されます
- 開発環境を簡単に共有できる
- コード管理された開発環境のため、バージョン差異なく簡単に共有、構築ができます
- そのため、新規参加メンバーが環境構築で失敗、躓くことがなくなります
- また、PC購入時やデスクトップとノートPCの使い分けの際にも、楽に環境構築ができます
- 開発環境を簡単に実行できる
- docker-composeにより、1コマンドでアプリケーション全体の起動を行えます
- そのため、アプリケーションやデータベースなどをそれぞれ実行する手間が省けます
- また、Railsは起動したけど、PostgreSQLの起動し忘れた...などの問題を防げます
- テスト環境や本番環境の構築も楽になる
- ローカルの開発環境と同じ環境を簡単にCircle CIやAWS上に作ることができます
- そのため、ローカルではテスト通るけど、CIだと落ちてしまうなどの問題を少なくできます
- ただし、開発環境と本番環境は全く同じであることは少ないため、工夫は必要です
より詳細に
https://docs.docker.com/get-started/#docker-concepts
手を動かして学ぶ
下記リンクのどれか良さそうなものを選び、image、container、volume、docker-compose、networkなどDockerの主要機能や概念について学びます。私は一通りやりましたが、公式Docのチュートリアルが最もコンパクト、過不足なくまとまっており分かりやすいです。
オススメ
- Orientation and setup | Docker Documentation
その他の選択肢
- Dockerでプログラマが最低限知るべきことが、最速でわかるチュートリアル - Qiita
- Linuxコマンドから始めるDocker ~ BE A FIRST PENGUIN AND GROW AS WHALE | Udemy
- ゼロからはじめる Dockerによるアプリケーション実行環境構築 | Udemy
- Docker Deep Dive by Nigel Poulton [Leanpub PDF/iPad/Kindle]
Ruby on Rails + PostgreSQL + Docker環境の構築
WIP
Dockerの次に学ぶこと
WIP
参考文献
公式Doc
https://docs.docker.com/
概要、詳細はもちろんのこと、クイックスタート(チュートリアル)やRailsでの利用方法といったSampleも充実しているため、必見です。Docker Deep Dive
https://leanpub.com/dockerdeepdive
Amazonレビューが高かったので読みました。説明が丁寧で、各章において概要や背景から入り、その後手を動かしながら詳細を学ぶというスタイル。個人的には冗長に感じてしまう部分も多々ありましたが、全体的に分かりやすいのでオススメです。なお、Amazonの方が安いですがコピー制限がありDeepLで最後まで日本語翻訳できません。leanpubで購入してpdf落とすと制限なく翻訳できます。
Railsでビジネスロジックをどこに書くか?
どのような歴史を辿ったか?
Rails勃興(2004~2005年)
ViewやControllerにビジネスロジックを記述。見通しの悪さが問題に
モデルにビジネスロジックを書くべきという主張(2006年)
Buckblog: Skinny Controller, Fat ModelFat Modelが問題。サービスオブジェクトなどModelの責務を切り出す動き(2012年)
7 Patterns to Refactor Fat ActiveRecord Models - Code Climate
(日本語訳)肥大化したActiveRecordモデルをリファクタリングする7つの方法 Railsで重要なパターンpart 1: Service Object(翻訳)|TechRacho(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS株式会社サービスオブジェクトの間違った運用に警鐘を鳴らす
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
Service Objectがアンチパターンである理由とよりよい代替手段(翻訳)|TechRacho(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS株式会社
その他参考
Railsのファットモデル問題に対処する前に読んでほしい記事 - Qiita
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it? - Speaker Deck
railsのエラー処理
参考
1.controller外でのエラー処理
例えば、routing時のエラー(存在しないurlの指定)など
Rails の rescue_from で拾えない例外を exceptions_app で処理する - Qiita
参考コード
add: routing時のエラー制御等を追加 · fv17/rails6-practice-guide@9867d5a · GitHub
2.controller内でのエラー処理
Action Controller の概要 14.Rescue
参考コード
add: エラー表示画面を作成 · fv17/rails6-practice-guide@d86e36a · GitHub
メモ、補足
書籍(Rails実践ガイド)だとStandardErrorもハンドリングしているが、Railsガイドだと非推奨。 親クラスなので、一番最初に指定しないと全て500でキャッチしてしまうリスクがある。
rescue_fromにExceptionやStandardErrorを指定すると、Railsでの正しい例外ハンドリングが阻害されて深刻な副作用が生じる可能性があります。よほどの理由がない限り、この指定はおすすめできません。
参考コード
スクラムマスターとしてすべきこと
メモ
SMとしての役割
- 仕事の可視化
- ムダの可視化
- モチベーション向上
- 障害の追跡と除去
- イベント成果物への集中
- 依存関係の可視化
POへの支援
- リリース計画の支援
- Epicを見積もる
- リリースバーンダウンチャートの作成
- デミングの20%の変動(期間が長いと50%ズレる例も)
- ステークホルダーからの要求管理を支援
- スコープ設定やMVPでの製品開発を支援
開発チームへの支援
- 機能横断的な動きを支援
- スケジュールの可視化を支援
- 技術的リスクの発見を支援
- リーンなドキュメント作成を支援
- タスク分割や割当等を支援
1/2の時間で2倍の成果を出すには?
- 安定したチーム
- 昨日の天気で早く終える
- 3スプリントの平均ベロシティを計画に考慮
- 終わらないスプリントはチームの士気を大きく下げる!
- スウォーミング
- 思考の切り替えはムダである
- 優先順位の高いものから順に終わらせる
- 機能横断を実践するためT型人材
- 割り込み
- 割り込みのためのバッファを、あらかじめ計画に含めておく
- 計画時に詰め込みすぎず、余力を残す
- クリーンなコード
- バグはその日のうちに
- 幸福指標
- コミュニケーションコストを下げる(RW時)
- 必要なツールは導入
- テキストではなく、小さいMTGを開く