Zarządzanie wewnętrznymi zależnościami stron trzecich

Question

Mamy wiele różnych rozwiązań/projektów zarządzanych przez różne zespoły. Nasze rozwiązanie musi odwoływać się do kilku projektów, które posiada inny zespół. Nie chcemy dodawać tych zależności jako odniesień do projektu, ponieważ nie zamierzamy modyfikować tego kodu, chcemy go po prostu użyć. Również mamy już sporo projektów w naszym rozwiązaniu i nie chcemy dodawać więcej, ponieważ spowolni to działanie Visual Studio. Budujemy te projekty w osobnym rozwiązaniu i dodajemy je jako odniesienia do naszego rozwiązania.

Moje pytanie brzmi, w jaki sposób ludzie zarządzają tego typu zależnościami? Czy powinienem po prostu zautomatyzować proces, który szuka zmian w tych projektach, buduje je i sprawdza biblioteki dll w naszej kontroli kodu źródłowego, po czym traktujemy je tak, jak inne zewnętrzne zależności? Czy istnieje zalecany sposób robienia tego?

Answer 1

Jednym rozwiązaniem, choć niekoniecznie musi być to, czego szukasz, to sprawdzenie, czy każdy podukład zależny wykonuje zwolnienie. To wydanie może mieć postać instalacji MSI lub tylko udziału sieciowego w złożeniach. Po wprowadzeniu znaczącej zmiany zespół może poinformować o tym użytkownika, a następnie można uruchomić instalację lub skrypt, aby skopiować pliki.

Po wydaniu, możesz umieścić je w GAC, w ten sposób nie będziesz musiał się martwić o skopiowanie ich do folderów bin projektu.

Innym rozwiązaniem, zakładając, że korzystasz z serwera kompilacji lub ciągłej integracji, jest wykonanie kroku procesu lub etap procesu. Niż programiści pozostałych zespołów mogli w dowolnym momencie pobrać nowe pliki lub pobrać plik skryptu lub pliku bat na miejscu.

EDYCJA - INNE ROZWIĄZANIE Najlepiej byłoby zapytać, dlaczego masz te zależności? Czy naprawdę potrzebujesz ich lokalnie podczas budowania swojej części aplikacji? Czy możesz wyśmiewać zależności w swoim rozwiązaniu, pozwalając ci kodować, budować i uruchamiać testy jednostkowe? Rzeczywiste zastosowanie połączy je w środowisku DEV/Test/Prod. Pozostawienie rozwiązania oderwanego od produkcji i uzależnienie od niego może być lepszym rozwiązaniem dla pojedynczego zespołu. Pozostaw integrację i sprzężenie, gdy aplikacja działa w rzeczywistym ustawieniu.

Answer 2

(^{Nie kompletny odpowiedź, ale nadal:})
Każda dostawa jest lepiej przechowywane w pliku/repozytorium binarnego, w przeciwieństwie do VCS służącego do zarządzania źródeł historii.

Wolimy zarządzania tymi dostawami w repo jak Nexus, i używamy maven wrócić odpowiednich zależności.
Nawet jeśli te narzędzia mogą być bardziej zorientowane na Javę, Nexus może przechowywać wszystko, a maven jest tam tylko po to, aby przeczytać pom.xml każdego artefaktu i obliczyć właściwe zależności.