![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Conceptos del gestor de ediciones de aplicaciones
Si 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.

Versiones y ediciones
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 la siguiente generación 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 la siguiente generación del despliegue, por ejemplo, el despliegue de un conjunto determinado de artefactos con versión. Una edición es un concepto operativo y de despliegue.
- La edición base se refiere a una aplicación desplegada que no tiene ninguna información de edición asociada.
- 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.
- 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 un conjunto de usuario el acceso a una edición y a otros usuarios 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.

Actualización y despliegue de aplicaciones
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. En otras palabras, los usuarios de la aplicación no experimentan ninguna pérdida de servicio durante la actualización de la aplicación.
- Impedir al servidor recibir nuevas solicitudes.
- Inmovilizar las solicitudes para la aplicación en un servidor determinado.
- Detener la edición activa de forma simultánea.
- Iniciar la nueva edición.
- Reanudar el flujo de solicitudes en la edición.
Cuando se realiza un despliegue de una edición en un clúster de servidores de aplicaciones, se completan las siguientes actividades en todo el conjunto de los servidores que están en dicho clúster:
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. Sólo se puede realizar una despliegue en un grupo a la vez en la consola administrativa. Cuando un miembro de la nueva edición está disponible, todas las solicitudes se direccionan a la nueva edición.
Cuando realice un despliegue en la edición, algunos servidores del clúster se mueven de la edición anterior a la nueva edición, algunos servidores están en el proceso de realizar 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 aplicaciones cuando la edición 2.0 pasa a estar disponible en un servidor. Los servidores que siguen ejecutando la edición 1.0 no prestan servicio a las solicitudes hasta que se actualiza el servidor a la edición 2.0. El ejemplo siguiente es un diagrama de un despliegue de grupo.

Un despliegue atómico de una edición sustituye una edición en mitad del clúster en un instante cada vez para atender a 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 garantiza que una edición coherente presta servicio a todas las solicitudes de aplicación, por ejemplo, ya sea la edición 1.0 o la 2.0, pero no 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 estos servidores 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 desde la edición anterior hasta la siguiente edición y se pone de nuevo en línea. El ejemplo siguiente es un diagrama de un despliegue atómico:

Compatibilidad y validación de ediciones
La validación de 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 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, tales 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. Si se realiza un despliegue, la edición sale 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.

Algunos cambios de aplicación son transparentes, mientras que otros cambios de aplicación son vistos por el usuario final. Cuando una actualización de aplicación entrega, como mínimo, las mismas interfaces de programación de aplicaciones que el último cambio y no hay ningún cambio semántico en el comportamiento esencial, dicha edición de aplicación es una actualización que es 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 descartar 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.