EoLから逃げることは大切です。
誰？
nana
Gyazoのバックエンドを普段は書いています。
Gyazoはユーザに見えるところではRailsを、画像の配信サーバにgoを使っています。
最初に
手を挙げてね。
普段コードを書いてる人
普段Rubyを書いてる人
普段書いてるRuby version
3.2+
3.1.x(EoL: 2025/03/31)
3.0.x(EoL: 2024/03/31)
2.x (EoL: 2023/03/31)
まぁそんなもんですよね。
そんなもんじゃなかったらすごい。いいこと。
EoL?
End of Lifeの略。
ここではその処理系、ライブラリについて、更新が来なくなる時期 ぐらい。
越えてしまってもその瞬間に直ちに問題のある日付というわけではないが、その日付以降はセキュリティアップデートなどが公開されなくなるので、バージョンを上げるか、使うのをやめるほうがよい。
今日はこれだけ覚えてかえってください。
ライブラリのアップデートからは逃げられない。
今年の頭はGyazoのバックエンドのRubyバージョンを上げていました。
GyazoのRubyは2.7.6だった。
Rubyの2.7系のEoLは今年の3月末。
ちゃんと上げていなかったがために面倒なことに……。
3系に行く素振りのために2.7.7に上げる。
https://gyazo.com/11f30932d9d8801c0c7978ae07a1b87b
出たのはクリスマスじゃなくて2022/11/24だった。
テストが壊れまくる！
https://gyazo.com/38698c5702e08ffd8149ebaf78d71db5
https://gyazo.com/0341f4fb375fa34e3a0c0577d540e4bb
masterでは直ってる(3.2.0以降には含まれている)ので、3ヶ月後にEoLを迎えるようなバージョンを使い続けていると不幸に会ったりする。
11/24に出て、次の3/31に終わるのに使う人はどれぐらいいるんだ？
目が少ないから、踏むこともある。
はやく上げていなかったばっかりに……。
(これは若干言いすぎで、cgiが0.3.6未満だと3.0、3.1とかでもaffectedであったのではないか？ という気はする)
ソフトウェアは放置していくと上げるのも大変になっていく。
いよいよRubyを3.0に上げるぞ → keyword args(kwargs)であらゆるところが壊れる。
おいおいkwargsの破壊的変更が入った3.0が出たのは2020年のクリスマスだぞ。
しかも2019年には予告されている。
code:kwargs.rb
def f(x: 42); x; end # キーワード引数としてxのみを取る関数
opt = { x: 108130958085102 }
# f(x) #=> wrong number of arguments (given 1, expected 0) (ArgumentError) # 3.0以降 f(**x) #=> 108130958085102 # 今はこう書かないといけない。 自分のアプリの中で壊れてる分は直せばよいだけ。
100箇所ぐらいあったけど、testで気付けるのでそんなに大変じゃない。
f(opt)形式で書かれていた古いコードに f(**opt)とexpandの**つけて回るだけ。
ライブラリの中で使われてる分は直せないので、つまりそのライブラリも上げる必要がある。
https://gyazo.com/177d6e98fbea1ce271ed97e855eb42cc
2020年中には直ってる問題にどうして3年越しに踏むんですか？
そもそもライブラリのアップデートをサボっていたツケを支払っている。
ライブラリ、処理系アップデートの戦略
我々の持つ選択肢は少ない。
アップデートしない。
デモアプリ、動作検証のアプリとかそういうのだったらよい。
サービス終了する日が决まってる物とかなら逃げ切りもなくはないかも。
なんかのイベントのためのアプリとかだったらそういうこともあるかも。
(ほんとうに以降使いませんか？)
アップデートする。
いつする？
まとめてやる
日々やる
まとめてやる
無理では？
できるんだったらよいのか……？
従来型のリリースが年1とかのアプリなら行けるかもしれない。
日々やる
我々が普段書いてるローリングリリースなプロダクトのコードとかだと結局これしかないよね。
というか、これが一番楽だよね。
今回は溜めまくってしまってたから大変だった。
どうやって日々やる？
Gyazoチームではrenovateを使っていくことに。
本質的ではなさそうなgemとかだと「testが通ってたらヨシ！」で上げていく みたいな合意が取れてきた。
それでダメだったとしたら、問題だったのは上げたことではなく、testが足りていなかったということ で……。
実際に上げて爆発することはほぼ無く、testの段階でほぼ非互換があった場合には気付けている。
今まではnpmのほうでしか使っていなかったが、これを機にgemなどでも使うように拡大した。
溜めずにどんどん上げていこうな。
アップデートからは逃げられない。
たしかにアップデートの作業自体はユーザに新しい価値をお届けできるわけじゃない。
かと言って、やらないとどんどんプロダクトのコードが廃墟になっていく。
歯をくいしばって、周りの人々に「これは必要なことだ」と説明して、やっていくしかない。
がんばりましょう。
まとめ
アップデートからは逃げられない！！
EoLから逃げる とか目標の低いことを言っていないで、日々自然に上げていくことで余裕を持って更新していけるといいですね。
---