Нещодавно ми перенесли майже весь вихідний код моєї компанії в єдине рішення.
Чому?
Спочатку у нас було десятки рішень. Деякі проекти з рішення повторно використовували проекти з іншого, і ніхто не піклувався про використання менеджера пакунків. У день, коли ви істотно зміните проект, який використовується майже скрізь, очікуйте годин та годин втраченої роботи для всієї компанії протягом наступних днів чи тижнів. Найгірше, що ви навіть не можете знати, що саме вплине на зміну.
Об’єднання всього коду в одне рішення було альтернативою. Наразі це добре працює, і залежність тепер легко простежити. Хочете змінити метод, але також відстежити наслідки, які ця зміна може мати в будь-якій точці бази коду? Visual Studio може це зробити легко. Для мене це успіх.
Безперервна інтеграція тепер також простіша. Одне рішення для компіляції та розгортання. Налаштовувати майже нічого.
Чи масштабований?
Виконання продуктивності мене дуже здивувало Visual Studio . Я думав, що він почне плакати за рішенням, скажімо, з 50 проектів. Сьогодні існує понад 200 проектів; Візуальна студія виявилася достатньо масштабованою, щоб керувати ними так, ніби їх було лише 20. Так, є речі, на які потрібен час. Якщо ви перекомпілюєте кожен проект із контрактами Code, аналіз коду, включений за замовчуванням тощо, очікуйте, що це займе певний час. Але ніхто не сподівався скласти 200 проектів так швидко, як 10, і, до речі, не варто: це роль сервера безперервної інтеграції. Час запуску (холодний старт, потім завантаження розчину) вражаюче швидкий ; можливо, не так швидко, як з 10 проектами, але все-таки дуже прийнятно (менше 20 секунд на машині, купленій більше п'яти років тому).
Щоб піти далі, систематична розвантаження проектів - хороша ідея (і це дуже просто, коли проекти організовуються в каталогах у рамках рішення). Якщо хтось працює над тим, що вимагає завантаження лише трьох проектів, немає необхідності завантажувати всі 200 проектів (якщо, звичайно, залежність може не вплинути).
Контроль версій працює також, як і очікувалося (я використовую SVN-сервер, якщо це має значення). Я не працював у реальному одночасному середовищі, де, скажімо, десятки розробників часто здійснюють код, але я думаю, що це не матиме надто багато проблем. Тільки остерігайтеся випадків, коли багато розробників одночасно додають нові проекти: об’єднання файлу .sln - це не найпростіша річ.
Висновок
Якщо мені доведеться вибрати рішення ще раз:
Я все одно мігрував би все в єдине рішення. Це надзвичайно скорочує біль від розбитих залежностей, і лише ця вигода цілком варта того. Мати централізоване місце для всіх кодів - це також хороша ідея; це дає можливість, наприклад, шукати щось у Visual Studio. Я також можу працювати над двома слабо пов'язаними проектами, і все ще відкриваю лише одне вікно Visual Studio.
Я також вивчив би більше NuGet та можливість розміщення приватного сервера NuGet. Управління залежностями через NuGet може вирішити деякі проблеми, коли ви не хочете об'єднати кілька проектів у загальне рішення. Особисто у мене таких випадків не було, але я гадаю, що могли мати інші компанії.
Нарешті, вкладення коштів у SSD для кожного розробника може внести величезні значення. Але вам не потрібно, і в моєму випадку база коду все ще зберігається на звичайному жорсткому диску.