Le gestionnaire des éditions d'application vous permet de gérer différentes versions et éditions de votre application. La présente rubrique décrit la différence entre une version et une édition du gestionnaire des éditions d'application, la méthode de mise à niveau de l'application, la validation et la compatibilité des éditions.
Une version est une génération successive d'une interface, d'une fonction, d'une implémentation, d'une application toute entière, ou autre. Il s'agit d'un concept lié au développement et à la génération. Une édition est une génération de déploiements successifs, par exemple le déploiement d'un ensemble particulier d'artefacts versionnés. Il s'agit d'un concept lié au déploiement et à l'exploitation. Ces termes permettent de différencier plus clairement les opérations qui s'exécutent dans l'environnement de développement et de génération de celles qui s'exécutent dans l'environnement de déploiement et d'exploitation.
De nombreuses applications d'entreprise doivent être disponibles en permanence. Les types de configuration de WebSphere Application Server qui offrent une disponibilité permanente sont documentés dans le centre de documentation de déploiement réseau de Websphere Application Server et dans d'autres sources, notamment les Redbooks IBM. Au sujet de la disponibilité de l'application, la norme recommande de déployer les applications sur des clusters de serveurs d'applications. Il est essentiel qu'un cluster soit redondant pour assurer une disponibilité permanente.
On appelle Mise à niveau des applications sans interruption la capacité à mettre à niveau une application tout en conservant sa disponibilité permanente. Les utilisateurs de l'application n'observent pas de perte de service lors de la mise à niveau.
L'édition d'application désigne un déploiement unique d'une application particulière. Dans l'environnement d'administration de WebSphere Application Server, une édition d'application est une application qui n'est identifiée que par la combinaison d'un nom d'application et d'un nom d'édition. Plusieurs éditions de la même application ont le même nom d'application mais des noms d'édition différents. Le nom d'édition peut être numérique, comme 1.0 ou 2.0, ou il peut être descriptif, comme première édition ou édition bleue.
L'édition de base désigne une application déployée qui ne comporte aucune information d'édition associée. Par exemple, les applications installées avant l'ajout de la prise en charge du gestionnaire des éditions dans votre cellule WebSphere Extended Deployment s'affichent dans le gestionnaire des éditions en tant qu'éditions de base.
L'Activation d'édition distingue deux états possibles pour une édition d'application. La première fois que vous installez une édition, elle est à l'état inactif. Une édition inactive ne peut pas être démarrée. Une action explicite est requise pour placer une édition à l'état actif. Une édition à l'état actif ne peut pas être démarrée. Le passage de l'état inactif à l'état actif est appelé activation.
On parle d'Activation simultanée lorsque plusieurs éditions de la même application sont actives et démarrent simultanément.
Des éditions actives concurrentes peuvent permettre à certains utilisateurs d'accéder à une édition et à d'autres utilisateurs d'accéder à une autre édition. Par exemple, si vous lancez une nouvelle édition d'une application, vous voudrez peut être qu'un groupe d'utilisateurs la teste, sans que tous les utilisateurs y aient accès. Avec une activation simultanée, vous devez établir une règle de routage pour distinguer les utilisateurs qui ont accès à une édition. Une règle de routage évite les ambiguïtés et détermine l'édition qui doit recevoir le contrôle. Voici un diagramme d'activation simultanée :
WebSphere Extended Deployment fournit des règles de routage d'application. Une règle de routage est stockée parmi les métadonnées de configuration d'une application. Une règle de routage permet de formuler les règles d'instruction de l'ODR (on demand router) pour qu'il envoie des demandes d'application spécifique à une édition donnée, en fonction de certains critères. Vous pouvez utiliser différents critères pour spécifier les demandes envoyées à une édition d'application données. Cela permet d'envoyer les demandes de certains utilisateurs à une édition et les demandes d'autres utilisateurs à une autre édition.
On entend par Déploiement d'édition le déploiement et l'activation d'une édition d'application sur un cluster de serveurs. Pour fournir des mises à niveau d'application sans interruption, le déploiement d'application consiste à mettre au repos les demandes de l'application sur un serveur donné, bloquer la réception de nouvelles demandes sur ce serveur, interrompre l'édition active en cours, démarrer la nouvelle édition, et reprendre le flux des demandes vers cette édition. Le déploiement d'édition sur un cluster des serveurs exéute ces opérations sur tous les serveurs du cluster.
Le Déploiement de groupe remplace une édition pour les membres d'un cluster cible dans un groupe. Pendant le déploiement de groupe, les demandes peuvent être prises en charge par l'ancienne ou par la nouvelle édition, jusqu'à ce que le remplacement soit terminé. Le déploiement de groupe permet une mise à niveau simultanée des serveurs à la nouvelle édition. Chaque serveur du groupe est mis au repos, purgé, arrêté et réinitialisé. Seul un groupe peut être déployé à la fois sur la console d'administration. Sinon, pour déployer plusieurs groupes, vous pouvez utiliser des scripts.
Lors du déploiement de groupe, l'ancienne et la nouvelle édition coexistent pendant certaines périodes de temps et desservent en même temps les demandes des utilisateurs. Lorsque le déploiement d'édition se produit, certains serveurs du cluster sont déjà passés de l'ancienne édition à la nouvelle édition, certains serveurs sont en train d'effectuer la transition, et d'autres serveurs n'ont pas encore commencé la transition. A moins qu'une règle de routage ne soit imposée, les demandes d'application sont envoyés sur tous les serveurs sur lesquels une instance d'une édition de l'application demandée est active et en cours d'exécution. Par exemple, lorsque vous réalisez le déploiement de l'édition 1.0 à 1.1, les demandes d'application peuvent être desservies soit par l'édition 1.0 ou l'édition 1.1 jusqu'à ce que le déploiement soit terminé.
Voici un diagramme de déploiement de groupe :
L'option de déploiement isolé remplace une édition par moitié de cluster à la fois de sorte que toutes les demandes d'utilisateur soient desservies au moyen d'une édition cohérente de l'application. A tout point de cette période, toutes les demandes d'utilisateur sont desservies soit par l'ancienne, soit par la nouvelle édition, mais jamais l'une ou l'autre.
Le déploiement isolé garantit que toutes les demandes d'application sont desservies par une édition cohérente, par exemple, l'édition 1.0 ou 1.1, mais pas les deux éditions. L'édition disponible en cours est mise hors ligne sur la moitié des serveurs que comprend le cluster. Sur ces serveurs, la nouvelle édition est activée et démarrée, mais les serveurs sont maintenus hors ligne jusqu'à l'achèvement de l'étape suivante, qui consiste à déployer l'édition active courante hors ligne sur le reste des serveurs. Dès lors, aucun serveur ne dispose plus d'une instance de l'une ou l'autre édition pour desservir les demandes d'application. A cet instant, l'ODR met provisoirement en file d'attente toutes les demandes reçues pour cette application. Une fois l'application entièrement remise en ligne, la première moitié du cluster est remise en ligne. La seconde moitié du cluster passe de l'ancienne à la nouvelle édition et est remise en ligne.
Voici le diagramme d'un déploiement isolé :
La Validation d'édition désigne un cas spécial d'activation simultanée, au cours duquel la cible de déploiement attribuée d'une édition, par exemple, un cluster dynamique, est dupliquée et l'on prépare le démarrage de l'édition sur cette cible de déploiement dupliquée. La cible de déploiement dupliquée est appelée cible de validation. Des règles de routage doivent être utilisées pour désigner les demandes d'application qui doivent être envoyées à l'édition en cours de validation. Lorsqu'une édition est en cours de validation, elle est en mode validation.
Le mode validation vérifie que la nouvelle édition d'une application fonctionne dans son environnement de production sans mettre hors ligne l'édition courante disponible. Généralement, un test est envoyé à une édition en mode validation pour confirmer que les aspects d'environnement et de configuration de l'application, tels que la connectivité et l'accès à la base de données, fonctionnent comme prévu. Lors du déploiement du mode de validation d'une édition, le déploiement a lieu sur la cible de déploiement où l'édition était installée à l'origine. Cela entraîne l'édition à quitter le mode validation. Lors de l'arrêt du mode validation, la cible de validation est supprimée.
Voici un exemple de diagramme de validation :
Certaines modifications de l'application sont transparentes pour les utilisateurs mais d'autres ne le sont pas. Lorsqu'une mise à niveau d'application fournit les mêmes interfaces de programmation, au minimum, que la dernière modification, et qu'aucune modification sémantique n'a été apportée au comportement essentiel, cette mise à jour est qualifiée de compatible en amont. Les utilisateurs existants peuvent utiliser l'application mise à niveau sans modification de l'environnement, et ne verront pas de différence entre l'ancienne édition et l'édition courante.
Une mise à niveau d'application qui impose aux utilisateurs de modifier leur utilisation de l'application est une mise à niveau incompatible. Il peut s'avérer nécessaire de supprimer une fonction antérieure, ou de modifier des interfaces, pour améliorer la capacité de maintenance ou d'autres paramètres, ce qui peut apporter des modifications non compatibles à votre environnement de déploiement. Les modifications non compatibles doivent être planifiées avec soin afin de gérer leur incidence sur les utilisateurs existants.
Related concepts
Gestionnaire des éditions d'application
Related tasks
Tutoriel du gestionnaire des éditions
Related reference
Etats d'édition