Déploiement incrémental ou redéploiement complet

Dans un précédent article sur le déploiement, j’ai présenté l’ensemble des tâches à mettre en œuvre pour déployer une application Java dans un environnement d’entreprise. Le scénario décrivait étape après étape la configuration de chaque composant comme les serveurs web, les pare-feux, la base de données et les ressources externes JEE. Le point clé à retenir était que ces différentes configurations de composants avaient autant d’importance dans un déploiement que l’installation d’un fichier EAR ou WAR.

Mais voilà, comme on l’avait rapidement suggéré précédemment, il existe un scénario légèrement plus compliqué que celui décrit ci-dessus ; il s’agit du cas de mise à jour d’une application vers une nouvelle version. Bien que le déploiement initial d’une application soit forcément important, un certain nombre de raisons me fait penser que le déploiement d’une nouvelle version l’est encore plus.

Livrer une nouvelle version est plus important que le premier déploiement !

Voici quelques raisons qui peuvent vous convaincre de porter plus d’attention à une nouvelle livraison:

• Les mises à jour sont plus fréquentes qu’un déploiement initial. ;-)
• Les mises à jour en production ont lieu alors que les utilisateurs sont déjà en train d’utiliser l’application ; il est préférable que cette dernière reste accessible pendant le déploiement ou, au pire, que la coupure soit la plus brève possible.
• Si une mise à jour échoue, l’ancienne version doit toujours être réinstallable.
• Et le fait qu’une mise à jour soit « routinière », peut tromper la vigilance des différentes personnes, responsables du déploiement. Il faut se méfier de l’excès de confiance. Lorsqu’une application est déployée pour la première fois, chacun est très attentif : les développeurs, les administrateurs des différents composants, les architectes, les responsables de projet, les utilisateurs, etc. Donc, quand un problème arrive, il est traité très rapidement. En revanche, si on souhaite déployer la version 2.1.54 un vendredi après-midi, c’est là que tout peut aller de travers.

En résumé, la mise à jour d’une application est complexe, et être concentré permet de diminuer les risques d’échec.

A présent, partons du scénario initial lorsque l’application est déployée. Ce scénario comprenait un fichier EAR, quelques fichiers statiques (images, css, etc.) et des scripts SQL.
Comment allons-nous mettre à jour cette application pour passer en v1.1 ? Pour simplifier, nous imaginons qu’il n’y a pas eu de changements sur le schéma de base de données entre v1.0 et v1.1.
Deux solutions sont possibles : soit nous mettons à jour juste ce qui est nécessaire, il s’agit alors d’un déploiement incrémental, soit nous supprimons la totalité de v1.0 et déployons proprement v1.1, et dans ce cas on fait un redéploiement complet.

Etapes nécessaires à chaque scénario

Si on choisit de simplement mettre à jour, voici les tâches à accomplir :

1. Supprimer le contenu statique v1.0 du serveur web.
2. Arrêter l’application v1.0.
3. Supprimer l’application v1.0.
4. Déployer l’application v1.1 à partir du fichier EAR.
5. Démarrer l’application v1.1.
6. Copier le contenu statique v1.1 sur le serveur web.

Et un redéploiement complet ressemble à ceci :

1. Arrêter le serveur web.
2. Supprimer le contenu statique v1.0 du serveur web.
3. Supprimer la configuration v1.0 du serveur web.
4. Arrêter le serveur d’applications.
5. Supprimer l’application v1.0.
6. Supprimer la configuration du serveur d’applications nécessaire à v1.0 (source de données, queues, etc.).
7. Créer la configuration du serveur d’applications pour v1.1.
8. Déployer l’application v1.1 à partir du fichier EAR.
9. Démarrer le serveur d’applications.
10. Créer la configuration v1.1 du serveur web.
11. Copier le contenu statique v1.1 sur le serveur web.
12. Démarrer le serveur web.

Si on compare les deux scénarii, on note aisément le nombre de différences :

• Le serveur web est arrêté au début et démarré seulement à la toute fin (étape 1 et 12).
• La configuration du serveur web est supprimée avant d’être recréée (étape 3 et 10).
• Au lieu de simplement arrêter puis démarrer l’application, le serveur d’applications complet est arrêté et démarré (étape 4 et 9).
• La configuration du serveur d’applications est elle aussi supprimée puis recréée (étape 6 et 7).

En supprimant puis recréant la configuration du serveur web et du serveur d’applications, nous avons la certitude de connaitre exactement le résultat qu’on obtiendra. En effet, si des changements ont eu lieu dans la configuration qui n’ont pas été notés, ils seront supprimés et non recréés. Pour ce faire, il faut arrêter les serveurs avant de les redémarrer à la toute fin du déploiement. Par contre, cela rend l’application indisponible, mais vous savez de toutes façons qu’il faudra bientôt mettre en place un cluster pour avoir une haute disponibilité, n’est-ce pas ? ;-)

L’autre point intéressant de ce scénario se trouve entre les étapes 7 et 12. Vous aurez certainement noté qu’elles correspondent exactement au scénario du déploiement initial de votre application. La petite différence se situe au niveau des étapes de création du schéma de la base de données. On peut enfin noter que les étapes 1 à 6 permettent de désinstaller complètement l’application.

Résumons maintenant les avantages et inconvénients des deux scénarii.

Du pour et du contre

Dans le cas du déploiement incrémental, on peut retenir les points suivants :

• Pour : Le déploiement incrémental s’exécute très vite car il fait le strict minimum.
• Contre : Le déploiement incrémental laisse éventuellement des traces de modifications manuelles. Ce point est problématique car la configuration a pu être changée de manière « magique » et sûrement non documentée pour que l’application fonctionne. Si vous décidez de migrer sur un autre serveur, vous oublierez probablement ces petites retouches. Et par-dessus tout, nous pouvons imaginer que si cela a été fait sur un des serveurs, et bien … je vous laisse compléter la phrase. :-)
• Pour : Le déploiement incrémental ne touche pas aux systèmes qui sont normalement OK. Mais encore une fois, si vous craignez de toucher votre système parce que ça pourrait ne plus fonctionner du tout, vous avez du travail. Il faut avoir suffisamment confiance dans les composants de votre environnement pour ne pas avoir peur de faire un changement, de redémarrer le serveur et enfin de prier pour que ça re-fonctionne correctement.
• Contre : Il est plus difficile de faire un retour arrière avec un déploiement incrémental. Pour chaque déploiement incrémental, il est nécessaire de décrire le scénario de retour arrière. En effet, comme le précédent déploiement était aussi incrémental, on ne peut donc pas le relancer. Sans scénario de retour arrière, la seule façon de revenir à v1.3 est de faire un déploiement « propre » de v1.0 est de déployer successivement v1.1, v1.2 et enfin v1.3.

A présent, voyons un peu ce que le redéploiement complet apporte comme solutions mais aussi comme difficultés :

• Pour : Le redéploiement complet efface toutes modifications manuelles, ne laissant que la configuration « bien » documentée en place.
• Pour : Le redéploiement complet est reproductible et prévisible. Grâce aux procédures qui sont systématiquement les mêmes, il n’y a aucune importance à connaitre ni la partie du produit qui a changé, ni l’état actuel de l’environnement cible. Ca sera toujours le même résultat.
• Pour : Le redéploiement complet permet d’avoir une stratégie de retour arrière extrêmement simple. Quand le déploiement d’une nouvelle version échoue, ou que la nouvelle application ne fonctionne pas, il suffit de déployer la version précédente.
• Contre : Conserver l’application disponible pendant le déroulement d’un redéploiement complet est une affaire plus délicate que pour un déploiement incrémental. Pour avoir une application en haute disponibilité, il est indispensable de configurer un cluster.
• Contre : Un redéploiement complet peut s’exécuter lentement si l’environnement cible n’est pas assez rapide, car le nombre d’opérations de configuration est important.

Déploiement incrémental, plus sûr que le redéploiement complet ?

Pour ma part, même si le redéploiement complet est parfois plus difficile et plus long à mettre en œuvre, le fait qu’il soit prévisible et reproductible est un avantage décisif qui fait passer les inconvénients au second plan. Le déploiement incrémental peut sembler être une approche plus simple et plus rapide pour déployer des mises à jour, mais vous sacrifiez ce qui est essentiel pour un scénario de déploiement, le processus de retour arrière. L’unique cas où le déploiement incrémental est indispensable, c’est lorsqu’on met à jour une base de données. Dans tous les autres, il est recommandé d’utiliser le redéploiement complet pour appliquer des changements.

Traduction libre du billet « Incremental deployments vs. full redeployments » publié par Vincent Partington sur blog.xebia.com.