Niedawno przenieśliśmy prawie cały kod źródłowy w mojej firmie do jednego rozwiązania.
Dlaczego?
Początkowo mieliśmy dziesiątki rozwiązań. Niektóre projekty z rozwiązania wykorzystywały ponownie projekty z innego i nikt nie dbał o użycie menedżera pakietów. W dniu, w którym znacząco zmienisz projekt, który jest używany prawie wszędzie, spodziewaj się godzin straconej pracy dla całej firmy na następne dni lub tygodnie. Najgorsze jest to, że nie możesz nawet wiedzieć, na co dokładnie miałaby wpływ zmiana.
Scalenie całego kodu w jedno rozwiązanie było alternatywą. Na razie działa dobrze, a zależności są teraz łatwe do naśladowania. Chcesz zmodyfikować metodę, ale także śledzić następstwa, jakie ta zmiana może mieć w dowolnym miejscu w bazie kodu? Visual Studio może to zrobić z łatwością. Dla mnie to sukces.
Ciągła integracja jest teraz również łatwiejsza. Jedno rozwiązanie do kompilacji i wdrożenia. Prawie nic do skonfigurowania.
Czy to jest skalowalne?
Pod względem wydajności byłem bardzo zaskoczony Visual Studio . Myślałem, że zacznie płakać z rozwiązaniem, powiedzmy, 50 projektami. Obecnie istnieje ponad 200 projektów; Visual Studio wydawało się być wystarczająco skalowalne, aby zarządzać nimi tak, jakby było ich tylko 20. Tak, są rzeczy, które wymagają czasu. Jeśli ponownie skompilujesz każdy projekt, z umowami Kod, domyślnie włączoną analizą kodu itp., Spodziewaj się, że zajmie to trochę czasu. Ale nikt nie spodziewałby się, że skompiluje 200 projektów tak szybko, jak 10, a swoją drogą nie powinieneś: taka jest rola serwera ciągłej integracji. Czas uruchamiania (zimny start, a następnie ładowanie rozwiązania) jest imponująco szybki ; może nie tak szybki jak w przypadku 10 projektów, ale wciąż bardzo akceptowalny (poniżej 20 sekund na maszynie kupionej ponad pięć lat temu).
Idąc dalej, systematyczne rozładowywanie projektów jest dobrym pomysłem (i naprawdę łatwe, gdy projekty są zorganizowane w katalogach w ramach rozwiązania). Jeśli ktoś pracuje nad czymś, co wymaga załadowania tylko trzech projektów, nie trzeba ładować wszystkich 200 projektów (chyba że oczywiście może to mieć wpływ na zależności).
Kontrola wersji działa również zgodnie z oczekiwaniami (używam serwera SVN, jeśli ma to znaczenie). Nie pracowałem w prawdziwym środowisku współbieżnym, powiedzmy, z dziesiątkami programistów często popełniających kod, ale wyobrażam sobie, że nie miałoby to zbyt wielu problemów. Uważaj tylko na przypadki, w których wielu programistów dodaje nowe projekty w tym samym czasie: scalenie pliku .sln nie jest najłatwiejsze.
Wniosek
Gdybym musiał ponownie wybrać decyzję:
Nadal migrowałbym wszystko do jednego rozwiązania. To ogromnie zmniejsza ból zerwanych zależności, a sama ta korzyść jest całkowicie tego warta. Dobrym pomysłem jest także scentralizowane miejsce na cały kod; umożliwia to na przykład wyszukiwanie czegoś w Visual Studio. Mogę także pracować nad dwoma słabo powiązanymi projektami i nadal mam otwarte tylko jedno okno Visual Studio.
Chciałbym również przestudiować nieco więcej NuGet i możliwość hostowania prywatnego serwera NuGet. Zarządzanie zależnościami za pomocą NuGet może rozwiązać niektóre problemy, gdy nie chcesz scalić kilku projektów w jedno wspólne rozwiązanie. Osobiście nie miałem takich przypadków, ale wyobrażam sobie, że inne firmy mogą to mieć.
Wreszcie, inwestycja w dysk SSD dla każdego programisty może mieć ogromną różnicę. Ale nie musisz, aw moim przypadku baza kodu jest nadal przechowywana na zwykłym dysku twardym.