セマンティック・バージョニング、チームの依存関係のメモ

セマンティック バージョニングのルールについて、改めてメモ。
主張のないラフなメモ書き。

【参考】
セマンティック バージョニング 2.0.0 | Semantic Versioning

「セマンティック バージョニング」を読んだのでバージョニングについてまとめた - Qiita

t32k、怒られる！セマンティック バージョニングしてますか？ | HTML5Experts.jp

Ruby 2.1.0 以降のセマンティックバージョニングについて

【1】(引用開始)
バージョンナンバーは、メジャー.マイナー.パッチとし、バージョンを上げるには、

APIの変更に互換性のない場合はメジャーバージョンを、
後方互換性があり機能性を追加した場合はマイナーバージョンを、
後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。

プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチの形式を拡張する形で利用することができます。
(引用終了)

(引用開始)
例えばVersion 3.2.1の場合、メジャーバージョンは3、マイナーバージョンは2、パッチバージョンは1ということになります
(引用終了)

【2】ソフトウェアはハード製品とは違って、バージョンの依存性関係の管理がすごく重要だ。
特に、OSやミドルウェア、ライブラリのバージョンが違うだけですぐに動かなくなる。
また、バージョンアップの頻度も多いのが普通なので、ライブラリのバージョンアップを追随するのにも結構労力がかかる。

一方、バージョンアップしないライブラリは、進化していないので危険。
たとえば、最新のセキュリティパッチが考慮されていない場合もあると、すごく危険。

僕は、どの開発プロジェクトであっても、そこの構成管理の運用ルールをまずは見る。
ソース管理やビルド管理だけでなく、設計書の版管理はどのようにタグ付けされて、リリースバージョンとしてリリースされるのか？

構成管理はソフトウェア開発プロセスの基本であるが、意外に運用がまちまちだったりする。
今でも、リリース管理台帳というExcelで、リリースモジュールとバージョン番号を記録して、初めてリリースできる運用を行なっている所も多いのではないか。

すると、Excelのリリース管理台帳がロックされて書き込めない、リリース管理台帳が最新化されていない、リリース管理台帳そのものの履歴管理ができてないのでデグレした、とか、諸々の問題点が色々出てくる。

【3】また、バージョンのネーミングルールも重要だ。
メジャーバージョンとマイナーバージョンの違いを認識せずに、何となくナンバリングしていないか？

t32k、怒られる！セマンティック バージョニングしてますか？ | HTML5Experts.jpでも「『いっぱい変更したのでメジャーバージョン上げてみるか』、『今回の修正は軽微なものだし、マイナーバージョンを上げるか』」とバージョニングしていたら、ロシアのサンクトペテルブルク在住の青年エンジニアに怒られた、という内容があった。

(引用開始)
彼の言い分は、「APIを変更したので、この場合はSemantic Versioningのルールに従ってメジャーバージョンを上げるべきであり、そうすることでユーザーも予測・対応しやすい」とのことです。
(引用終了)

すごく参考になる。
セマンティック バージョニングによるバージョン番号によって、ユーザに影響箇所を認識させることができるメリットがあること。
数多くのOSSも、そういうバージョン番号になっている。

だが、単一のアプリではなく、数多くの共有ライブラリに依存した大規模システムになると、依存関係の管理が難しくなる。
一つの共通ライブラリのバージョンアップで、回帰テストの工数が増えるリスクもある。
Javaでは、Maven、Ivy、さらにはGradleを使っていたが、今はどうなのかな？

【4】依存関係については、ライブラリだけでなく、チーム間の依存関係の例もある。
100人月以上の大規模システムになると、複数のチームが連携するのが普通だが、他チームのライブラリや成果物に依存するために、開発が滞る時がある。
あるいは、インフラ基盤に依存する場合、アジャイルチームとWF型開発チームが混在している場合、などの例もあるだろう。

下記の記事がすごく分かりやすい。

スクラムで依存関係を取り扱う方法 | Ryuzee.com

【5】この記事を読みながら、「ドメイン駆動設計」のパターンを幾つか連想した。
普通は、依存しあう二つのチームには、権力や影響力の優劣が存在する。
では、力の優劣のあるチームの依存関係では、どんなパターンがあるのか？

「顧客・供給者の開発チーム」パターンなら、上流のチームに対し、下流のチームが顧客として振る舞う。
これが理想。
本来は、上流のチームが「公開ホストサービス」「公開された言語」パターンで、下流のチームが使えるようなAPIを準備して公開すべき。
昨今のマイクロサービスの流行は、この方向性だろう。

「順応者」パターンなら、下流のチームは上流のチームに従順に従うしか無い。
下流のチームにとっては最悪のパターンなので「腐敗防止層」パターンでガードしたり、「別々の道」パターンを採用する。
たとえば、レガシーシステムの開発チームが強い場合は、こうならざるを得ない場合が多いだろう。

セマンティックバージョン、ライブラリの依存関係、チームの依存関係については、既に数多くの知見やベストプラクティスがあるので、それをまとめると面白いかなと思う。