パッケージソフトウェアのバージョニングの苦しみの話

私が勤めていた会社の中には、お客様環境のWebアプリケーションのバージョンについて、「リリースタイミング、リリースバージョンをユーザー側が決められる」というようにしていたものがありました。 顧客が指定するバージョンが動作するアプリケーションコンテナに振り分けて実現しているだけですが、そのソースコード達のメンテナンスはなかなか苦しかった思い出です。

結局、「お客様にバージョンアップを委ねる」というのは、「特に欲しい機能がないのでバージョンアップを見送る」というのが保守的な発想になります。 企業向けとかだと、RPAをしっかり組んでしまっているみたいな話もあって、全ユーザーに新バージョンに追従してもらうというのができませんでした。

ということで、当時、複数のバージョンを同時並行的に管理していました。 1.0 -> 1.1 -> 1.2 -> 1.3 みたいに。それぞれのバージョンに　1　以上ユーザーがいる感じです。

さて、バグが発見されるとですね、そのパッチバージョンを作るのですが、それを上位バージョン側にどんどん連れてかなければいけませんでした。1.0 で不具合が見つかって、不具合修正コミットを作ったら、それを 1.1へマージして、1.2へマージして、1.3 へマージして、と手動でやっておりました。ひたすらコンフリクトを解消する日々でした。

もちろん上位バージョンは機能改修しているので、修正内容によっては、それが適合されるべき適切な行への移行だの、機能改修に適合した形でのパッチを即席で作ってマージだのしてました。 なかなか厄介なもので、「パッチの上位への展開を理由とした不具合」も幾らかあったと思います。

これ、いまだに何が正解かわかっていないのですが、何かWebアプリケーションなりパッケージを1から作っていいですってなったら、「常に最新バージョンを利用してもらう」は徹底するだろうと思います。

Gerrit とか、Phabricator といったコード管理ソリューション(?) がやるように、一つの統合ブランチと短命の派生ブランチだけを持つのが幸せなのかなと思いながら、 今日、改めてブランチ戦略を考えるってことになって調べているうちに、これに近いものが Trunk-based (トランクベース) 開発と呼ばれていることを知りました。

CI/CD用のプラットフォームも大体整っている今、gitflow ではなく Trunk-based な開発の方が良いところもあるのか？などと、何か小さなチームなりで検証したいなぁと思うところです。

以上！