Jak zorganizować wiele nakładających się rozwiązań / projektów w .Net?

Niedawno zacząłem pracować dla nowego klienta ze starą bazą kodu, w której istnieje wiele rozwiązań .net, z których każdy zazwyczaj obsługuje niektóre projekty unikalne dla tego rozwiązania, ale potem „pożycza” / „łączy” (dodaj istniejący projekt) kilka innych projektów który technicznie należy do innych rozwiązań (przynajmniej jeśli chodzi o strukturę folderów w TFS)

Nigdy nie widziałem tak splecionej konfiguracji, nie ma jasnej kolejności kompilacji, czasami projekt w rozwiązaniu A po prostu odwołuje się do bibliotek dll bezpośrednio z katalogu wyjściowego projektu hostowanego w rozwiązaniu B, czasami projekt został właśnie dołączony bezpośrednio, nawet jeśli rezyduje DALEKO w strukturze folderów.

Wygląda na to, że wszystko zostało zoptymalizowane pod kątem lenistwa programistów.

Kiedy stanąłem przed nimi z pytaniem, dlaczego nie mają serwera CI, odpowiedzieli, że trudno jest skonfigurować kod w takiej formie. (Teraz konfiguruję i przeklinam tę organizację kodu)

Rozwiązania są zorganizowane wokół artefaktów wdrażania (rzeczy, które muszą zostać wdrożone razem, są w tym samym rozwiązaniu), co moim zdaniem jest mądrą decyzją, ale zawartość tych rozwiązań (projektów) jest wszędzie.

Czy istnieje zgoda co do najlepszych praktyk, które należy zastosować przy ponownym użyciu bibliotek klas wspólnych w wielu rozwiązaniach / artefaktach wdrażania,

• Jak ustrukturyzować kod w VCS
• Jak ułatwić współużytkowanie logiki biznesowej między oddzielnymi artefaktami wdrażania

Nigdy nie byłem fanem włączania istniejących projektów, które należą do innych rozwiązań. Istnieje zbyt wiele zmiennych, w których dokonanie edycji tego projektu dla 1 rozwiązania całkowicie psuje coś w innym rozwiązaniu. Następnie, rozwiązując ten problem, ostatecznie łamiesz oryginalne rozwiązanie. Spłucz, spłucz, powtórz.

Gdy tego rodzaju zależność przenika do wielu rozwiązań, lubię rozdzielać zależny kod na jego WŁASNE rozwiązanie i tworzyć bibliotekę czarnych skrzynek, która jest następnie dołączana jako odniesienie. Myślę, że twoje rozwiązania były ze sobą powiązane, dzięki czemu można było debugować całą drogę do wspólnego projektu dla każdego rozwiązania. Jeśli biblioteka jest poprawnie zbudowana i przetestowana, tego rodzaju debugowanie naprawdę nie jest konieczne. Biblioteka powinna być w stanie oprzeć się na własnych zaletach i powinna zostać gruntownie przetestowana, aby konsekwentnie spełniać oczekiwania każdego projektu konsumenckiego.

Właściwie zorganizowałem takie struktury TFS, jak ta, o której wspominasz, i chociaż stanowi on dla CI wyjątkowe wyzwania, ma wiele różnych zalet. Jednym z nich jest to, że obsługuje i zachęca do właściwej komponentizacji w oddzielne projekty .NET, a tym samym wspiera dobre TDD, zachęcając do 100% pokrycia testowego. Od razu zauważam kilka problemów, które możesz rozwiązać.

czasami projekt w rozwiązaniu A po prostu odwołuje się do bibliotek DLL bezpośrednio z katalogu wyjściowego projektu hostowanego w rozwiązaniu B, czasami projekt został właśnie dołączony bezpośrednio, nawet jeśli znajduje się on daleko w strukturze folderów.

Binarne odniesienia do danych wyjściowych innych katalogów nie są dobrym podejściem i stają się złym podejściem, gdy są połączone z odwołaniami do projektu. Spróbuj wykonać jedno lub drugie, najlepiej zmieniając odniesienia binarne na odwołania projektu, co najmniej dla zachowania spójności. W tym momencie każde rozwiązanie może reprezentować pojedynczą aplikację lub warstwę aplikacji do zbudowania (np. SuperApp.sln, OtherAppServices.sln, OtherAppPresentationTier.sln).

Aby zbudować WSZYSTKIE projekty, zalecam również stworzenie rozwiązania głównego. Rozwiązanie główne będzie zawierało odwołania do projektu do wszystkiego i zasadniczo istnieje tylko dla pojedynczej komendy kompilacji, która obsługuje wszystkie projekty w pakiecie aplikacji. Programiści nie powinni używać rozwiązania głównego do aktywnego programowania lub debugowania. Ułatwia to składanie artefaktów kompilacji.

Wdrożenie można wtedy wykonać za pomocą prostego skryptu wsadowego, PowerShell lub Perl. To zasadniczo zbuduje odpowiednie rozwiązanie lub rozwiązanie główne, a następnie wdroży wszystko w odpowiednich środowiskach. Można to łatwo zintegrować z dowolnym serwerem CI, jeśli zostanie to wykonane poprawnie.

• Jak ułatwić współużytkowanie logiki biznesowej między oddzielnymi artefaktami wdrażania

Utwórz projekt dla wspólnej logiki biznesowej lub lepiej rozdziel obawy dotyczące bardziej globalnej lub uniwersalnej logiki biznesowej. Wszystkie rozwiązania, które można wdrożyć, powinny się do tego odwoływać poprzez odniesienie do projektu.

Organizując kod w TFS, łatwiej jest to osiągnąć, utrzymując wspólne lub wspólne projekty na wyższym poziomie w drzewie katalogów.