はじめに
前回は独自ライブラリをチーム開発で配布するにあたって、dllファイルを直接配布する方法の問題点を明らかにし、その問題に対してNuGetを活用して対応する方法について紹介しました。NuGetを使うと「ソリューションごとにライブラリ参照先を独立して持てる」ようになることが、様々な問題の解決につながるのでしたね。
チーム開発において、ライブラリの配布と同じくらい大変なのが、ライブラリの変更です。多くのモジュールから参照されているライブラリであればあるほど、ライブラリに変更が発生した場合、その影響は甚大です。
前述のNuGetの特徴を活用すると、こういったライブラリ変更にも柔軟に対応できるようになります。今回はライブラリ変更について、実例を挙げて対応方法を紹介していきます。
ケース1：ライブラリの破壊的変更に順次対応する
システム開発を進めていく中では、ライブラリの変更も随時行われます。その変更の中には内部的な構造、動作の変更もあれば、外部に影響のあるAPI（アプリケーション・プログラミング・インターフェース）の変更などもあります。特に後者の外部に影響のある変更は、特に注意が必要です。
まず最初は、dllファイルを直接配布して、共通のライブラリを複数の機能で参照しているケースを考えてみましょう（図1）。
このとき、ライブラリのAPIに後方互換性のない、いわゆる「破壊的変更」が加えられたとします。
dll直接配布の問題点
破壊的変更が加えらえれたdllファイルを直接配布する場合、起きうる問題は次の通りです。
1) すべての参照機能でビルドエラーが起きる
すべての機能は単一のdllファイルを参照しています。したがって、dllファイルが置き換えられると、そのdllファイルを参照していた機能すべてでビルドエラーが発生します。例ではMyLib.dllを参照していたMyApp1、MyApp2の両方でビルドエラーが発生してしまいます（図2）。
2) ライブラリ変更対応を一度に行わなければならない
1)でビルドエラーのある状態では、VCS（バージョン管理システム）にコミットしてしまうと、他のメンバーに迷惑がかかってしまいます。そのため、ライブラリの変更と共に、MyApp1、MyApp2の両方にも変更を加え、一度にコミットしなければなりません（図3）。
この方法は、ライブラリを参照している機能が少ない場合はそれほど問題にならないかもしれません。しかし、そのライブラリが基盤を支えるようなものだと、参照している機能が非常に多くなることもあります。参照している機能が多ければ多いほど、修正にも時間がかかりますが、それらの変更はすべて一度にコミットしないといけません。
こういった対応を多くの他のメンバーの作業と並行して行うことは難しいです。そのため、他のメンバーには作業を止めてもらうか、夜間、早朝などの時間を選んで、限られた人数の担当者がライブラリ変更に伴う変更作業をすべて担当する必要があります。
もちろん、VCSの機能の一つである「ブランチ」を活用すれば、他のメンバーには影響を与えずに個別に作業を進めることはできます（図4）。しかし、特定の担当者の負担が大きいことは変わりません。
