Sortie de Maven vers Nexus

1. Vue d'ensemble

Dans l'article précédent de cette série, nous avons mis en place un processus de déploiement avec Maven vers Nexus . Dans cet article, nous allons configurer le processus de publication avec Maven - à la fois dans le pom du projet et dans un travail Jenkins.

2. Référentiel dans le pom

Pour que Maven puisse publier sur un serveur de référentiel Nexus, nous devons définir les informations du référentiel via l' élément distributionManagement :

  nexus-releases //localhost:8081/nexus/content/repositories/releases  

Le référentiel de versions hébergé est prêt à l'emploi sur Nexus, il n'est donc pas nécessaire de le créer explicitement.

3. SCM dans le pom Maven

Le processus de publication interagira avec le contrôle de source du projet - cela signifie que nous devons d'abord définir le élément dans notre pom.xml :

 scm:git://github.com/user/project.git //github.com/user/project scm:git://github.com/user/project.git 

Ou, en utilisant le protocole git:

 scm:git:[email protected]:user/project.git scm:git:[email protected]:user/project.git scm:git:[email protected]:user/project.git 

4. Le plugin Release

Le plugin Maven standard utilisé par un processus de publication est le plugin maven-release-plugin - la configuration de ce plugin est minimale:

 org.apache.maven.plugins maven-release-plugin 2.4.2  [email protected]{project.version} true releases  

Ce qui est important ici, c'est que la configuration releaseProfiles forcera en fait un profil Maven - le profil des releases - à devenir actif pendant le processus de Release.

C'est dans ce processus que le plugin nexus-staging-maven-plugin est utilisé pour effectuer un déploiement sur le référentiel Nexus de nexus-releases :

  releases    org.sonatype.plugins nexus-staging-maven-plugin 1.5.1   default-deploy deploy  deploy     nexus-releases //localhost:8081/nexus/ true      

Le plug-in est configuré pour exécuter le processus de publication sans le mécanisme de transfert , comme précédemment, pour le processus de déploiement ( skipStaging = true ).

Et également similaire au processus de déploiement, la libération vers Nexus est une opération sécurisée - nous allons donc utiliser à nouveau le formulaire utilisateur de déploiement Out of the Box Nexus.

Nous devons également configurer les informations d'identification pour le serveur nexus-releases dans le global settings.xml ( % USER_HOME% /. M2 / settings.xml ):

  nexus-releases deployment the_pass_for_the_deployment_user  

Ceci est la configuration complète

5. Le processus de libération

Décomposons le processus de publication en petites étapes ciblées. Nous effectuons une version lorsque la version actuelle du projet est une version SNAPSHOT - disons 0.1-SNAPSHOT .

5.1. Sortie: propre

Nettoyer une version :

  • supprimer le descripteur de version ( release.properties )
  • supprimer tous les fichiers POM de sauvegarde

5.2. libération: préparer

La prochaine étape du processus de libération est la préparation de la version ; cette volonté:

  • effectuer quelques vérifications - il ne devrait y avoir aucune modification non validée et le projet ne devrait dépendre d'aucune dépendance SNAPSHOT
  • changer la version du projet dans le fichier pom en un numéro de version complet (supprimer le suffixe SNAPSHOT) - dans notre exemple - 0.1
  • exécuter les suites de tests du projet
  • valider et pousser les changements
  • créer la balise à partir de ce code versionné non-SNAPSHOT
  • augmenter la version du projet dans le pom - dans notre exemple - 0.2-SNAPSHOT
  • valider et pousser les changements

5.3. libération: effectuer

La dernière partie du processus de libération est l' exécution de la libération ; cette volonté:

  • checkout release tag de SCM
  • construire et déployer du code publié

Cette deuxième étape du processus repose sur la sortie de l'étape de préparation - release.properties .

6. Sur Jenkins

Jenkins peut effectuer le processus de publication de deux manières: il peut soit utiliser ses propres plugins de publication, soit simplement exécuter la version avec un travail maven standard exécutant les étapes de publication appropriées.

Les plugins Jenkins existants axés sur le processus de publication sont:

  • Libérer le plugin
  • Plugin de version M2

Cependant, comme la commande Maven pour exécuter la version est assez simple, nous pouvons simplement définir un travail Jenkins standard pour effectuer l'opération - aucun plug-in n'est nécessaire.

Ainsi, pour un nouveau travail Jenkins (Construisez un projet maven2 / 3) - nous allons définir 2 paramètres de chaîne: releaseVersion = 0.1 et developmentVersion = 0.2-SNAPSHOT .

Dans la section Configuration de la construction , nous pouvons simplement configurer la commande Maven suivante pour qu'elle s'exécute:

Release:Clean release:prepare release:perform -DreleaseVersion=${releaseVersion} -DdevelopmentVersion=${developmentVersion}

Lors de l'exécution d'une tâche paramétrée, Jenkins invitera l'utilisateur à spécifier des valeurs pour ces paramètres - donc chaque fois que nous exécutons la tâche, nous devons remplir les bonnes valeurs pour releaseVersion et developmentVersion .

Also, it's worth using the Workspace Cleanup Plugin and check the Delete workspace before build starts option for this build. However keep in mind that the perform step of the Release should necessarily be run by the same command as the preparestep – this is because the latter perform step will use the release.properties file created by prepare. This means that we cannot have a Jenkins Job running prepareand another running perform.

7. Conclusion

Cet article a montré comment implémenter le processus de publication d'un projet Maven avec ou sans Jenkins. Similaire au déploiement, ce processus utilise le plugin nexus-staging-maven-plugin pour interagir avec Nexus et se concentre sur un projet git.