Jenkins: jak tworzyć wiele projektów najwyższego poziomu z repozytorium git?

Question

Mam repozytorium Git, które zawiera kilka projektów najwyższego poziomu maven (każdy siedzi w ich własnym podkatalogu z pom.xml). Najwyższy poziom oznacza, że ​​te projekty znajdują się w podkatalogu bezpośrednio pod katalogiem głównym repozytorium. Wszystkie te projekty powinny pozostać w tym samym repozytorium Git.

repo 
+--- projectA 
    +--- pom.xml 

+--- projectB 
    +--- pom.xml 

Mogą/powinny być budowane przez niezależne firmy Jenkins. Mamy więc pracę dla projektu A i jednego dla projektu B.

Dawniej z Subversion udało mi się stworzyć zadanie Jenkinsa (dla każdego projektu), które miało być wykonane tylko ze źródła projektu i uruchomić kompilację Maven z pliku pom.xml.

Z modelem Git (prawdopodobnie to samo ze wszystkimi DVCS) to się zmienia i nie jestem pewien, co jest najlepszą praktyką. Istnieje kilka opcji, które widzę i od którego nikt tak naprawdę lubię:

1. Każde zadanie Jenkins jest configured sklonować/pull pełną Git repo i odnosi się do /pom.xml dla Maven budować. Tak więc zadanie ma cały kod, ale buduje tylko jego kawałek.
2. Git oferuje submodules (http://book.git-scm.com/5_submodules.html), które wydają się być nieco kłopotliwe w obsłudze (i może łatwo pęknąć)
3. Tworzenie maven rodzica (agregator, który zawiera wszystkie projekty) Projekt, który wyzwala każdy projekty budowy (o jedna robota jenkins). Ten plik pom.xml zawiera elementy projektuA i projectB.

Czy widzisz bardziej przydatne podejście do tego (bardzo typowa konfiguracja). Jakie jest twoje doświadczenie? Jakieś najlepsze praktyki?

Answer 1

Myślę, że pracujesz przeciwko ziarnu tutaj. Jeśli te projekty są wydawane jako jednostka z wersjami, powinieneś stworzyć macierzysty POM. Ale prawdopodobnie powinieneś mieć tylko jedno zadanie CI. Jeśli chcesz, aby ta kompilacja działała szybko, możesz skonfigurować ją tak, aby budowała tylko moduły, które zmieniły się od czasu ostatniej kompilacji (przycisk zaawansowany w sekcji Kompilacja - "Tylko przyrostowe zmienione moduły"). Możesz również powiedzieć Jenkinsowi, aby w razie potrzeby uruchamiał współbieżne kompilacje, aby przetestować wiele zatwierdzeń naraz.

Ale jestem ciekawy, dlaczego uważasz, że chcesz mieć wiele zadań CI? Jeśli dostrzeżesz, że te dwa projekty mają różne cykle życia, być może powinny one być wersjonowane osobno i dlatego powinny być w oddzielnych repozytoriach git. Nie przechowuj repozytoriów git, są tanie. W rzeczywistości im więcej, tym weselej we wszystkich niemal przypadkach.

Zwykle chcesz, aby dany pom tworzył jeden artefakt. Poms agregatorów są przydatne do rozbijania części większego artefaktu na submoduły, ale tylko wtedy, gdy te submoduły nie są uwalniane samodzielnie.

Answer 2

Cóż, istnieje najlepsza praktyka nie powtarzania się. Zatem posiadanie super POM byłoby dobre z tego punktu widzenia.

Prawdopodobnie idę z opcją 1. Miejsce na dysku jest zwykle tanie.

Ale 3 ułatwiłoby wdrożenie do nowych systemów bez ponownego konfigurowania Jenkins.

Answer 3

@recampbell, mam ten sam problem. Mamy kilka powiązanych ze sobą projektów w jednym repozytorium Hg.

W ten sposób wiemy dokładnie, pod którą wersją (numer wersji hg), każdy się kompiluje. Kiedy mówię dokładnie, mam na myśli, że mogę zweryfikować, że jest binarny identyczny.

Używanie numerów wersji jest zbyt gruboziarniste. Na przykład dzisiaj znalazłem błąd, który był powtarzalny tylko w wersji hg 3367, ale nie w wersji hg 3368. Używanie wielokrotnych replik hg, które nie byłyby odtwarzalne, ponieważ każdego dnia w każdym projekcie jest kilka zatwierdzeń, a zatem jest to niemożliwe jest dokładne określenie, która wersja każdego projektu została użyta, tylko wersja hg jest właściwa do użycia (użycie bisect do znalezienia błędu).

Okazało się, że zmieniliśmy wersję sterownika bazy danych klienta w jednym z podprojektów i że nasza automatyczna generacja dao zakończyła się niepowodzeniem z NPE. Kierowca oczywiście, jeśli wersja wydania, której nie piszemy, po prostu używamy wersji dostarczonej przez sprzedawcę. Zajęło by nam to kilka dni debugowania tego, ale ponieważ używamy Jenkinsa do budowania co godzinę, wiedzieliśmy, że jest od 10 do 20 zatwierdzeń do przeszukania, a tylko 3 lub 4 dotknęły generatora dao, więc było to łatwe zadanie.

Posiadanie wersji mieszanych każdego projektu stanowiłoby ból w dolnej części pleców, ponieważ mielibyśmy kilka różnych dao-generator-3.1.2.jar, które byłyby trochę inne od innych (chyba że oczekują od nas zmiany numerów wersji po każdym zatwierdzeniu, lub jeśli istnieje jakaś konfiguracja w Jenkins/maven/cokolwiek, co robi to automatycznie? byłoby świetnie ...).