こんにちは、サーバーサイドエンジニアの山田です。
ユニファ開発者ブログに初投稿です！
以前から続けていたRuby/Railsバージョンアッププロジェクトが完了しましたので、今回は作業を進める中で気をつけたことについて書こうと思います。
この記事は以下2つの続編となります。
tech.unifa-e.com tech.unifa-e.com
プロジェクト完了
2023年1月に最終リリースを行い、現在も問題なく動作しています！
段階的にリリースを重ね、最終的にはRuby2.7/Rails6.1へのアップデートとなりました。
Rails バージョンアップで気をつけたこと
具体的なアップデート作業については Rails アップグレードガイド - Railsガイド やリリースノートをご確認いただければと思いますので、今回は作業を進める中で気をつけたことについてまとめました。
- 変更内容を丁寧に記録する
- config を整理する
変更内容を丁寧に記録する
これはアップデート作業に限った話ではないのですが、変更内容を丁寧に残すのはとても重要なことだと思います。 普段から気をつけるのが理想ではありますが、少なくともRailsアップデート作業では特に意識するのが良いと感じました。 慎重に作業を進めたとしても残念ながらアップデート後に問題が発生してしまうこともあります。何のために変更を行ったのかを分かりやすい形で残していると問題解決に役立つ可能性が高いです。
1変更1コミットを心がける
1コミットに複数の変更を含めてしまうと、それぞれの差分が何のためのものか判断するのに時間がかかります。
例えば、Rails アップデートでは DEPRECATION WARNING を解決する必要があります。
多くの場合、複数種類の WARNING が発生しますが、これらの対応を1つのコミットにまとめてしまうと、どの WARNING に対する修正なのかを判断するのが難しいです。
1つのコミットには1つの WARNING 対応だけを含めるのが良いと思いました。
「なぜ」変更したのかを残す
コミットメッセージや pull request に「なぜ」変更したのかを残すのはとても重要です。 通常の開発(機能追加/修正 等)の場合は、システムの動作を変更する目的が分かっているので、ある程度メッセージを省略しても何をしたいのかは分かります。 Railsアップデートでは、システムに新しい動作をさせるために修正するのではなく、現状の動作を維持するために修正を行います。 そのため、変更した理由を残していないと「なぜ」この修正が必要なのかが分かりません。
こちらも例として DEPRECATION WARNING で見てみます。
DEPRECATION WARNING: update_attributes! is deprecated and will be removed from Rails 6.1 (please, use update! instead)
この WARNING に対して update_attributes! を update! に変更するという対応を行ったとします。
- user.update_attributes!(name: 'AAA') + user.update!(name: 'AAA')
この対応のコミットメッセージに「WARNING 対応」とだけ残した場合、この diff とコミットメッセージから変更が妥当なのかどうか判断するのは難しいです。
修正を行った本人は DEPRECATION WARNING として表示されたメッセージを確認していますが、それ以外の人はこのメッセージを確認していません。
そのため、コードの差分とアップグレードガイドやリリースノートの内容から、何のための修正なのかを判断しないといけなくなります。
DEPRECATION WARNING の対応であれば、個人的にはコミットメッセージに WARNING で表示された内容をそのまま残すのが良いと考えています。
update_attributes! は Rails 6.1 で使用できなくなるので update! に変更する DEPRECATION WARNING: update_attributes! is deprecated and will be removed from Rails 6.1 (please, use update! instead)
今回のように修正方法まで表示してくれているような簡単なものであれば、コミットメッセージにそのままそれを残すだけというのも良いと思います。
git commit -m 'DEPRECATION WARNING: update_attributes! is deprecated and will be removed from Rails 6.1 (please, use update! instead)'
難しい問題の場合、内容を理解した上で修正するということができないこともあります。 そのような時には「理解はできていないけど、この修正をいれておく」というようなことを残すのも大切です。作業時に理解できなかったとしても後から見直した場合や他のメンバーは理解できる可能性があります。 このようなメッセージが残っていない場合は、元の修正に何か理由があるかどうかの判断ができず、より良い修正方法が見つかったとしても現状維持としてしまうかもしれません。 メッセージが残っていれば修正しても大丈夫と判断できるのでシステムが改善される可能性が高くなります。
config を整理する
個人的にはRailsアップデートにおいてconfigの対応が一番難しいと思っています。 仮に間違っていても動作自体はするので気づかないまま時間が経ってしまう、ということもありそうです。 そのため、configの変更についても先に述べたように変更理由を残すのが大切です。
デフォルトを使用する
長年管理しているコードの場合、本来不要になっているにもかかわらず残り続けているコードが存在します。 configについても例外ではなく「機能は削除したけどconfigは消し忘れた」「旧バージョンでは必要な記述だったが今は不要になった」というようなコードが残っていることがあります。 できるだけデフォルトの値を使用しつつ必要なものだけ変更する、という形にしておくと今後のバージョンアップ作業でも考えることが減るのかなと思います。
これから
無事Ruby/Railsアップデートプロジェクトを完了することができました。 ただ、最新まで上げることはできていませんし、今後も新しいバージョンがリリースされていきます。 これからも定期的なアップデートを行っていけると良いなと思っています！
ユニファでは一緒に働いてくれる仲間を募集しています。
詳細はこちらからご確認ください。
