web-dev-qa-db-fra.com

Comment organiser un pipeline de build complet avec Gulp, Maven et Jenkins, jusqu'aux tests d'intégration?

J'ai un projet qui a:

  • Client JS avec un processus de construction quelque peu intéressant. Cela comprend la compilation de CSS, la caténation et la réduction de JS et CSS, la génération et le traitement de HTML et certaines autres étapes. Les outils Node comme Grunt ou Gulp sont excellents dans ce domaine.
  • Serveur Java qui est un WAR déployé sur Tomcat. Il comprend ces actifs ainsi que tous les Java. Il a toutes sortes de tests: tests unitaires, tests d'intégration qui peuvent instancier un DAO et parler à DB, et API de bout en bout tests qui parlent réellement à l'application exécutée sur Tomcat.
  • Tests de bout en bout avec Protractor. Si vous n'êtes pas familier, c'est un autre outil Node qui enveloppe Selenium.

Comment puis-je organiser l'ensemble de ce processus d'une manière saine, robuste et automatisée?

Ce que j'ai en ce moment, c'est Gulp et Maven, Maven étant propriétaire de tout le processus.

  1. Il appelle Gulp asset generation dans generate-sources en utilisant antrun (doh, troisième outil de build!).
  2. Il exécute la version régulière Java build.
  3. Il démarre Tomcat avec mon WAR en pré-test d'intégration.
  4. Il exécute Java tests E2E parlant à ce Tomcat avec plug-in à sécurité intégrée.
  5. Il appelle à nouveau Gulp avec antrun, cette fois pour exécuter les tests Protractor.
  6. Il arrête Tomcat dans le test post-intégration.
  7. Il est censé vérifier les résultats des tests dans Verify.

Ce genre de travaux, sauf que Maven est généralement très rigide et je sens que je vais trop loin. Utiliser antrun pour appeler Gulp est un truc moche. Il est très difficile de contrôler les dépendances entre ces étapes et de surveiller leurs résultats. Il est difficile de contrôler l'ordre des choses dans la même phase. La vérification de sécurité ne semble pas traiter les fichiers de rapport JUnit externes générés par Gulp. Je pourrais continuer.

Je me demande si je devrais faire plus dans mon serveur de build (Jenkins), peut-être en utilisant un pipeline de build ou des déclencheurs paramétrés - mais je ne l'ai jamais fait et je ne sais pas si c'est vraiment mieux.

Alors, comment le mettriez-vous en œuvre?

mavenbuildjenkinsbuild-processgulp
30
Konrad Garus

D'après mon expérience, le plugin maven frontal est de loin le meilleur plugin pour ce type de processus de construction/déploiement. https://github.com/eirslett/frontend-maven-plugin . C'est ainsi que je l'utilise pour Grunt mais il prend également en charge Gulp.

<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>

Une chose à savoir est le téléchargement du nœud pour le système sur lequel il est exécuté, donc si vous avez un système d'exploitation différent sur votre serveur de build, vous devrez vous assurer que c'est la version que vous avez vérifiée dans le contrôle de version, votre version locale (pour moi OSX) devra être maintenue locale à votre projet.

31
am80l

J'essaierais de construire une sorte de pipeline de pauvres.

  1. Laissez grunt/gulp faire son travail en premier (traiter les ressources, exécuter des tests frontaux, etc. - préparer les artefacts à inclure dans WAR). Échec de la génération entière lorsque cette étape échoue (génération d'actifs ou tests).

  2. Exécutez la construction maven régulière produisant le fichier WAR avec les actifs créés à l'étape 1. Il exécutera son propre ensemble de tests avec un fichier WAR normal. N'a pas besoin de connaître les choses de grognement/gorgée.

Vous aurez alors deux endroits où par exemple les tests sont exécutés (frontend, exécuté par grunt/gulp et backend par maven) mais la configuration de reporters corrects permettra aux serveurs CI de les détecter tous (nous utilisons TeamCity et cela le gère très bien).

Scriptez-le un peu et cela devrait être mieux que d'appeler le nœud via antrun plusieurs fois. Alternativement, vous pouvez exécuter la première étape à partir de la construction maven, mais il peut être difficile de contrôler les choses.

1
Michal Ostruszka

Ce projet a environ 2 ans mais il fait beaucoup de ce que vous recherchez.

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

Extrayez le pom parent qui exécute tous les sous-projets ensemble, directement du Web vers le domaine jusqu'au référentiel et échoue en cas d'échec (tests Jasmine ou SpringMVC ou SpringServices). Et cela crée également une guerre pour le déploiement côté serveur.

C'était un pré-rapporteur, donc ce serait un ajout sympa. Bien que le plugin maven frontal ressemble maintenant à l'outil pour le travail.

HTH Pankaj

0
Pankaj Tandon

Je vais juste l'utiliser comme un talon parce que j'ai cherché à faire une chose similaire, et je reviendrai plus tard pour enrichir ma réponse. En attendant, vous devriez rechercher JHipster . Bien qu'ils aient une pile beaucoup plus grande et que leur pile soit déjà construite, ils font essentiellement ce que je pense que vous voulez dans leur processus de construction.

Bien que je ne sois pas entièrement d'accord avec leur processus de construction, je reviendrai pour expliquer pourquoi et ce que je fais dans les projets sur lesquels je travaille actuellement.

0
Henry B