Недавно мы перенесли почти весь исходный код моей компании в одно решение.
Почему?
Первоначально у нас были десятки решений. Некоторые проекты из решения повторно использовали проекты из другого, и никто не заботился об использовании менеджера пакетов. В тот день, когда вы существенно измените проект, который используется практически везде, ожидайте часы и часы потерянной работы для всей компании в течение следующих дней или недель. Хуже всего то, что вы даже не можете знать, что именно повлияет на изменение.
Объединение всего кода в одно решение было альтернативой. На данный момент это работает хорошо, и теперь легко понять зависимости. Хотите изменить метод, но также отследить последствия, которые это изменение может иметь где-либо в базе кода? Visual Studio может сделать это с легкостью. Для меня это успех.
Непрерывная интеграция теперь также стала проще. Одно решение для компиляции и развертывания. Почти нечего настраивать.
Это масштабируемое?
Что касается производительности, я был очень удивлен Visual Studio . Я думал, что он начнет плакать с решением, скажем, 50 проектов. На сегодняшний день существует более 200 проектов; Visual Studio оказался достаточно масштабируемым для управления ими, как будто их было всего 20. Да, есть вещи, которые требуют времени. Если вы перекомпилируете каждый проект с контрактами кода, включенным по умолчанию анализом кода и т. Д., Ожидайте, что это займет некоторое время. Но никто не ожидал бы, что скомпилирует 200 проектов так быстро, как 10, и, кстати, вы не должны: это роль сервера непрерывной интеграции. Время запуска (холодный запуск, затем загрузка раствора) очень быстро ; может быть, не так быстро, как с 10 проектами, но все же очень приемлемо (менее 20 секунд на машине, купленной более пяти лет назад).
Чтобы пойти еще дальше, систематически разгрузки проектов является хорошей идеей (и действительно простой, когда проекты организованы в каталогах внутри решения). Если кто-то работает над чем-то, что требует загрузки только трех проектов, нет необходимости загружать все 200 проектов (если, конечно, не могут быть затронуты зависимости).
Контроль версий также работает, как и ожидалось (я использую сервер SVN, если это имеет значение). Я не работал в реальной параллельной среде, скажем, с десятками разработчиков, которые часто пишут код, но я бы предположил, что у этого не будет слишком много проблем. Просто остерегайтесь случаев, когда многие разработчики добавляют новые проекты одновременно: объединить файл .sln не так просто.
Вывод
Если бы мне пришлось выбирать решение снова:
Я все равно перенесу все в одно решение. Это значительно уменьшает боль от сломанных зависимостей, и одно только это преимущество того стоит. Наличие централизованного места для всего кода также хорошая идея; это позволяет, например, искать что-то в Visual Studio. Я также могу работать над двумя слабо связанными проектами, и у меня по-прежнему открыто только одно окно Visual Studio.
Я также хотел бы изучить немного больше NuGet и возможность размещения частного сервера NuGet. Управление зависимостями с помощью NuGet может решить некоторые проблемы, когда вы не хотите объединять несколько проектов в общее решение. Лично у меня не было таких случаев, но я предполагаю, что другие компании могли иметь.
Наконец, инвестирование в SSD для каждого разработчика может иметь огромное значение. Но вам не нужно, и в моем случае кодовая база все еще хранится на обычном жестком диске.