Gestionar lanzamientos

Un lanzamiento de Cloud Deploy incluye fases. Una fase es una agrupación lógica y ordenada de tareas que se deben realizar en una implementación.

Cada fase incluye tareas, que son las acciones que se deben llevar a cabo en cada fase (por ejemplo, deploy o verify). Cada tarea puede tener cero o más ejecuciones. Una ejecución de una tarea es una instancia de una tarea. Si el trabajo no se ha ejecutado, no habrá ninguna ejecución.

En este documento se describen las fases, los trabajos y las ejecuciones de trabajos, así como la forma de gestionarlos.

Estructura de un lanzamiento

Un lanzamiento es un recurso de Cloud Deploy que asocia una versión con un destino.

Fases

Un lanzamiento consta de una o varias fases.

En el caso de una estrategia de implementación estándar, solo hay una fase: stable.

En una estrategia de implementación canaria, hay una fase independiente para cada porcentaje configurado. Por ejemplo, si configuras una versión canary que implementa el 25%, el 50 % y el 100%, habrá tres fases:

• canary-25
• canary-50
• stable

Estos nombres de fase son estándar: canary-[PERCENTAGE] para las fases de lanzamiento canary y stable para la fase del 100 %. Sin embargo, si configuras una prueba canary personalizada automatizada o una prueba canary personalizada, puedes controlar los nombres de las fases.

Tareas y ejecuciones de tareas

Cada fase de lanzamiento incluye uno o varios trabajos.

En una implementación estándar, con la estrategia de lanzamiento, sin la verificación de la implementación habilitada, hay una fase (stable).

En el caso de un lanzamiento Canary, habrá una fase para cada parte del Canary (por ejemplo, canary-25, canary-50 y stable) y, en cada fase, habrá un trabajo deploy. Si la verificación está habilitada, también hay una tarea verify para cada fase.

Una ejecución de una tarea es una instancia de una tarea. Por ejemplo, se ejecuta un trabajo de deploy y, si se completa correctamente, no se vuelve a ejecutar. Si falla, se puede volver a intentar como otra ejecución de trabajo.

Saltar fases la primera vez

Algunas estrategias de implementación (por ejemplo, la canaria) reparten el tráfico entre las versiones antigua y nueva. Si es la primera vez que implementas una versión en un destino, no hay ninguna versión antigua, por lo que no podemos repartir el tráfico.

Por este motivo, cuando implementas una versión canary por primera vez, nos saltamos la fase o las fases canary y ejecutamos la fase stable. Después, la aplicación se implementa y las futuras implementaciones canary incluirán las fases canary.

En una situación real, normalmente se ejecuta una implementación canary en la que la aplicación ya está en funcionamiento, por lo que esta fase se omitirá en raras ocasiones.

Estados de un lanzamiento

Los lanzamientos, las fases, los trabajos y las ejecuciones de trabajos tienen estados. En esta sección se describen los estados de cada uno.

Estados de lanzamiento

Una publicación tendrá uno de los siguientes estados:

• APPROVAL_REJECTED

  El lanzamiento requería aprobación, pero se ha rechazado.

• CANCELLED

  Estado final de los lanzamientos que han sido cancelados por un usuario.

• CANCELLING

  Un usuario ha cancelado el lanzamiento, pero la cancelación no ha terminado de procesarse.

• HALTED

  En una implementación paralela, si falla una o más implementaciones secundarias, pero al menos una se completa correctamente, la implementación del controlador se DETIENE si hay más fases después de la actual.

  Para reanudar el lanzamiento de una versión de controlador que se ha detenido, puedes hacer lo siguiente:

  • Cancelar el lanzamiento del controlador

  • Reintentar o ignorar los trabajos fallidos de las implementaciones secundarias

• IN_PROGRESS

  Se está procesando una ejecución de trabajo.

• FAILED

  Un trabajo ha fallado y el usuario no ha elegido ignorar el fallo.

• PENDING

  El lanzamiento aún no ha empezado a procesarse. Este estado pasa a IN_PROGRESS o CANCELED.

• PENDING_APPROVAL

  El lanzamiento requiere aprobación, pero aún no se ha aprobado.

• PENDING_RELEASE

  El lanzamiento está pendiente de que se renderice la versión.

• SUCCEEDED

  El lanzamiento se ha completado sin errores.

Estados de las fases

Una fase puede tener uno de los siguientes estados:

• PENDING

  La fase está esperando a que termine otra fase del lanzamiento.

• IN_PROGRESS

  La fase ha comenzado.

• SUCCEEDED

  La fase se ha completado correctamente.

• FAILED

  Se ha producido un error en un trabajo de la fase y el usuario no ha elegido ignorar el error.

• ABORTED

  Se ha producido un error en una fase anterior.

• SKIPPED

  Cuando ejecutas una estrategia de despliegue, como un canario, Cloud Deploy pasa a la fase stable en los casos en los que aún no hay una versión en ejecución de la aplicación con la que dividir el tráfico. En este caso, el estado se define como SKIPPED.

Estados de la tarea

Un trabajo tendrá uno de los siguientes estados:

• ABORTED

  Si falla una fase, se cancelan las fases posteriores.

  Si falla un trabajo y ese fallo no se ignora, se cancelan los trabajos posteriores. Por ejemplo, si una fase incluye un trabajo de implementación y un trabajo de verificación, y el trabajo de implementación falla, el trabajo de verificación se cancela.

• DISABLED

  Puede que algunas tareas de una fase estén inhabilitadas. Por ejemplo, las fases siempre incluyen la verificación de los trabajos, independientemente de si la verificación está habilitada o no. Si la verificación no está habilitada, el trabajo de verificación se establece en DISABLED.

• FAILED

  Se ha producido un error en la ejecución de esta tarea y el usuario no ha elegido ignorar el error.

  El usuario ha decidido finalizar la ejecución de la tarea.

• IGNORED

  Se ha producido un error en la ejecución de esta tarea y el usuario ha decidido ignorar el error.

• IN_PROGRESS

  Actualmente, se está ejecutando una tarea de este tipo.

• PENDING

  La ejecución de este trabajo está esperando a que empiece porque otra fase u otro trabajo no ha terminado.

• SKIPPED

  Cuando ejecutas una estrategia de despliegue, como un canario, Cloud Deploy pasa a la fase stable en los casos en los que aún no hay una versión en ejecución de la aplicación con la que dividir el tráfico. En este caso, el estado se define como SKIPPED en los trabajos de la fase o las fases omitidas.

• SUCCEEDED

  El trabajo se ha completado correctamente y ha empezado el siguiente trabajo de la fase, o ha empezado la siguiente fase o está lista para empezar (posiblemente pendiente de la entrada del usuario) o el lanzamiento ha finalizado.

Estados de ejecución de la tarea

• FAILED

  La ejecución de la tarea ha fallado.

• IN_PROGRESS

  La ejecución del trabajo ha comenzado, pero no ha terminado.

• TERMINATED

  El usuario ha finalizado la ejecución del trabajo.

• TERMINATING

  El usuario ha finalizado la ejecución del trabajo, pero aún no ha terminado de finalizar.

• SUCCEEDED

  Cuando una ejecución de un trabajo finaliza correctamente, sin fallar ni ser finalizada por un usuario, se pone en estado SUCCEEDED, que

Gestionar el lanzamiento

Con la Google Cloud consola o el SDK de Google Cloud, puedes hacer lo siguiente con un lanzamiento de Cloud Deploy:

• Avanzar el lanzamiento

• Cancelar el lanzamiento

• Finalizar una ejecución de un trabajo

• Ignorar una tarea

• Reintentar una tarea fallida

Si usas la implementación paralela con una estrategia de implementación canary, consulta cómo gestionar las implementaciones canary paralelas.

Avanzar un lanzamiento

En los destinos configurados para usar una estrategia de implementación que no sea "estándar", debes avanzar en la implementación de fase en fase.

Por ejemplo, si tienes un destino configurado para realizar una implementación canary sencilla con solo las fases 50% y stable (100%), tendrías que avanzar la implementación una vez, de la fase canary-50 a la fase stable (100%).

gcloud deploy rollouts advance ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --region=REGION

Cancelar un lanzamiento

Puedes cancelar cualquier lanzamiento que no haya finalizado. También puedes cancelar una implementación fallida para evitar que se realicen más acciones en ella (como ignorar o volver a intentar). El lanzamiento debe tener uno de los siguientes estados:

• FAILED
• HALTED
• IN_PROGRESS
• PENDING
• PENDING_APPROVAL
• PENDING_RELEASE

Después de cancelar un lanzamiento, este tendrá el estado CANCELLING hasta que se hayan completado todas las ejecuciones de tareas pendientes. Puedes finalizar ejecuciones de trabajos pendientes que no quieras esperar. Una vez que se haya completado el lanzamientoCANCELLED, no se podrá avanzar ni modificar.

Para cancelar un lanzamiento:

gcloud deploy rollouts cancel ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --region=REGION

Finalizar una ejecución de una tarea

Puedes finalizar un trabajo que esté en curso. Por ejemplo, puedes hacerlo si una ejecución de un trabajo parece que está tardando demasiado o no funciona como se esperaba. La ejecución de la tarea debe estar en estado IN_PROGRESS para poder finalizarla.

gcloud deploy job-runs terminate JOB_RUN_ID \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --rollout=ROLLOUT_NAME \
                               --region=REGION

Después de finalizar una ejecución de un trabajo, se considera que el trabajo ha fallado y puedes hacer lo siguiente:

• Déjalo así y no tengas en cuenta el lanzamiento fallido
• Volver a intentar la tarea
• Ignora el trabajo y continúa con el siguiente trabajo o fase de la implementación.

Ignorar una tarea

Puedes ignorar un trabajo fallido y pasar inmediatamente al siguiente trabajo de la fase. Es posible que el trabajo haya fallado por cualquier motivo, incluido que tú u otra persona haya finalizado una ejecución del trabajo.

Si falla un trabajo, también fallarán la fase y el lanzamiento. Sin embargo, si ignoras el error, tanto la fase como el lanzamiento se pueden completar y, en última instancia, pueden tener estados SUCCEEDED.

gcloud deploy rollouts ignore-job ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --job-id=JOB_ID \
                               --phase-id=PHASE_ID \
                               --region=REGION

Reintentar una tarea fallida

Puedes volver a intentar ejecutar un trabajo que haya fallado. El trabajo puede fallar por cualquiera de los siguientes motivos:

• No se ha podido completar una ejecución de un trabajo.

  Por ejemplo, puede que se haya producido un error con los permisos.

• Un usuario ha finalizado una ejecución de un trabajo de ese trabajo.

  Si finalizas una ejecución de un trabajo, este fallará, pero podrás volver a intentarlo.

• Ha fallado una prueba de verificación.

  En una tarea de verificación, no se ha superado una prueba de verificación. Aunque el trabajo de verificación se ha completado correctamente, una de las pruebas de verificación ha fallado y se ha propagado al trabajo de verificación. En este caso, volverías a intentar ejecutar el trabajo como parte de la depuración de la prueba fallida en tu aplicación.

Para volver a intentar una tarea fallida, sigue estos pasos:

gcloud deploy rollouts retry-job JOB_NAME \
                       --release=RELEASE_NAME \
                       --delivery-pipeline=PIPELINE_NAME \
                       --rollout=ROLLOUT_NAME \
                       --phase=PHASE_ID \
                       --region=REGION

Siguientes pasos

• Consulta más información sobre cómo funcionan las estrategias de despliegue en Cloud Deploy.

• Consulta la documentación sobre la arquitectura de servicio de Cloud Deploy para obtener más información sobre cómo se ajustan los lanzamientos, las fases, los trabajos y las ejecuciones de trabajos al resto de Cloud Deploy.