2011-10-22 6 views
0

Je voudrais faire une "release" qui a une signification légèrement différente de celle supposée par le plugin Maven.Parution avec Maven, SVN et Hudson (jenkins)

J'ai un projet web (que je voudrais "libérer") qui dépend de divers autres projets qui sont également construits par le même hudson (pas comme des modules).

La "libération" devrait effectuer les tâches suivantes:

  • construire tous dependend^projets DÉPENDANT via hudson
  • build-projet web (en ajoutant un numéro de version incrémenter Manifester)
  • Déployez-projet web à tomcat (ceci est déjà dans la construction régulière)
  • créer une nouvelle balise qui comprend le numéro de version à l'emplacement svn x
  • copier toutes les sources svn/head actuelles des projets où préviou construire catimini à la nouvelle balise
  • changer toutes les versions pom de tous les projets concernés à $ {versionNumber} .0.1-snapshot sur SVN/tête

Je figure ce tout le monde est quelque chose doit être fait, il est juste très difficile pour trouver la solution réelle via google.

+0

Votre dernière hypothèse est intéressante. Pourquoi penses-tu cela? – bmargulies

Répondre

0

Si vous avez des besoins spécifiques, alors je pense que la façon la plus simple de les réaliser est de créer des scripts. Plusieurs langages de script peuvent être utilisés comme étapes de construction dans Hudson.

0

Cela ressemble beaucoup à nos exigences. Nous ne l'avons pas encore complètement construit à Jenkins.

Nous avons donc en suivant la procédure:

  1. annoncer le gel du code pour permettre à toutes les équipes d'avoir le code « droit » dans le coffre et d'avoir le code « synchronisation » avec l'autre. Nous exécutons un outil java (développé en interne) qui vérifie le code crée les branches pour la libération et les étiquettes de libération. à partir de l'itération suivante, le tronc sera également mis à jour avec la nouvelle version de l'instantané. L'outil possède ses propres fichiers de configuration afin qu'il sache quels sont les numéros de version et quels projets (et où ils se trouvent) doivent être mis à jour. Nous exécutons notre travail 'build release', qui est à peu près déconnecté de tous nos repos internes d'entreprise (il ne connaît que les tiers et les repos externes). Le travail nettoie le repo maven local (il a son propre repo qu'aucun autre emploi utilise). Je télécharge tous les sous-dossiers spécifiques de nos projets (nous devons configurer cela dans le job) en utilisant le paramètre subversion-tag pour chacun et un pom Mega-project supplémentaire, qui déclare tous les projets téléchargés en modules (doit aller dans le dossier racine) . Ce travail fait aussi tout le packaging nécessaire (zipper du contenu statique, combiner des fichiers statiques de différents projets en un seul archivage, ...).

  2. déploiement

  3. tests fonctionnels

Jusqu'à présent 2 a son propre travail et 3 est complètement automatisé, il suffit de le lancer manuellement. L'étape 4 est en cours pour CI et l'étape 5 est prévue pour CI.L'étape 4 est un candidat chaud à automatiser (même s'il ne s'agit que de parties) pour le processus de publication. J'espère que cela aide un peu et vous donne quelques idées.