今すぐ実践したいバージョン管理のtips

CARTA TECH BLOG アドベントカレンダー 12月15日分の投稿です。

みなさんこんにちは、サポーターズの @y_chu5 （ちゅうこ）です。普段はTypeScriptでWebフロント、ScalaでAPIサーバーのコードを書いたり、CIを整備しています。

さて、みなさんはこんな経験はないでしょうか。

『cloneして動かそうとしたらビルドが通らない』、『何もしてないのにテストが落ちるようになった』、『キャッシュ消したらアプリが壊れた』…

この記事では、OSSを使う側、作る側両方に立ってみて見えたバージョン固定の重要さを少しお話したいと思います。

これからお話する内容は、例えば言語だったり、また対象がライブラリやアプリケーション、CI設定やDockerfileなどに性質は違うにしろ、ある程度共通している内容となっています。この記事の考えと、各ベストプラクティスを組み合わせていい感じにしてもらえたらなと思います。

前提としてはテストがあってCI(Continuous Integration)を回していることが前提の記事です。

はじめにまとめを…

緩すぎるバージョン指定で生殺与奪の権を他人に握らせるな

依存先の最新情報をキャッチアップしてバージョンを定期的に上げていこう

例えばライブラリやDocker Image、CIのOSなど

CIではlatestでもビルドできてると最高

固定運用とlatest運用両方あるともっと最高

バージョンを固定しないことで起きる問題

この令和の時代、バージョン固定が出来ない環境は限られているので、意識せずともバージョン指定をもちろん行っているとは思いますが、以下のようなバージョン指定をしていないでしょうか？

例えば

>7 みたいな最低バージョン指定（これ正しくはなんて言うんでしょうかね、識者教えて下さい）
latest固定

この指定は開発者視点に立ってみると、非常にリスクのある指定であると考えられます。

最低バージョン指定の記載の場合を考えてみます。

例えばマイナーバージョンやパッチバージョンでAPIや挙動が変わらない、なんていうのは誰が保証したでしょう。一応セマンティックバージョニングというものを信用するのであれば動作などは保たれるのでしょうが、正しく運用されている例をなかなか見ません。そういうこともあり、依存先がOSSのライブラリみたいな時は、急にインタフェースが変わっていた、動作が変わっていたなんでことザラにあります。また悪意のあるコードが新たに追加された場合、いつの間にかその影響を受けてしまうなんてことも考えられます。

ではlatestにした場合はどうでしょう。

これも最低バージョンと同じような影響を受けるのはもちろん、大規模な変更が加わるメジャーアップデートの影響も受けることがあるでしょう。今あなたが見ていたlatestは時間経過とともにlatestではなくなるのです。

この様に時間経過やアップデートのような外的要因から自分のソフトウェアが壊れることは、緩いバージョン指定では回避できていないことがわかります。

その影響はもちろん、使う側も受けることでしょう。使う側の動作が保証されていないのです。

ということで、本当に動作する環境のスナップショットを取る意味でも、バージョン固定を行うのが良さそうに思えます。