Migración a Liferay DXP

La actividad de la compañía se centra en el diseño, fabricación, instalación, mantenimiento y modernización de ascensores, escaleras mecánicas, rampas y pasillos. Está formada por más de 30 empresas en España, Portugal, Francia, Reino Unido, Irlanda, Bélgica, Países Bajos, Luxemburgo, Noruega, Brasil y Polonia.

Desde Zylk.net, como partner especializado en desarrollos bajo tecnologías Liferay, se lideró la migración del portal de la Extranet de la compañía a Liferay DXP en su versión 7.0. Este portal multiinstancia, multisite y multidioma, con contenidos en castellano, inglés, francés, alemán y holandés aloja 4 instancias formada por múltiples sitios. Cada instancia tiene una orientación específica:
    • Una instancia orientada para ser el entorno de comunicación con el cliente.
    • Una instancia dedicada a la red de innovación de la compañía.
    • Una instancia dedicada a alojar aplicativos y funcionalidades orientada al personal del grupo de la companía.
    • Una instancia dedicada al intercambio de información con los proveedores.

Inicialmente, se identificaron aquellas tareas de proyecto que pudieran ser bloqueantes y/o que provocasen incertidumbre en el proyecto. Aparecieron tres tareas claves:

    • La necesidad de que los equipos que realizan desarrollos en la compañía puedan realizar evolutivos sin tener que depender del avance del proyecto. 
    • Dado que el Portal de la compañía, utilizaba en su versión 6.2 el sharding, surgió el reto ofrecer una solución que unificase los 4 shards en un único shard. El sharding de la base de datos es una singularidad no soportada en Liferay DXP 7.0
    • Identificar aquellos desarrollos que pueden seguir funcionando mediante la capa de compatibilidad que ofrece Liferay DXP y aquellos que necesitan ser migrados a módulos OSGi.

Se desplegó una infraestructura de desarrollo paralela para evitar interrumpir y/o bloquear a los diferentes equipos que se encargan de evolucionar los desarrollos de la Extranet. La infraestructura está basada en proyectos de software libre como SVN, Maven, Gradle y Jenkins. Uno de los retos del proyecto, y en todo upgrade del producto, es cómo organizar a los proyectos existentes y empresas desarrolladoras mientras sigue su ciclo de vida de desarrollo el Liferay 6.2.

Dado que Liferay DXP 7.0 no soporta el sharding en la base de datos, se trazó, junto con el equipo de Soporte de Liferay, un pre-proceso del upgrade para poder adaptar el Liferay Portal 6.2 con sharding a un Liferay Portal 6.2 sin sharding (con un único shard). Esta pre-proceso estaba formado por tres fases:
    • Una primera fase que consistía en la unificación de shards a través de unos scripts genéricos e independientes del entorno donde se lanzaban. De tal forma que se conseguía fusionar todas las tablas de los 4 shards. 
    • Una segunda fase que consistía en levantar el Liferay Portal 6.2 apuntando a la nueva base de datos con un único shard.
    • Una tercera fase que consistía en validar junto con los usuarios que no se hayan perdidos datos durante la primera fase.

Una vez superado el pre-proceso de upgrade para unificar los shards en uno, se trazó el procedimiento para migrar los tres entornos (desarrollo, preproducción y producción) a Liferay DXP 7.0 mediante el proceso de upgrade definido por Liferay. 
Para entrenar el procedimiento de upgrade del core de Liferay DXP, en los tres entornos se utilizaron los datos de producción. En total, el proceso de upgrade del CORE se executó en cuatro ocasiones:
    • En el entorno de desarrollo.
    • En el entorno de preproducción.
    • En el entorno de producción. Esta iteración tenía como objetivo, entrenar la máquina de producción y anticipar potenciales problemas con la máquina o la conectiviadad a los servicios externos.
    • La segunda y definitiva iteración en el entorno de producción.

El stack utilizado está certificado por Liferay, y utiliza Red Hat como sistema operativo, Jboss como servidor de aplicaciones, Elastic Search como motor de indexación y búsquedas y Oracle como base de datos relacional.

La estrategia para la migración de los desarrollos consistió en identificar qué desarrollos podían seguir funcionando en modo compatibilidad y qué desarrollos que, por su idiosincrasia, debían ser migrados a módulos OSGi (temas y proyectos de tipo service builder). El modo compatibilidad permite mantener la misma estructura del proyecto sin necesidad de migrar el portlet a OSGi cambiando las referencias a las nuevas APIs  de Liferay. 

Los temas hubo que actualizarlos a Gradle mediante el uso de Yeoman, que forman parte de las recomendaciones de Liferay. Los estilos CSS se vieron afectados por los cambios en la estructura de la página en versión DXP. El uso de las librerías Bootstrap 3 así como del Automatic Single Page (SPA) en Liferay DXP requirió también de algunas adaptaciones.

La utilización de módulos OSGI en los portlets también precisó de ciertos cambios, como por ejemplo, a la hora de hacer un portlet configurable en Liferay DXP. La adopción de una arquitectura OSGI incorpora muchas ventajas al producto, pero va a requerir de numerosos cambios en aquellos proyectos de upgrade entre versiones 6.2 y 7.x, que tengan muchos componentes personalizados y desarrollados.

La puesta en producción se realizó de forma fluida, controlada y sin contratiempos, bajo un estricto trabajo de revisión y validación, con un portal bajo Liferay DXP equivalente en lo que a funcionalidad y apariencia se refiere. Debido a los cambios introducidos en la arquitectura del producto en la versión DXP, a una arquitectura OSGI modularizada, esto supuso un reto considerable.

Actualmente, en el portal de la Extranet de la compañía, residen varios sitios web con varios desarrollos (entre temas, portlets y extensiones de Liferay hay entorno a 30 proyectos) desarrollados con diferentes frameworks como (MVC, Service Builder, Spring MVC…) así como diferentes herramientas de automatización de tareas (Maven y Gradle).