Los releases se implementan mediante despliegues. Un despliegue tiene como destino una sola fase y su entorno asociado (cada fase tiene un solo entorno y está asociada al mismo). Un despliegue puede tener una amplia base y utilizar todas las aplicaciones de un release, puede representar un despliegue de emergencia o una sola aplicación, o cualquier término medio. Los despliegues pueden tener un destino tan preciso como sea necesario.
Los despliegues de IBM® UrbanCode Release contienen:
La planificación que define cuándo se lleva a cabo el despliegue y especifica si se trata de un suceso de una sola vez o de un suceso recurrente
Las notificaciones de correo electrónico que activan los sucesos definidos por el usuario y se envían a un usuario o a un rol de usuario concreto
Aprobaciones necesarias
Los despliegues, o planes de despliegue, constan de segmentos. Un segmento representa las actividades del release previstas para que se completen conjuntamente. Se puede configurar un segmento para que se ejecute una vez se ha ejecutado correctamente otro segmento o para que se ejecute independientemente de otro segmento. Un plan de despliegue puede tener cualquier número de segmentos. El plan predeterminado tiene dos segmentos: Tareas previas al despliegue y Tareas de despliegue.
Después de definir un plan de despliegue, se puede iniciar un despliegue en cualquier momento con una solicitud de despliegue. Una solicitud de despliegue puede iniciar un despliegue completo o una parte del plan, por ejemplo, un segmento individual.
Asegúrese de que cada equipo tiene un plan de reserva además del plan principal. El plan de reserva puede ser tan sencillo como restituir una versión antigua hasta que se resuelvan los bloqueos.
Como su nombre indica, un despliegue ad hoc es un despliegue no planificado. Los despliegues ad hoc se pueden planificar en cualquier momento, lo que significa que no tiene que definir una lista extensa de despliegues durante la planificación del release.
Durante el avance de un entorno típico es importante realizar pruebas, incluidas ventanas recurrentes, pero debe ser lo suficientemente flexible para replantear los entornos si los entornos que tenía previstos pasan a estar no disponibles.
Normalmente, la línea de aplicaciones se define cuando se crea el release. Las aplicaciones asociadas al release están disponibles automáticamente para cualquier despliegue que utilice el release. Las aplicaciones y las suites de aplicaciones se pueden promocionar a versiones publicadas. Normalmente, una versión publicada representa una aplicación (o suite) que se ha desplegado correctamente y puede volver a utilizarse con seguridad.
Además, puede añadir aplicaciones a un release después de que se hayan planificado despliegues para el mismo. Las nuevas aplicaciones pasan a formar parte de cualquier despliegue siguiente o despliegue en curso.
Las actividades de despliegue se definen mediante tareas. Una tarea individual es una unidad de trabajo que puede representar cualquier actividad relacionada con la empresa que esté asociada a un release. Se pueden configurar las tareas para que se ejecuten una vez o cada vez que se utiliza el plan de despliegue. Se puede asignar una tarea a un rol de usuario o a un usuario específico. Si no se asigna, podrá reclamarla cualquier usuario que tenga el rol requerido. Una vez definida una tarea, se añade a la biblioteca de tareas y pasa a estar disponible para otros despliegues.
Cuando se crea una tarea, se le asigna una duración, esto es, una estimación del tiempo que tarda en completarse. IBM UrbanCode Release agrega las duraciones de las tareas para calcular el tiempo que puede tardar el despliegue global.
Las tareas pueden ser automatizadas o manuales. Las tareas automatizadas proceden de las integraciones con las herramientas externas. Por ejemplo, los procesos de las aplicaciones de IBM UrbanCode Deploy están disponible como tareas automatizadas en IBM UrbanCode Release.
Las tareas manuales pueden representar cualquier tarea no automatizada, tal como detener o iniciar un servidor. A diferencia de los hitos que se definen para el release global, las tareas manuales (y las tareas automatizadas) se adjuntan a una fase y segmento concretos. Un segmento se puede considerar un grupo de tareas cuya finalización está prevista a la misma hora.
Normalmente, las tareas se definen en la página Despliegues planificados en la aplicación web pero también se pueden exportar e importar (como archivos CSV).
Las versiones de las aplicaciones tienen estados de calidad. Los estados de calidad garantizan que las versiones de las aplicaciones cumplen con algunos requisitos de calidad previstos. Se pueden asignar los estados manualmente o mediante la integración con herramientas externas.
Cuando sea necesario realizar un despliegue de emergencia, se pueden suspender temporalmente las aprobaciones y puertas.
Una aprobación es un mecanismo que se utiliza para controlar entornos, independientemente de las consideraciones de calidad (estado). Las aprobaciones se adjuntan a las fases. Un release que requiere aprobación no podrá avanzar a una fase hasta que se le conceda la aprobación. Normalmente, los aprobadores se designan por rol de usuario. Cualquier usuario con el rol designado puede responder a una solicitud de aprobación. Por ejemplo, si la fase QA requiere la aprobación del gestor del release, el release no podrá continuar hasta que sea aprobado por cualquiera que posea el rol de gestor del release. También se pueden designar usuarios específicos para la aprobación.
Si un despliegue planificado que requiere aprobación alcanza su hora de inicio sin recibir la aprobación, la fase no continúa y se considera que el aprobador la ha rechazado.