背景
担当プロジェクトで使用している「Ruby」のバージョンがサポート終了（EOL）となることを受けて、バージョンアップのやっていき方を検討してみたため、記録としてメモを残します。
当初は、「バージョンアップをしなかった場合に起こりえるセキュリティリスク」を全て洗い出して検討しようとしていたが、それはあまりにも壮大な話であったため、リスク対応と対応する工数のバランスについてを検討した。
今回の結論
EOLになるからと言ってバージョンアップをするのではなく、CVE（脆弱性情報）として公表されたものの中で対応が必要な場合に対応することとした。
（参考）cve.mitre.org
そのような脆弱性情報のほとんどは大きなニュースとして回ってくることが多く、かつ社内の担当部署から情報収集・展開がなされる運用も出来ているため、このような結論に至った。
理由
理想でいうと、マイナーバージョンの安定版が出るたびに小まめにバージョンアップをしていくのがセキュリティ面から言うと理想的ではあるが、工数がかかるため、開発速度は遅くなり、「本当に必要なこと」ではないことに工数を使うことにもなりかねない。
そこのバランスは非常に難しいが、「何か問題が起きてから」ではなく、「何か問題が起きる可能性があることが公表されてから」の対応が、今のプロジェクトとしてバランスが良いと判断した形となった。
こういうことが出来たら理想的
当該プロジェクトはDockerを使っており、Rubyのバージョンアップをしたい場合は、DockerImageの番号を書き替えてBuildし直すだけで出来る。
バージョンアップしたときに、自動的にテストを回すようにして、ワーニングの有無を確認して、本番にも適応する、というような運用が構築（できれば自動化）が出来ると、Dockerの便利さも活かしつつ、小まめなバージョンアップを工数を大きくかけずにやっていけるかもしれない。
ただ、自動テストの「カバレッジ100％」は難しいこともあると思うため、「どこまでは自動テストで見る、ここは自動テストでの対応は難しいので目視確認するようにする」などを、担当者間で合意しておくということでも対応はできそう。
バージョンアップをするときの注意点
- 「安定版（Stable）」のみを使用する
- マイナーバージョンアップは「1個ずつ」行う
- メジャーバージョンアップは大きな仕様変更の可能性があるため慎重に対応する
（参考）プログラム言語は常にバージョンアップしておいたほうが良い理由
以上です。