Jak zorganizować budowę rurociągu pełnego z Gulp, Maven i Jenkins, aż do testów integracyjnych?

Question

Mam projekt, który posiada:

• JS klientowi nieco ciekawego procesu kompilacji. Obejmuje to kompilację CSS, catenowanie i minimalizowanie JS i CSS, generowanie i przetwarzanie HTML oraz kilka innych czynności. Narzędzia Node, takie jak Grunt lub Gulp są w tym świetne.
• Serwer Java będący operacją WAR wdrożoną na serwerze Tomcat. Obejmuje te zasoby, a także cały kod Java. Posiada wszystkie rodzaje testów: testy jednostkowe, testy integracyjne, które mogą utworzyć instancję DAO i rozmowę z DB, oraz kompleksowe testy API, które faktycznie komunikują się z aplikacją działającą na Tomcat.
• End-to-end tests with Protractor. Jeśli nie jesteś zaznajomiony, jest to kolejne narzędzie Node, które otacza Selenium.

Jak zorganizować cały ten proces w rozsądny, solidny i zautomatyzowany sposób?

W tej chwili mam Gulp i Maven, a Maven w zasadzie jest właścicielem całego procesu.

1. Wywołuje generowanie zasobów Gulp w źródłach generujących za pomocą narzędzia antirun (doh, narzędzie do budowania trzeciego!).
2. Uruchamia zwykłą kompilację Java.
3. Zaczyna Tomcat z moją wojną podczas testu przed integracją.
4. Uruchamia testy Java E2E rozmawiające z tym tomcat za pomocą wtyczki failsafe.
5. Ponownie wywołuje Gulpa z Antrun, tym razem aby uruchomić testy Kątomierza.
6. Wyłącza Tomcat w teście po integracji.
7. Powinien zweryfikować wyniki testu.

Tego rodzaju prace, z wyjątkiem tego, że Maven jest ogólnie bardzo sztywny i czuję, że zajmuję to za daleko. Używanie antrun do wywoływania Gulpa to brzydka sztuczka. Bardzo trudno kontrolować zależności między tymi krokami i monitorować ich wyniki. Trudno kontrolować porządek rzeczy w tej samej fazie. Weryfikacja Failsafe nie przetwarza zewnętrznych plików raportów JUnit wygenerowanych przez Gulp. Mógłbym iść dalej.

Zastanawiam się, czy powinienem zrobić więcej w moim serwerze budowania (Jenkins), może przy użyciu budowania potoków lub sparametryzowanych wyzwalaczy - ale nigdy tego nie robiłem i nie jestem pewien, czy to naprawdę jest lepsze.

A więc, jak byś to wdrożył?

Answer 1

Chciałbym zbudować rodzaj rurociągu dla biednych.

1. Niech grunt/łyk zrobić swoją pracę pierwszy (aktywa procesowe, prowadzone testy frontend etc - przygotować artefakty, które należy uwzględnić w wojnie). Niepowodzenie całej kompilacji, gdy ten krok się nie powiedzie (generowanie lub testowanie zasobów).

2. Uruchom regularną kompilację maven, która tworzy plik WAR z zasobów utworzonych w kroku 1. Uruchomi własny zestaw testów z zwykłym plikiem WAR. Nie musi wiedzieć o rzeczach chrząknięć.

Będziesz mieć dwa miejsca, w których np.Testy są uruchamiane (frontend, uruchamiane przez grunt/gulp i backend przez maven), ale konfigurowanie poprawnych reporterów pozwoli serwerom CI wykryć je wszystkie (korzystamy z TeamCity i obsługujemy to dobrze).

Skryptuj go nieco i powinien być lepszy niż wywoływanie węzła za pomocą Antrun wiele razy. Alternatywnie możesz uruchomić pierwszy krok z poziomu kompilacji maven, ale może to być trudne do kontrolowania.

Answer 2

Z mojego doświadczenia wynika, że ​​wtyczka frontend maven jest najlepszą wtyczką do tego typu procesu budowania/wdrażania. https://github.com/eirslett/frontend-maven-plugin. W ten sposób używam go dla Grunta, ale obsługuje on również Gulpa.

<plugin> 
    <groupId>com.github.eirslett</groupId> 
    <artifactId>frontend-maven-plugin</artifactId> 
    <version>...</version> 

    <!-- optional --> 
    <configuration> 
     <workingDirectory>src/main/frontend</workingDirectory> 
    </configuration> 

    <execution> 
    <id>grunt build</id> 
    <goals> 
     <goal>grunt</goal> 
    </goals> 

    <!-- optional: the default phase is "generate-resources" --> 
    <phase>generate-resources</phase> 

    <configuration> 
     <!-- optional: if not specified, it will run Grunt's default 
     task (and you can remove this whole <configuration> section.) --> 
     <arguments>build</arguments> 
    </configuration> 
</execution> 
</plugin> 

Jedno być świadomi to będzie pobrać węzeł do systemu jest on prowadzony dalej, więc jeśli masz inny system operacyjny na serwerze kompilacji, musisz upewnić się, że jest to wersja sprawdziłeś kontrolę wersji, twoja lokalna wersja (dla mnie OSX) będzie musiała być utrzymywana lokalnie w twoim projekcie.

Answer 3

Po prostu użyję tego jako kodu pośredniczącego, ponieważ starałem się zrobić coś podobnego, a wrócę później, aby wzbogacić moją odpowiedź. W międzyczasie powinieneś przejrzeć JHipster. Chociaż mają dużo większy stos, a ich stos jest już zbudowany, w zasadzie robią to, co myślę, że chcesz w swoim procesie budowania.

Chociaż nie zgadzam się całkowicie z procesem ich budowy, powrócę do wyjaśnienia, dlaczego i co robię w projektach, nad którymi obecnie pracuję.

Answer 4

Ten projekt ma około 2 lat, ale ma wiele elementów, których szukasz.

https://github.com/pankajtandon/PointyPatient/blob/master/pointy-web/pom.xml

Do kasy pom nadrzędnego, które w zasadzie prowadzi wszelkie podprojektów razem bezpośrednio z sieci do domeny do repo i nie powiedzie, czy nie (Jasmine lub SpringMVC lub SpringServices testy) niepowodzeniem. I buduje również wojnę dla wdrożenia po stronie serwera.

To był pre-kątomierz, więc byłby to miły dodatek. Altho dodatek do frontendu wygląda teraz jak narzędzie do pracy.

HTH Pankaj