Liferay france symposium 2012 - montée de version d’une instance liferay

1,197 views

Published on

Les montées de version du produit sont des étapes critiques dans la vie d'une application basée sur Liferay. Le portail Liferay fournit nativement des mécanismes efficaces pour mettre à jour sans difficultés la structure et les données de la base de données Liferay standard, mais une attention importante doit être portée à la migration des données et développements spécifiques, tout particulièrement pour les plugins de type « hook » et les plugins de type « ext ». Pendant cette session, les auditeurs ont bénéficié de retours d'expérience terrain et ont prise connaissance de patterns et d'astuces utiles pour assurer une montée de version en évitant les régressions et en maîtrisant la charge engagée.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,197
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Liferay france symposium 2012 - montée de version d’une instance liferay

  1. 1. Montée de versiond’une instance LiferayLes clés du succèsSébastien Le MarchandExpert Technique – SQLI Group
  2. 2. SQLI - Un modèle intégré avec 5 métiers SOLUTION | PROGICIELS | AGENCE DIGITALE | CONSEIL | INGÉNIERIE Aller de l’idée à l’accompagnement du changement Partenaire de LiferayConseil / intégration / accompagnement à la mise en place de portails collaboratifs UNE STRUCTURE INTERNATIONALE 1800 collaborateurs CA 165 M€
  3. 3. AgendaEtat des lieux et enjeuxMise à jour des développements spécifiques En amont : réaliser des développements facilitant la mise à jour Méthode de mise à jour des portions de code issues de la version précédenteProblématiques avancées liées aux données Réaliser une procédure de mise à jour de données spécifique Migration de données multi-sourcesConclusion
  4. 4. Etat des lieux et enjeux
  5. 5. Les ingrédients d’une montée de version… Mise à jour d’une instance = Mise à jour de la configuration + Mise à jour logiciel standard + Mise à jour standard des données + Mise à jour logiciel spécifique + Mise à jour spécifique des données
  6. 6. … et la recette1) Préparation Adapter la configuration à la nouvelle version Adapter les développements spécifiques à la nouvelle version2) Déploiement Installer une instance vierge dans la nouvelle version Installer les plugins spécifiques (développements & configuration) Connecter l’instance aux données existantes (DB + FS) Démarrer…  Liferay met à jour automatiquement les données
  7. 7. Plus de détails Suivant les versions source et destination, il peut y avoirdes spécificités dans la procédure : toujours se référer à laprocédure officielle communiquée par Liferay Les montées de version vers les service packs peuventêtre évitées par l’usage des “Hotfixes” Les fichiers portal-legacy-*.properties facilitentl’adaptation de la configuration L’adaptation des développements spécifiques représenteen général l’essentiel de l’effort à fournir
  8. 8. Mise à jour desdéveloppements spécifiques
  9. 9. Quels développements spécifiques ? Plugins “Portlet” Mise à jour Plugins “Theme” = 1. Build  correction erreurs 2. Deploy  correction erreurs Plugins “Layout Template” 3. Test  correction erreurs Plugins “Web” Mise à jour Plugins “Hook” = 1. Inspection et adaptation du Plugins “Ext” code source 2. Build  correction erreurs 3. Deploy  correction erreurs 4. Test  correction erreurs
  10. 10. Hook & Ext : comment faciliter etsécuriser la mise à jour en amont ?Bonnes pratiques pour la réalisation de développementsspécifiques : Faire la chasse aux copier-collers qui devront être migrés Isoler et délimiter les développements spécifiques
  11. 11. Inclusion de la JSP originale Pour des ajouts avant et/ou après le code original Exemple : ajouter un bandeau en tête de la portlet de login Code spécifique Code spécifique Code original <%@ include file= "login.portal.jsp" %>/html/portlet/login/login.jsp
  12. 12. Faire usage de l’héritage de classe Concerne essentiellement les plugins “Ext” Exemple : classe com.liferay.portal.util.PortalImpl PortalImpl <bean id="com.liferay.portal.util.PortalUtil" class=" ..."> <property name="portal"> +getHomeURL() <bean class=“....CustomPortalImpl" /> </property> </bean> CustomPortalImpl ext-spring.xml +getHomeURL()
  13. 13. Faire usage de l’introspection Pour accéder depuis un plugin à une classe du portail AssetUtil << introspection >> AssetUtil portal-impl.jar ROOT.war monplugin-hook.war PortalClassInvoker portal-service.jar Procédé déjà utilisé nativement • com.liferay.portal.kernel.util.PrefsPropsUtil • com.liferay.portal.kernel.util.PropsUtil • …
  14. 14. …encore un peu plus d’introspection Pour accéder à une méthode privéeClass clazz = … ;java.reflect.method m = clazz.getDeclaredMethod(…);…m.setAccessible(true);m.invoke(…); L’abus d’introspection peut êtredangereux pour votre application
  15. 15. Délimiter le code spécifique Délimiter le code spécifique <!-- BEGIN CUSTOM CODE -->par des blocs de commentaires … • Ajouts … • Modifications <!-- END CUSTOM CODE --> • Suppressions Déporter les blocs de tailleimportante dans des fichiers <!-- BEGIN CUSTOM CODE -->JSPF <%@ include file="mypage.jspf" %> <!-- END CUSTOM CODE -->
  16. 16. Préserver le code issue de Liferay Des copier-collers de code depuis Liferay resteront toujoursinévitables dans certains cas • Dans certaines JSP • Dans certaines méthodes redéfinies Ces portions de code  Ne doivent pas être reformatées  Ne doivent pas être refactorées  Doivent être délimitées par des commentaires (pour les classes Java)
  17. 17. Méthode de mise à jour et outils Mettre en regard • Le fichier natif de la version source • Le fichier modifié à partir de la version source • Le fichier natif de la version cible Des outils adaptés • WinMerge • MeId • Kdiff3 • Araxis Merge • … Adopter une méthode systématique • Plusieurs approches possibles
  18. 18. Exemple avec WinMerge
  19. 19. Problématiques avancées liées aux données
  20. 20. Mise à jour spécifique des données Des données spécifiques peuvent être dépendantes d’uneversion de Liferay Exemple : préférence de portlet référençant une imagedans Liferay 6.0 Possibilité d’implémenter des “upgrade process” au seindes plugins spécifiques
  21. 21. Migration de données multi-sources Plusieurs instances Liferay sources en version X Une instance Liferay cible en version Y Procédure 1. Montée de version sur chaque instance source 2. Export des données concernées au format LAR 3. Import des fichiers LAR Problématiques périphériques • Dates de création et de modification • Identité des utilisateurs
  22. 22. Conclusion
  23. 23. Pour bien aborder ses montées de version Réduire au maximum certains développements spécifiques Appliquer des bonnes pratiques lors de la réalisation desdéveloppements Trouver le bon rythme • Evaluer les avantages de chaque montée de version potentielle • Considérer les Hotfixes • Ne pas attendre jusqu’à devoir faire un saut de géant (4.3  6.1) Suivre les procédures communiquées par Liferay Gérer chaque montée de version comme un vrai projet
  24. 24. Merci ! Des questions ?Sébastien Le Marchand SQLI Groupslemarchand@sqli.com www.sqli.com@slemarchand www.entreprise-collaborative.fr

×