Czy rozwiązanie z setkami projektów jest niebezpieczne lub po prostu nieporęczne?

Question

nasze główne rozwiązanie klienckie ma 111 projektów. Kiedy zaczynałem pracę w tym zespole, byłem zaskoczony (i zaniepokojony), że mieliśmy tak wiele projektów i zaleciliśmy konsolidację poziomów w mniejszych, ale większych zespołach. nasza struktura ma modele (DTO) z plikami mapowania nhibernate i warstwy usług WCF z kontrolerami danych, niektórymi projektami typu framework i aplikacją CAB z wieloma modułami. będziemy używać wdrożenia typu "kliknij raz".

ze względu na czas budowy (do 15 minut najgorszego przypadku), dotyczy to również niektórych innych członków zespołu. Nie mam empirycznych dowodów na to, że mniej projektów to dobry pomysł i zastanawiałem się, czy społeczność przepełnienia stosu ma jakieś uwagi. Czy istnieją ważne powody, aby zmieniać strukturę naszych rozwiązań w celu konsolidacji projektów? czy będziemy mieć problemy z wdrożeniem ponad 100 zespołów za pomocą jednego kliknięcia? Czy więcej złożeń powoduje spowolnienie podczas ładowania i wywoływania wywołań metod? Jakiekolwiek ograniczenia, które moglibyśmy napotkać, mogą zniszczyć rzeczy?

Answer 1

Największym problemem związanym z posiadaniem wielu projektów w ramach jednego rozwiązania (w szczególności gdy istnieje wiele współzależności między projektami) jest to, że czas kompilacji spowolni się naprawdę szybko. Widziałem, że czasy kompilacji idą od kilku minut do kilkudziesięciu minut, kiedy liczba projektów rośnie tak duża.

Uruchomienie aplikacji może również ucierpieć, jeśli trzeba złożyć i zainicjować 100 złożeń. Zakłada to oczywiście, że wszystkie 100 złożeń jest wymaganych przez aplikację.

Tak duża liczba projektów wskazuje również na problemy z organizacją kodu. Nazwałbym to wyraźnym zapachem kodu. Wygląda to na próbę oddzielenia się od tego, co wykracza poza rozsądne - trochę architektonicznego astronautyki, na domysły.

Nie martwię się o historię wdrożenia, ponieważ rozmieszczenie jednego zestawu w katalogu nie różni się zbytnio od rozmieszczania 100 w jednym katalogu ... Oczywiście rozmieszczanie 100 złożeń za pośrednictwem sieci będzie wolniejsze (100 połączeń zamiast 1, prawdopodobnie mają większy rozmiar ...).

Istnieją narzędzia, które scalą wiele złożeń, które mogą w tym pomóc - najlepiej znane z Microsoft - ILMerge.

Większy problem, o który trzeba się martwić, kiedy przychodzi do wdrożenia, jest w konfiguracji i poprawny, zwłaszcza jeśli większość złożeń wymaga własnej konfiguracji.

Answer 2

Nie sądzę, że pojawią się jakiekolwiek problemy, gdy wszystko zostanie skompilowane i zrobione.

W związku z tym, z własnego doświadczenia wiem, że wiele projektów może zabić Twoją wydajność. Na mojej (średniej mocy) maszynie, przy wielu projektach w rozwiązaniu, wystarczy załadować studio graficzne. Ponadto, gdy kompilacja twojego przepływu pracy zajmie prawie kwadrans, a koncentracja zostanie przerwana (nawet bardziej, jeśli zdecydujesz się zrobić coś innego podczas oczekiwania).

Answer 3

In a gist: Wdrożenie będzie najmniej z twoich zmartwień.

Prawdziwymi problemami, z jakimi borykamy się poza dłuższym czasem kompilacji, są: >> prawdopodobna nieefektywność i mniejsza produktywność programistów.

W zależności od rodzaju zautomatyzowanej konfiguracji kompilacji masz ... awarię w dyskretnym zestawie rozwiązań w tych samych projektach w połączeniu z częstymi kontrolami w czołówce deweloperów ... są zobowiązani dać ci (jeśli jeszcze nie) seria koszmarnych niepowodzeń w budowaniu.

Oto co można zrobić, aby złagodzić:

1. podstawie poziomu uzależnienia Możesz zebrać z projektów najmniej utrzymaniu. Na przykład, jeśli projekt A ma najmniejszą liczbę rezygnacji z kodu ... warto go oddzielić za pomocą automatycznego odwołania do zespołu ... w zależności od używanego rozwiązania kompilacji.

2. Ponadto, trywialna wskazówka, Devs może po prostu wczytać projekty, w których pracują, co przyspieszy i przyspieszy uruchomienie.

3. Jeśli masz konfigurację wdrożenia wielojęzykowego, jak: DEV, UAT, STAGE, MIRROR i PROD .. prawidłowe konfigurowanie konfiguracji za każdym razem będzie również królewskim bólem. Tak więc możesz przenieść wszystkie nietrywialne konfiguracje na poziom DB ... i zachować czystsze pliki konfiguracyjne ... używając ich tylko dla absolutnie koniecznych elementów.

Answer 4

Możliwe jest, że korzyści, które chce osoba, która zdecydowała się stworzyć 110 projektów, można osiągnąć dzięki 110 przestrzeniom nazw w jednym .dll.

Duża liczba dll sprawia, że ​​staje się bardziej oczywiste, gdy zależności zaczynają pełzać (1 dll odnosi się do 22 innych), ale to samo dotyczy przestrzeni nazw (jeśli nie masz instrukcji użycia, to jest wbudowane zniechęcenie odwołać wiele innych nazw.

również podczas scalania zespołów, można stracić „wewnętrzny”, a może chcesz, aby niektóre metody mniej widoczne niż były, co jest dobrą rzeczą, byle jak.