Si se conoce la diferencia entre las versiones y ediciones del gestor de ediciones de aplicaciones, los métodos de despliegue y actualización de la aplicación y la validación y compatibilidad de ediciones, podrá utilizar por completo el gestor de ediciones de aplicaciones para gestionar los despliegues de la aplicación.
Las aplicaciones web no gestionadas pueden definirse con una edición. Sin embargo, no se puede realizar un despliegue en ellas, ni se pueden colocan en la modalidad de validación. Están soportadas, pero no todas las prestaciones están disponibles para ellas debido a que son aplicaciones de gestión de ciclo de vida asistido.
Los términos versión y edición distinguen entre lo que sucede en el entorno de desarrollo y creación de lo que sucede en el entorno de despliegue y operativo. Una versión es una generación sucesiva de una interfaz, función, implementación o aplicación completa, etc. La versión es un concepto de desarrollo y de creación.
Una edición es una generación sucesiva de despliegue, por ejemplo, el despliegue de un conjunto determinado de artefactos con versión. Una edición es un concepto operativo y de despliegue.
Edición de la aplicación
La edición de la aplicación es un despliegue único de una aplicación en particular. En el entorno administrativo de WebSphere Application Server, una edición de aplicación es una aplicación que se identifica de forma exclusiva a través de la combinación de un nombre de aplicación y un nombre de edición. Varias ediciones de la misma aplicación tienen el mismo nombre de aplicación, pero nombres de edición distintos. El nombre de edición puede ser numérico como, por ejemplo, 1.0 o 2.0, o el nombre puede ser descriptivo como, por ejemplo, primera edición o edición borrador.
Edición base
La edición base se refiere a una aplicación desplegada que no tiene ninguna información de edición asociada. Por ejemplo, las aplicaciones que se instalan antes de agregar el soporte del gestor de ediciones de aplicaciones en la célula del producto se visualizan en el gestor de ediciones de aplicaciones como ediciones base.
Activación de la edición
La activación de la edición distingue entre dos estados en los que podría existir una edición de la aplicación. Cuando se instala una edición por primera vez, la edición está en el estado inactivo. Puede iniciar la edición sólo cuando está en el estado activo. La transición de inactiva a activa se denomina activación.
Activación simultánea
La activación simultánea existe cuando varias ediciones de la misma aplicación están activas e iniciadas de forma simultánea. Las ediciones activas simultáneamente pueden proporcionar a unos usuarios el acceso a una edición y a otros el acceso a otra. Por ejemplo, si presenta una nueva edición de una aplicación, es probable que desee seleccionar un grupo de usuarios para probar la edición y no desee que todos los usuarios tengan acceso a la edición. Con la activación simultánea, debe establecer una política de direccionamiento para distinguir qué usuarios tienen acceso a una edición. Se guarda una política de direccionamiento como parte de los metadatos de configuración para una aplicación. Además, una política de direccionamiento evita la ambigüedad y determina qué edición recibe el control. El siguiente ejemplo es un diagrama de ediciones activas de forma simultánea.
Muchas aplicaciones de empresa requieren una disponibilidad constante. El estándar de disponibilidad de aplicaciones afirma que las aplicaciones se despliegan en clústeres de servidores de aplicaciones. La redundancia de un clúster es esencial para proporcionar una disponibilidad continua. La actualización de aplicaciones sin interrupciones se refiere a la capacidad de realizar la actualización manteniendo a su vez la disponibilidad continua de la aplicación. Los usuarios de la aplicación no experimentan una pérdida de servicio durante la actualización de la aplicación.
Despliegue de la edición
Despliegue de grupo
Para realizar un despliegue en un clúster de destino, puede dividir el clúster en grupos y definir un tamaño de grupo, que especifica el número de nodos para procesar a la vez. La realización de un despliegue en un grupo genera los servidores en cada grupo que se está actualizando a la nueva edición a la vez. Cada servidor del grupo se inmoviliza, detiene y restablece. Se puede realizar un despliegue sólo en un grupo a la vez con la consola administrativa. Cuando un miembro de la nueva edición está disponible, todas las solicitudes se direccionan a la nueva edición.
A medida que se realiza un despliegue en la edición, algunos servidores del clúster pasan de la edición anterior a la nueva edición, algunos servidores realizan la transición y otros servidores no han iniciado la transición. Todas las solicitudes de aplicación se envían a un servidor que tenga una instancia en ejecución activa de la edición más reciente de la aplicación solicitada. Por ejemplo, cuando realice un despliegue de la edición 1.0 a 2.0, la edición 2.0 presta servicio a todas las solicitudes de aplicación cuando la edición 2.0 pasa a estar disponible en un servidor. Los servidores que continúen ejecutando la edición 1.0 no atenderán solicitudes hasta que el servidor se actualice a la edición 2.0. El ejemplo siguiente es un diagrama de un despliegue de grupo.
Despliegue atómico
Un despliegue atómico de una edición sustituye una edición en mitad del clúster en un instante para atender todas las solicitudes de usuario con una edición coherente de la aplicación. Todas las solicitudes de usuario son atendidas por la edición anterior o la nueva; las solicitudes de usuario nunca son atendidas por ambas ediciones.
Un despliegue atómico asegura que todas las solicitudes de aplicaciones son atendidas por una edición coherente; por ejemplo, ya sea la edición 1.0 o la edición 2.0, por no por ambas. La edición disponible actualmente se pone fuera de línea en la mitad de los servidores que componen el clúster. En esos servidores, se activa y se inicia la nueva edición, pero se mantienen fuera de línea hasta que finaliza el siguiente paso. El siguiente paso es poner fuera de línea la edición actualmente activa en los servidores restantes. En este punto, ningún servidor tiene ninguna instancia de las ediciones disponible para atender solicitudes de la aplicación. El ODR pone en cola temporalmente las solicitudes que llegan para esta aplicación. Después de que la aplicación está completamente fuera de línea, la primera mitad del clúster se pone de nuevo en línea. La segunda mitad hace la transición del clúster de la edición anterior a la siguiente edición y se pone de nuevo en línea. El ejemplo siguiente es un diagrama de un despliegue atómico:
Validación de la edición
La validación de la edición hace referencia a un caso especial de activación simultánea, donde un destino de despliegue asignado de la edición, por ejemplo, un clúster dinámico, se clona y la edición pasa a estar disponible para iniciarse en el destino de despliegue clonado. El destino de despliegue clonado se denomina destino de validación. Deben utilizarse las reglas de direccionamiento para designar qué solicitudes de la aplicación se enviarán a la edición que sufre la validación. Cuando una edición está en la validación, está en la modalidad de validación.
La modalidad de validación asegura que una nueva edición de una aplicación funciona en su entorno de producción sin poner fuera de línea la edición disponible actualmente. Normalmente, se envía una carga de prueba a una edición en la modalidad de validación para confirmar que los aspectos de entorno y configuración de la aplicación, como la conectividad y el acceso a la base de datos, funcionan como se esperaba. Cuando se realiza un despliegue en una modalidad de validación de edición, la operación se produce en el destino de despliegue en el que se instaló originalmente la edición. La realización de un despliegue provoca que la edición salga de la modalidad de validación. Cuando la validación finaliza, el destino de validación se suprime. El ejemplo siguiente es un diagrama de validación de edición.
Compatibilidad de ediciones
Algunos cambios de aplicaciones son transparentes mientras que otros cambios de aplicaciones los ve el usuario final. Cuando una actualización de aplicación entrega al menos las mismas interfaces de programación de aplicaciones que en el último cambio y no se produce ningún cambio semántico en el comportamiento esencial, esa edición es una actualización compatible con las versiones anteriores. Como usuario existente, puede utilizar la aplicación actualizada sin cambiar cómo la utilizan sin reconocer una diferencia entre las ediciones actuales y anteriores.
Una actualización de la aplicación que requiere que los usuarios existentes cambien el modo de utilizar la aplicación es una actualización incompatible. Quizás tenga que omitir la función inicial o cambiar las interfaces, por ejemplo, para mejorar la capacidad de mantenimiento u otros factores y podrían introducirse cambios incompatibles en el entorno de despliegue. Los cambios incompatibles requieren una planificación cuidadosa para gestionar el impacto en los usuarios existentes.