Defectos de producto

El servicio de soporte a las suscripciones de Liferay busca resolver funcionalidades no deseadas, también conocidas como defectos del producto, a través de parches o cambios de configuración de Liferay Digital Experience Platform, Liferay Portal EE y Liferay Commerce (“el producto”). Las incidencias reportadas por los clientes deben ser reproducidas por el servicio de soporte en una instancia de producto no personalizada. Algunas incidencias reportadas (p. ej. incidencias del API) se pueden verificar y reproducir con un mecanismo de comunicación específico.

Por favor consulta las siguientes secciones para revisar las políticas detalladas:

Liferay Commerce

Commerce 2.x y anteriores

Los parches de emergencia para Liferay Commerce se pondrán a disposición del cliente en la última micro versión de la versión menor del cliente. Se podrá requerir al cliente que se migre a la última versión menor disponible para poder recibir una versión de mantenimiento.

Las versiones de Liferay Commerce y los fix packs de DXP deben actualizarse de manera conjunta, ya que ambas versiones son de mantenimiento. Cuando se actualiza a un fix pack de DXP, la mejor práctica es actualizar a la última micro versión de Liferay Commerce. Cuando se actualiza Liferay Commerce, la mejor práctica es actualizar al último fix pack disponible.

Funcionalidad deseada

Cualquier comportamiento o incidencia, que entre en conflicto con las funcionalidades deseadas del producto, se podrá resolver a través de parches o cambios en la configuración del producto. La documentación oficial del producto determina su funcionalidad.

Liferay busca comunicar de manera clara la evolución, los cambios rupturistas (breaking changes) y la desaparición de las funcionalidades deseadas. La política de mantenimiento y desaparición de funcionalidades facilita una guía sobre las mismas en el producto.

Incidencias del API de Liferay

Si un punto en el código del producto impide tus desarrollos, entonces nuestros ingenieros de soporte te pueden ayudar a verificar si es una incidencia del producto de Liferay. Cuando informes de la incidencia, por favor, facilitanos información clara sobre el API concreto. Esto incluye su comportamiento esperado y el observado y una aplicación o script simple que demuestre el problema (si es posible).

Liferay procura resolver las incidencias acorde con la funcionalidad deseada del producto. Puede ser necesario que cambies algún desarrollo personalizado que potencia una funcionalidad no intencional. 

Si la funcionalidad deseada se reporta como una incidencia del API de Liferay, el equipo de soporte explicará el uso de la funcionalidad a través del código del producto, documentación de soporte o un simple ejemplo. Con las incidencias en el API la funcionalidad deseada no sólo se define en la guía oficial de administradores, sino también en javadocs y en el servicio web de JSON. Para obtener más información puedes revisar los artículos de la biblioteca técnica relativos a la documentación del API.

Las políticas sobre el desarrollo de código y la asistencia con la arquitectura también son guías para la resolución de incidencias reportadas sobre el API de Liferay. 

Contacta con tu Account Executive o tu Customer Experience Manager para comentar las opciones disponibles para obtener asistencia con tus desarrollos personalizados.

Reproducción y resolución de incidencias

Una vez reportadas, las incidencias entran en el proceso de diagnóstico. Durante este proceso, el equipo de soporte investiga la incidencia, tratando de reproducirla, para poder proporcionar una resolución. El equipo de soporte debe primero reproducir, en una versión de producto sin personalizar, cualquier incidencia reportada. Las incidencias que resulten de la personalización del producto son responsabilidad del cliente. Las incidencias que el equipo de soporte de Liferay no pueda reproducir permanecerán en la fase de diagnóstico y se resuelven caso por caso. Las incidencias que están fuera de la cobertura del servicio de soporte permanecerán en la fase de diagnóstico y se resolverán caso por caso. Tu Account Executive o Customer Success puede ayudarte con incidencias que no están incluidas bajo los servicios de soporte a las suscripciones. 

Liferay busca resolver los defectos no intencionados y reproducibles, en versiones no personalizadas del producto, a través de parches o de cambios en la configuración acordes a la política del ciclo de vida del producto. Los parches cambian el código del producto. El equipo de soporte puede facilitar documentación de los cambios en el código junto con el parche. Se requiere que los clientes prueben el parche para asegurarse que resuelve la incidencia, e informen, de manera oportuna, al equipo de soporte de los resultados obtenidos. Antes de instalar un parche, el cliente debe realizar una copia de seguridad de su sistema (p. ej. código, archivos, base de datos). Para verificar que el parche no entra en conflicto con ningún desarrollo personalizado, el cliente debe instalar el parche en un entorno no productivo primero. Los clientes son responsables de cualquier incidencia que surja en sus desarrollos personalizados como resultado de la resolución de un defecto de producto.

Actualizaciones de emergencia (Hotfixes)

Las actualizaciones de emergencia, también conocidas como hotfix, se proporcionan caso por caso para los componentes de Liferay que se despliegan en los entornos de producción.

Las actualizaciones de emergencia se pondrán a disposición del cliente de manera acorde a la severidad e impacto del defecto del producto, el ciclo de implementación del cliente y la fecha de publicación del Fix Pack, Service Pack, o versión trimestral en el entorno afectado. Las actualizaciones de emergencia se entregarán para resolver defectos que causen incidencias catastróficas a nivel de negocio, según lo determine Liferay. También se entregarán para limitar la cantidad de cambios a realizar en un entorno de producción funcional, cuando dicho entorno esté afectado.

Por último, las actualizaciones de emergencia de las versiones trimestrales se entregarán, bajo demanda, para versiones que se hayan publicado en los últimos 365 días, determinados por la fecha en la que se informó de la incidencia a Liferay y la fecha en la que se publicó la versión trimestral. Para este propósito, una versión se define como una nueva versión trimestral publicada como un bundle o un archivo war con dependencias de OSGi, o una imagen de Docker facilitada por Liferay que incluya una nueva versión trimestral.

La fecha original de publicación de una versión trimestral se utilizará para determinar la antigüedad de la versión y su elegibilidad para proporcionar una actualización de emergencia. Una imagen de Docker nueva, provista por Liferay, que contenga cambios en los scripts de Liferay, sistema operativo, u otra tecnología interoperativa, pero que no incluya un cambio en la versión trimestral, no se considera como una nueva versión.

Mantenimiento a través de reinicios ordenados (rolling restart)

Muchos clientes implementan reinicios ordenados con el deseo de incrementar el tiempo útil y la disponibilidad de sus instalaciones. Los reinicios ordenados permiten a los clientes tener casi un 100% de disponibilidad, a pesar de realizar el mantenimiento de los servidores, mediante el apagado selectivo de una instancia JVM en un clúster, llevando a cabo las labores de mantenimiento necesarias de la instancia para luego añadirla al clúster tras su reinicio. Este proceso se repite hasta que todos los nodos de un clúster han sido actualizados. 

Definición de la cobertura 

  1. Liferay busca asegurar que Liferay DXP es compatible con las prácticas de reinicios ordenados aceptadas por la industria para modificar las propiedades del portal, instalar y desinstalar fix packs, instalar nuevos plugins o módulos, actualizar los plugins y módulos existentes y actualizar versiones menores de java, siempre que estas funciones cumplan con los requisitos de los reinicios ordenados. 
  2. Liferay busca asegurar que Liferay DXP es compatible con las prácticas de reinicios ordenados aceptadas por la industria hasta el punto que el producto es mínimamente funcional y capaz de responder a peticiones limitadas durante la ventana de mantenimiento definida. Mínimamente funcional se define, caso por caso, por el equipo de producto de Liferay. 
  3. Liferay recomienda mitigar el riesgo de las actualizaciones de los entornos de producción a través de los reinicios ordenados, en vez de con despliegues en caliente. No obstante, la  viabilidad e implementación de la técnica de los reinicios ordenados en un entorno específico debe ser responsabilidad del cliente.
  4. El equipo de soporte puede ofrecer asistencia determinando si la actualización de un producto de Liferay cumple los requisitos de un reinicio ordenado. 
  5. La consecución exitosa de la técnica de reinicio ordenado incluye la interoperabilidad de múltiples tecnologías de terceros. La configuración de tecnologías de terceros, necesaria para realizar un reinicio ordenado en un clúster, es responsabilidad del cliente.

Requisitos de un reinicio ordenado

Para que cualquier labor de mantenimiento, realizada a través de la técnica de reinicio ordenado, sea compatible con Liferay DXP, debe cumplir los siguientes requisitos.

Instalación de Fix Pack 

La instalación de fix pack, utilizando la técnica de reinicio ordenado, es segura porque es compatible con Liferay DXP, siempre que el fix pack sea reversible y que no haya fix packs no reversibles entre el fix pack actualmente instalado y el fix pack que se quiere instalar. Los fix packs que se encuentran, o se van a incluir, en un service pack contienen cambios irreversibles en la base de datos. Estos fix packs se identificarán como irreversibles en el portal del cliente y tendrán documentación del tipo cambios importantes asociada a ellos o estarán documentados en los artículos Reinicio ordenado - Cambios rupturistas (breaking changes) de la biblioteca técnica.

Normalmente los fix packs irreversibles terminan con un 0. No todos los service packs contienen fix packs irreversibles, pero muchos sí lo hacen.

Plugins o módulos nuevos

El despliegue de plugins o módulos nuevos, mediante la técnica de reinicio ordenado, es segura porque es compatible con Liferay DXP, siempre que los plugins o módulos no borren o renombren ninguna columna de la base de datos o modifiquen los datos de manera que rompan la compatibilidad con versiones existentes. Cualquier actualización que borre tablas o rompa la compatibilidad debe de realizarse con todos los nodos del clúster parados.

Actualización de Plugins o módulos

Actualizar plugins o módulos ya desplegados, mediante el uso de la técnica de reinicio ordenado, es segura porque es compatible con Liferay DXP, siempre que los plugins o módulos no borren o renombren ninguna columna de la base de datos o modifiquen los datos de manera que rompan la compatibilidad con versiones existentes. Cualquier actualización que borre tablas o rompa la compatibilidad debe de realizarse con todos los nodos del clúster parados.

Existen técnicas de desarrollo que pueden adaptar cambios en el esquema de la base de datos mientras utilizan la técnica del despliegue ordenado (p.ej. despliegue tipo blue-green). Los productos de Liferay no utilizan dichas técnicas de desarrollo ya que requieren cambios menores, conforme avanza el tiempo, aplicados en un orden específico y Liferay no puede garantizar que las versiones de producto se apliquen en el orden adecuado.

El despliegue tipo blue-green puede tener lugar en desarrollos personalizados, sin impactar la funcionalidad del software de Liferay. Por favor, consulta con tu Account Executive o Customer Experience Manager para explorar las opciones relacionadas con la asistencia al desarrollo.

Actualización de versiones de Java 

La actualización de una instalación de Java JDK, utilizando la técnica de reinicio ordenado, es segura porque es compatible con Liferay DXP, siempre que la versión que se incrementa sea una versión menor. Actualizar a una versión mayor de la instalación de Java JDK que la usada por Liferay no se asegura que sea compatible con la técnica de reinicio ordenado y debe ser realizada mientras todos los nodos en el clúster estén parados.

¿Fue útil este artículo?
Usuarios a los que les pareció útil: 4 de 5