Si vous déployez sur serveur Tomcat, JBoss ou GlassFish, l'outil le plus utile à votre disposition sera probablement le plugin Deploy. Ce plugin rend relativement simple l'intégration de ces plateformes dans votre processus de build Jenkins. Si vous déployer sur IBM Websphere, vous pouvez utilisez le plugin Websphere Deploy dans le même but.

Voyons ce plugin en action, en utilisant le séquenceur de build illustré dans Figure 12.1, “Une chaîne simple de déploiement automatisé”.

Ici, le build par défaut (gameoflife-default) exécute les tests unitaires et d'intégration, puis créé un déployable binaire sous la forme d'un fichier WAR. Le build des métriques (gameoflife-metrics) lance des contrôles supplémentaires sur les standards de codage et la couverture des tests. Si ces deux builds réussissent, l'application sera automatiquement déployée vers l'environnement de test par la tâche de build gameoflife-deploy-to-test.

Dans la tâche de build gameoflife-deploy-to-test, nous utilisons le plugin Copy Artifact plugin pour récupérer le fichier WAR généré dans la tâche gameoflife-default puis nous le copions dans l'espace de travail de la tâche courante (voir Figure 12.2, “Copier l'artefact binaire à déployer”).

Ensuite, nous utilisons le plugin Deploy pour déployer le fichier WAR sur le serveur de test. Bien sûr, il est généralement possible, et pas trop difficile, d'écrire à la main un tel script de déploiement. Dans certains cas, cela peut être votre seul recours. Toutefois, si un plugin Jenkins existe pour votre serveur d'application, cela peut simplifier considérablement les choses de l'utiliser. Si vous déployez sur Tomcat, JBoss, ou GlassFish, le plugin Deploy est susceptible de vous aider. Ce plugin utilise Cargo pour se connecter à votre serveur d'application et y déployer (ou redéployer) votre application. Il suffit sélectionner le type de serveur visé, spécifier son URL ainsi qu'un nom et mot de passe d'utilisateur ayant les droits de déploiement (voir Figure 12.3, “Déployer sur Tomcat avec le plugin Deploy”).

Cela est connu comme le déploiement à chaud, c'est à dire que l'appplication est déployée sur un serveur en cours de fonctionnement. Cela est généralement une façon rapide et efficace d'avoir votre application en ligne, et devrait être votre solution préférée pour cela. Cependant, en fonction de votre application et de votre serveur, cette approche fut parfois source de fuites de mémoire ou de verrouillage de ressources. Les anciennes versions de Tomcat, par exemple, étaient bien connues pour cela. Si cela vous arrive, vous pourriez avoir à planifier des redémarrages après chaque déploiement, ou éventuellement planifier des redémarrages nocturnes du serveur d'application de votre environnement de test.

Lorsque vous déployez votre application de façon automatisée ou continuellement, il devient critique de bien identifier la version de l'application actuellement déployée. Il y a plusieurs façons de faire cela, qui varient essentiellement en fonction du rôle de Jenkins dans l'architecture de build et de déploiement.

Certaines équipes utilisent Jenkins comme la source de vérité, où les artefacts sont à la fois construits et gardés pour référence. Si vous stockez vos artefacts déployables dans Jenkins, il est alors parfaitement logique de déployer vos artefacts directement depuis votre instance Jenkins. Cela est facile à faire : dans la prochaine section nous verrons comment faire cela au moyen des plugins Copy Artifacts, Deploy, et Parameterized Trigger.

Alternativement, si vous gardez vos artefacts dans un dépôt d'entreprise tel que Nexus ou Artifactory, alors ce dépôt devrait être le point central de référence : les artefacts devraient être construits et déployés par Jenkins, et les déployer ensuite depuis ici. C'est typiquement le cas lorsque vous utilisez Maven comme votre outil de build. Des équipes utilisant Gradle ou Ivy sont aussi susceptibles d'utiliser cette approche. Les gestionnaires de dépôt tels que Nexus et Artifactory, particulièrement dans leur éditions commerciales, rendent cette stratégie plus aisée en offrant des fonctionnalités telles que la promotion de build et des dépôts intermédiaires qui aident à contrôler les versions des artefacts.

Voyons à présent comment vous pourriez implémenter chacune de ces stratégies en utilisant Jenkins.

Redéployer un artefact prédédement déployé dans Jenkins est relativement simple. Dans Section 12.3.1.1, “Utiliser le plugin Deploy”, nous avons vu comment utiliser les plugins Copy Artifacts et Deploy pour déployer un fichier WAR produit par une tâche de build précédente vers un serveur d'application. Ce dont nous avons besoin à présent est de laisser l'utilisateur spécifier la version à déployer, plutôt que de se contenter de déployer le dernier build.

Nous pouvons faire cela en utilisant le plugin Parameterized Trigger (voir Section 10.2, “Tâches de build paramétrées”). En premier lieu, nous ajoutons un paramètre à la tâche de construction, en utilisant le type de paramètre “Build selector for Copy Artifact” (voir Figure 12.4, “Ajouter un paramètre “Build selector for Copy Artifact””).

Cela ajoute un nouveau paramètre à votre tâche de build (voir Figure 12.5, “Configurer le sélecteur de paramétrage de build”). Vous devez entrer un nom et une description courte. Le nom fourni sera utilisé comme une variable d'environnement pour les étapes suivantes du build.

Le sélecteur de paramétrage de build vous permet de choisir un build précédent de diverses façons, y compris le dernier build réussi, le build en amont ayant déclenché cette tâche de build ou un build spécifique. Toutes ces options seront offertes à l'utilisateur lorsqu'il ou elle déclenchera un build. Le sélecteur par défaut vous permet de spécifier laquelle de ces options sera proposé par défaut.

Lorsque l'utilisateur sélectionne une tâche de build particulière, le numéro de build sera également stocké dans la variable d'environnement pour l'utiliser dans les étapes du build. La variable d'environnement est appelé COPYARTIFACT_BUILD_NUMBER_MY_BUILD_JOB, où MY_BUILD_JOB est le nom de la tâche de build originelle (en lettres majuscules et avec les caractères autres que A–Z convertis en blanc soulignés). Par exemple, si nous copions un artefact avec le numéro de build 4 vers le project gameoflife-default, la variable d'environnement COPYARTIFACT_BUILD_NUMBER_GAMEOFLIFE_DEFAULT aura la valeur de 4.

La seconde partie de la configuration est de dire à Jenkins ce qu'il doit récupérer, et en provenance de quelle tâche de build. Dans la section Build de la configuration de notre projet, nous ajoutons une étape “Copy artifacts from another project”. Là nous spécifions le projet où l'artefact a été construit et archivé (gameoflife-default dans notre exemple). Vous devez aussi faire en sorte que Jenkins utilise le build spécifié dans le paramètre défini précédement. Cela se fait en choisissant “Specified by a build parameter” dans l'option “Which build” et en fournissant le nom de variable donné plus tôt dans le sélecteur de paramétrage de build (voir Figure 12.6, “Specifier où trouver les artefacts à déployer”). Ensuite, il suffit de configrer les artefacts à copier comme nous l'avons fait dans l'exemple précédent.

Enfin, nous déployons l'artefact copié en utilisant le plugin Deploy, comme illustré dans Figure 12.3, “Déployer sur Tomcat avec le plugin Deploy”.

Voyons comment ce build fonctionne en pratique. Lorsque nous déclenchons un build manuellement, Jenkins va proposer une liste d'options vous permettant de choisir le build à redéployer (voir Figure 12.7, “Choix du build à redéployer”).

La plupat de ces options sont explicites.

L'option “latest successful build” correspond au build le plus récent sans prendre en compte les builds échoués. Cette option va donc se contenter de déployer à nouveau la dernière version. Si vous utilisez cette option, vous voudrez probablement cocher la case “Stable builds only”, qui excluera également tout build instable.

Si vous avez choisi de supprimer les anciens builds, vous serez capable d'indiquer que certaines tâches de build doivent être éternellement conservées (voir Section 5.3.1, “Options Générales”). Dans ce cas, vous pouvez choisir de déployer le “Latest saved build”.

Une option raisonnable pour une tâche de build automatisée à la fin d'un séquenceur de build est “Upstream build that triggered this job”. Ainsi, vous pouvez être sûr que vous allez déployer l'artefact qui a été généré (ou promu) par la précédente tâche de build, même si d'autres builds ont eu lieu depuis. Il est important de noter que, bien que ce type de build paramétré est souvent utilisé pour déployer manuellement un artefact spécifique, il peut aussi être utilisé efficacement au sein d'un build automatisé. S'il n'est pas déclenché manuellement, le build va simplement utiliser la valeur définie dans le champ “default selector”.

Vous pouvez aussi choisir l'option “Specified by permalink” (voir Figure 12.8, “Utiliser l'option “Specified by permalink””). Cela vous permet de choisir parmi un certain nombre de valeurs, telles que le dernier build, le dernier build stable, le dernier build réussi et ainsi de suite.

Cependant, si vous voulez redéployer une version particulière de votre application, une option plus utile est “Specific build” (voir Figure 12.9, “Utiliser un build spécifique”). Cette option vous demande de fournir un numéro de build particulier indiquant le build à déployer. Cela est la façon la plus flexible de redéployer une application, vous avez seulement besoin de connaître le numéro du build à redéployer, mais cela n'est généralement pas difficile à trouver en regardant l'historique du build de la tâche de build originelle.

Cela est une façon pratique de déployer ou redéployer des artefacts de build Jenkins précédents. Cependant, dans certains cas, vous pourriez préférer utiliser un artefact stocké dans un dépôt d'entreprise comme Nexus ou Artifactory. Nous allons voir un exemple de cela dans la prochaine section.

De nombreuses organisations utilisent un gestionnaire de dépôt tel que Nexus ou Artifactory afin de stocker et partager des artefacts binaires tels que des fichiers JAR. Cette stratégie est communément utilisée avec Maven, mais également avec d'autres outils de build tels que Ant (couplé à Ivy ou aux Maven Ant Tasks) et Gradle. Dans un environnement d'Intégration Continue, les versions snapshots et délivrables sont construites sur votre serveur Jenkins, puis déployées sur votre gestionnaire de dépôt (voir Figure 12.10, “Utiliser un dépôt d'entreprise Maven”). A chaque fois qu'un développeur enregistre un changement dans le code source sur le système de contrôle des versions, Jenkins va prendre ces changements et construire de nouvelles versions snapshot des artefacts correspondant. Jenkins deploie alors ces artefacts snapshots sur le gestionnaire de dépôt d'entreprise, où ils peuvent être mis à disposition des autres développeurs de l'équipe ou d'autres équipes au sein de l'organisation. Nous avons discuté sur la façon de faire pour que Jenkins déploie automatiquement les artefacts Maven dans Figure 12.10, “Utiliser un dépôt d'entreprise Maven”. Une approche similaire peut être suivie avec Gradle ou Ivy.

Les conventions Maven se basent sur un système bien défini d'identifiants de version, faisant la distinction entre des versions SNAPSHOTS et RELEASE. Les versions SNAPSHOT sont considérées comme des builds potentiellement instables des dernières sources, tandis que les versions RELEASE sont des versions officielles étant passées au travers d'un processus de livraison plus formel. Typiquement, les artefacts SNAPSHOT sont réservés à un usage interne à l'équipe de développement, tandis que les versions RELEASE sont considérées comme prêtes pour des tests plus avancés.

Une approche très similaire peut être utilisée pour des artefacts déployables tels que les fichiers WAR ou EAR, qui sont construits et testés sur le serveur d'intégration continue, puis déployés automatiquement vers le dépôt d'entreprise, souvent au sein d'un séquenceur de build impliquant des tests automatisés et des contrôles qualité (voir Section 10.7, “Pipelines de build et promotions”). Les versions SNAPSHOT sont typiquement déployées sur un serveur de test pour des tests automatisés ou manuels, afin de déterminer si une version est prête pour être officiellement publiées.

La stratégie exacte utilisée pour déterminer quand une version est à créer et comment elle est déployée varie grandement d'une organisation à une autre. Par exemple, certaines équipes préfèrent un processus formel à la fin de chaque itération, avec un numéro de version bien défini et des notes de livraison correspondantes distribuées aux équipes d'assurance qualité pour des tests supplémentaires. Quand une version particulière obtient le feu vert de l'assurance qualité, elle peut être déployée en production. D'autres préfèrent utiliser un processus lean, déployant une nouvelle version lorsqu'un correctif ou une nouvelle fonctionnalité est prêt à être déployé. Si une équipe est particulièrement confiante dans ses tests automatisés et ses contrôles qualité, il est même possible d'automatiser complètement le processus, en générant et livrant une nouvelle version périodiquement (par exemple chaque nuit) ou à chaque fois qu'un changement a été réalisé.

Il y a de nombreuses façons d'implémenter ce type de stratégie. Dans le reste de cette section, nous verrons comment la réaliser via un projet Maven multimodule conventionnel. Notre projet de démonstration est une application web nommée gameoflife, consistituée de trois modules : gameoflife-core, gameoflife-services et gameoflife-web. Le module gameoflife-web génère un fichier WAR incluant les JAR des deux autres modules. Le WAR est ce que nous voulons déployer :

tuatara:gameoflife johnsmart$ ls -l
total 32
drwxr-xr-x  16 johnsmart  staff    544 16 May 09:58 gameoflife-core
drwxr-xr-x   8 johnsmart  staff    272  4 May 18:12 gameoflife-deploy
drwxr-xr-x   8 johnsmart  staff    272 16 May 09:58 gameoflife-services
drwxr-xr-x  15 johnsmart  staff    510 16 May 09:58 gameoflife-web
-rw-r--r--@  1 johnsmart  staff  12182  4 May 18:07 pom.xml

Précédement dans ce chapitre, nous avons vu comment utiliser le plugin Deploy pour déployer un fichier WAR généré par la tâche de build courante vers un serveur d'application. Ce que nous voulons maintenant c'est déployer une version arbitraire du fichier WAR vers un serveur d'application.

Dans Section 10.7.1, “Gestion des releases Maven avec le plugin M2Release”, nous avons discuté de comment configurer Jenkins pour invoquer le plugin Maven Release afin de générer une version release formelle de l'application. La première étape du déploiement débute ici, nous supposerons donc que cela a été configuré et que plusieurs versions releases ont déjà été déployées sur notre gestionnaire de dépôt d'entreprise.

La prochaine étape implique de créer un projet dédié pour le processus de déploiement. Ce projet sera un projet Maven standard.

La première chose à faire est de mettre en place un projet de déploiement dédié. Dans sa forme la plus simple, ce projet va simplement récupérer la version requise de votre fichier WAR depuis le gestionnaire de dépôt pour le déployer avec Jenkins. Dans le fichier pom.xml qui suit, nous utilisons le module maven-war-plugin pour récupérer la version spécifiée du fichier WAR gameoflife-web. Cette version est spécifiée dans la propriété target.version :

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/
        XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://
  maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.wakaleo.gameoflife</groupId>
  <artifactId>gameoflife-deploy-with-jenkins</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>war</packaging>
  <dependencies>
    <dependency>
      <groupId>com.wakaleo.gameoflife</groupId>
      <artifactId>gameoflife-web</artifactId>
      <type>war</type>d
      <version>${target.version}</version>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-war-plugin</artifactId>
        <configuration>
          <warName>gameoflife</warName>
          <overlays>
            <overlay>
              <groupId>com.wakaleo.gameoflife</groupId>
              <artifactId>gameoflife-web</artifactId>
            </overlay>
          </overlays>
        </configuration>
      </plugin>
    </plugins>
  </build>
  <properties>
    <target.version>RELEASE</target.version>
  </properties>
</project>

Ensuite, nous configurons un build Jenkins pour invoquer le fichier pom.xml en utilisant une valeur pour la propriété définie par l'utilisateur (voir Figure 12.11, “Déployer un artefact depuis un dépôt Maven”). Notez que nous avons défini la valeur par défaut à RELEASE pour qu'ainsi, par défaut, la version release la plus récente soit déployée. Sinon, l'utilisateur peut fournir le numéro de version de la version à déployer ou à redéployer.

La suite de cette tâche de build récupère simplement le projet à déployer et appelle le but mvn package, puis déploie le fichier WAR en utilisant le plugin Deploy (voir Figure 12.12, “Préparer le WAR à déployer”). La propriété target.version sera automatiquement passée dans la tâche de build et utilisée pour déployer la bonne version.

Des techniques similaires peuvent être utilisées pour d'autres types de projet. Si vous déployez sur un serveur d'application non supporté par le plugin Deploy, vous avez aussi la possibilité d'écrire un script spécifique dans le langage de votre choix et en faisant en sorte que Jenkins passe le numéro de version demandé comme décrit plus haut.