2011-06-30 23 views
19

W jaki sposób radzisz sobie z odwzorowywaniem zadań Jenkinsa do procesu budowania i czy byłeś w stanie tworzyć kaskadowe konfiguracje dziedziczenia?Dziedziczenie zadań w pracy Jenkinsa

Dla każdej kompilacji będę mieć co najmniej trzy zadania (standardowa ciągła integracja/nocne, skanowanie bezpieczeństwa, zasięg), a następnie niektóre zadania testowania integracyjnego w dół. Wtyczka konfiguracji fragmentów obsługuje niektóre aspekty przekrojowe zadań, ale każde zadanie jest w dalszym ciągu bardzo indywidualną jednostką, bez żadnego związku z innymi zadaniami w swojej grupie.

Niedawno zobaczyłem QuickBuild i ma dziedziczenie zadań, w którym zadania nadrzędne mogą definiować standardową grupę kroków, a jej dzieci mogą przesłonić i wyspecjalizować. Z Jenkinsem mam kopie zleceń, co jest w porządku, dopóki nie będę musiał coś zmienić. Dzięki QuickBuild relacja między zadaniami pozwala mi bez trudu rozpowszechniać moje zmiany.

Próbowałem dowiedzieć się, jak sobie z tym poradzić w Jenkins. Mogłabym użyć sparametryzowanej wtyczki wyzwalacza budowania, aby umożliwić zadaniom wywoływanie innych i nadpisywanie aspektów. Następnie pobierałbym dane z wywoływanych zleceń do rozmówcy. Podejrzewam, że napotkam szereg problemów, w których istnieją aspekty, których nie mogę przesłonić, co zmusi mnie do wdrożenia funkcji Jenkinsa w moim własnym skrypcie, dzięki czemu Jenkins będzie mniej przydatny.

W jaki sposób radzisz sobie ze złożonością zadań budowania w Jenkins? Czy słyszałeś o poważnych problemach z QuickBuild?

+0

Szukałem w tych kwestiach dzisiaj chociaż bez jakiekolwiek zainteresowanie QuickBuild. W szczególności chciałbym różne opcje konfiguracji dla CI i Nightly kompilacji, takich jak sprawdzanie na czystych przestrzeni roboczych vs wykonanie przywracania + aktualizacji, jak długo przechowywane są artefakty kompilacji i jak archiwizować lub wdrażać artefakty - przy zachowaniu tej samej listy instrukcje kompilacji dla każdego. Wtyczka Matrix/multiconfig nie zapewnia wystarczających opcji. Myślę, że możemy sobie z tym poradzić dzięki pod-zadaniu, które wykonuje samą kompilację, wywołaną sparametryzowanym obszarem roboczym - ale jest to dodatkowa złożoność. – CJBrew

+0

Jeśli każde z twoich zadań wykonuje jeden aspekt twojego CI, nie powinno być potrzeby powielania zadań między zadaniami. Mamy pracę polegającą na budowaniu, która ma pracę na dalszych etapach, która następnie przeprowadza testy integracyjne. Jeśli istnieje chęć przeprowadzenia niektórych testów etapowych w regularnych odstępach czasu, można to ustawić w tych zadaniach jako wyzwalacze czasowe. W ten sposób budowana praca po prostu się buduje, testowanie polega na testowaniu i tak dalej. Jeśli użyjesz zadania "Archiwizuj klonowaną przestrzeń roboczą", to dalsze zadanie może uzyskać dostęp do artefaktów budowy. Czy możesz rozwinąć odpowiedź, jeśli wolisz? – jbjon

+3

Zastanawiam się, czy rok później znalazłeś rozwiązanie tego problemu. – sorin

Odpowiedz

2

Miałem prawie ten sam problem. Mamy zestaw zadań, które muszą być uruchomione dla naszego łącza, a także co najmniej dwóch gałęzi. Oddziały reprezentują nasze wersje, a nowy oddział tworzony jest co kilka miesięcy. Ręczne tworzenie nowych zadań nie jest rozwiązaniem, więc sprawdziłem pewne możliwości.

Jedną z możliwości jest użycie template plugin. Umożliwia to tworzenie hierarchii zadań w rodzaju. Zapewnia dziedziczenie dla twórców, wydawców i ustawień SCM. Może pracować dla niektórych, dla mnie to nie wystarczyło.

Drugą rzeczą, którą wypróbowałem, był Ant Script do klonowania zadań, a jego siostra to Bash Script. Są naprawdę świetne. Chodzi o to, aby skrypt tworzył nowe zadanie, kopiował wszystkie ustawienia z zadania szablonu, wprowadzaj zmiany w miarę potrzeb. Ponieważ jest to skrypt, jest bardzo elastyczny i można z nim wiele zrobić. Jedyną wadą jest to, że nie spowoduje to prawdziwej hierarchii, więc zmiany w zadaniu szablonu nie będą odzwierciedlać już sklonowanych zadań, tylko w przypadku zadań, które zostaną utworzone w przyszłości.

Patrząc na wady i zalety tych dwóch rozwiązań, ich kombinacja może być najlepsza. Tworzysz projekt szablonu z kilkoma podstawowymi ustawieniami, które będą prawdziwe dla wszystkich zadań, a następnie użyjesz skryptu bash lub mrówki do tworzenia zadań w zależności od tego szablonu.

Nadzieję, że pomaga.

+0

Wtyczka szablonu jest drogą do zrobienia. Używamy go i osiągnęliśmy wszystko, czego naprawdę chcieliśmy od wtyczki szablonowej! – Mark

1

Zostałem zapytany, jakie jest nasze ewentualne rozwiązanie problemu ... Po wielu miesiącach walki z naszym systemem zakupów wydaliśmy około 4000 USD na Quickbuild. W ciągu 2-3 miesięcy mieliśmy system szablonów i byliśmy z niego bardzo zadowoleni. Zanim opuściłem firmę, mieliśmy kilka grup produktów w systemie i automatyzowaliśmy również proces wydawania.

Quickbuild był świetnym produktem. Powinien być w klasie 40 000 $, ale kosztuje znacznie mniej. Chociaż jestem pewien, że Jenkins mógłby to zrobić, byłoby to trochę kłopotliwe, podczas gdy Quickbuild miał tę funkcję upieczoną. Wprowadziłem już skomplikowane zachowania przed produktami (np. Śledzenie scalania w SVN 1.0) i żałowałem tego. Quickbuild był niedrogi i stanowił solidną podstawę dla naszych systemów budowania i testowania.

Obecnie jestem w firmie z wykorzystaniem bambusa i nadzieję, że jego funkcja oddział nowa funkcja zapewni znacznie od tego, co można zrobić QuickBuild

0

Używamy QuickBuild i wydaje się doskonale do większości rzeczy. Byłem nawet w stanie używać ich API do pisania niestandardowych wtyczek. Jednym z obszarów, w którym brakuje quickbuild, jest integracja sonaru. Zespół sonarowy ma wtyczkę Jenkinsa, a nie wersję quickbuild.

13

Chciałbym zwrócić uwagę na wydanie wtyczki opracowanej przez mój zespół i dopiero niedawno opublikowanej pod otwartym kodem źródłowym. Implementuje pełne "Dziedziczenie między zadaniami".

Oto dalsze linki, które mogą pomóc:

+0

Czy są plany dalszego rozwoju? Szczególnie naprawienie wymienionych niezgodności z 'Job Config History' i' Artifactory'. Ostatnie zatwierdzenie na GitHub jest od lutego 2015. –