Administrar lanzamientos

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

Cada fase incluye trabajos, que son las acciones que se deben realizar en cada fase (por ejemplo, deploy o verify), y cada trabajo puede tener cero o más ejecuciones. Una ejecución de trabajo es una instancia de un trabajo. Si el trabajo no se ejecutó, no habrá ejecuciones del trabajo.

En este documento, se describen las fases, los trabajos y las ejecuciones de trabajos, y cómo administrarlos.

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 más fases.

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

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

• canary-25
• canary-50
• stable

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

Trabajos y ejecuciones de trabajos

Cada fase de lanzamiento incluye uno o más trabajos.

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

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

Una ejecución de trabajo es una instancia de un trabajo. Por ejemplo, se ejecuta una ejecución de trabajo para un trabajo deploy y, si se realiza correctamente, no hay más ejecuciones de trabajo para ese trabajo. Si falla, se puede volver a intentar como otra ejecución de trabajo.

Cómo omitir fases la primera vez

Algunas estrategias de implementación (por ejemplo, la canary) asignan el tráfico entre las versiones antigua y nueva. Si es la primera vez que realizas la implementación en un destino, no hay una versión anterior, por lo que no podemos asignar el tráfico.

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

En una situación real, por lo general, ejecutarás una implementación de versiones canary en la que tu aplicación ya se esté ejecutando, por lo que omitir esta fase será poco común.

Estados dentro de un lanzamiento

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

Estados del lanzamiento

Un lanzamiento tendrá uno de los siguientes estados:

• APPROVAL_REJECTED

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

• CANCELLED

  Es el estado final de las versiones que un usuario canceló.

• CANCELLING

  Un usuario canceló el lanzamiento, pero la cancelación aún no terminó de procesarse.

• HALTED

  En una implementación paralela, si falla uno o más lanzamientos secundarios, pero al menos uno se realiza correctamente, el lanzamiento del controlador se DETIENE si hay más fases después de la actual.

  Para reanudar el lanzamiento de un controlador detenido, puedes hacer lo siguiente:

  • Cancela el lanzamiento del control

  • Vuelve a intentar o ignora los trabajos con errores en los lanzamientos secundarios

• IN_PROGRESS

  Se está procesando una ejecución de trabajo.

• FAILED

  Falló un trabajo y el usuario no eligió ignorar la falla.

• PENDING

  La implementación no comenzó a procesarse. Este estado pasa a IN_PROGRESS o CANCELED.

• PENDING_APPROVAL

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

• PENDING_RELEASE

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

• SUCCEEDED

  Se completó el lanzamiento sin errores.

Estados de la fase

Una fase tendrá uno de los siguientes estados:

• PENDING

  La fase está esperando que finalice otra fase del lanzamiento.

• IN_PROGRESS

  La fase comenzó.

• SUCCEEDED

  La fase se completó correctamente.

• FAILED

  Falló un trabajo en la fase y el usuario no eligió ignorar la falla.

• ABORTED

  Falló una fase anterior.

• SKIPPED

  Cuando ejecutas una estrategia de implementación, como una versión canary, Cloud Deploy se salta 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 establece en SKIPPED.

Estados del trabajo

Un trabajo tendrá uno de los siguientes estados:

• ABORTED

  Si falla una fase, se anulan las fases posteriores.

  Si un trabajo falla y esa falla no se ignora, se anulan 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, se anula el trabajo de verificación.

• DISABLED

  Es posible que algunos trabajos de una fase estén inhabilitados. Por ejemplo, las fases siempre incluyen trabajos de verificación, independientemente de si la verificación está habilitada. Si la verificación no está habilitada, el trabajo de verificación se establece en DISABLED.

• FAILED

  Falló una ejecución de trabajo para este trabajo, y el usuario no eligió ignorar la falla.

  El usuario eligió interrumpir la ejecución del trabajo para este trabajo.

• IGNORED

  Se produjo una falla en la ejecución de este trabajo, y el usuario eligió ignorar la falla.

• IN_PROGRESS

  Actualmente, se está ejecutando un trabajo para este trabajo.

• PENDING

  La ejecución de este trabajo está en espera para comenzar, ya que no finalizó otra fase o trabajo.

• SKIPPED

  Cuando ejecutas una estrategia de implementación, como una canaria, Cloud Deploy se salta 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 establece en SKIPPED en los trabajos de la fase o las fases omitidas.

• SUCCEEDED

  La ejecución del trabajo finalizó correctamente y se inició el siguiente trabajo de la fase, o bien se inició la siguiente fase o está lista para iniciarse (posiblemente, pendiente de la entrada del usuario), o bien finalizó el lanzamiento.

Estados de ejecución del trabajo

• FAILED

  La ejecución del trabajo falló durante la ejecución.

• IN_PROGRESS

  La ejecución del trabajo comenzó, pero no finalizó.

• TERMINATED

  El usuario finalizó la ejecución del trabajo.

• TERMINATING

  El usuario detuvo la ejecución del trabajo, pero aún no finalizó la detención.

• SUCCEEDED

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

Administra tu lanzamiento

Con la consola de Google Cloud o el SDK de Google Cloud, puedes hacer lo siguiente con una implementación de Cloud Deploy:

• Cómo adelantar el lanzamiento

• Cancela el lanzamiento.

• Cómo detener la ejecución de un trabajo

• Cómo ignorar un trabajo

• Cómo reintentar un trabajo con errores

Si usas la implementación paralela con una estrategia de implementación de versiones canary, consulta cómo administrar los lanzamientos canary paralelos.

Cómo adelantar un lanzamiento

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

Por ejemplo, si tienes un destino configurado para realizar una implementación canary simple con solo fases del 50% y stable (100%), deberás avanzar la versión una vez, desde la fase canary-50 hasta la fase stable (100%).

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

Cancela 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 intentarlo). El lanzamiento debe estar en uno de los siguientes estados:

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

Después de cancelar un lanzamiento, este se encontrará en estado CANCELLING hasta que se completen todas las ejecuciones de trabajos pendientes. Puedes finalizar las ejecuciones de trabajos pendientes que no quieras esperar. Una vez que se completa el lanzamiento (CANCELLED), ya no se puede avanzar ni modificar.

Para cancelar un lanzamiento, sigue estos pasos:

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

Cómo finalizar una ejecución de trabajo

Puedes finalizar una ejecución de trabajo que esté en curso. Por ejemplo, es posible que desees hacerlo si una ejecución de trabajo parece tardar demasiado o no funciona como se espera. La ejecución del trabajo debe ser IN_PROGRESS para que puedas 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 la ejecución de un trabajo, se considera que este falló y puedes realizar cualquiera de las siguientes acciones:

• Déjalo así y no tengas en cuenta el lanzamiento con errores
• Reintenta el trabajo
• Ignorar el trabajo y continuar con el siguiente trabajo o fase de la implementación

Cómo ignorar un trabajo

Puedes ignorar un trabajo con errores y pasar de inmediato al siguiente trabajo de la fase. Es posible que ese trabajo haya fallado por cualquier motivo, incluso si tú o alguien más finalizó una ejecución del trabajo.

Un trabajo con errores significa una fase con errores y un lanzamiento con errores. Sin embargo, si ignoras el error, se puede avanzar tanto en la fase como en el lanzamiento, 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

Cómo reintentar un trabajo con errores

Puedes reintentar una ejecución de trabajo que falló. El trabajo puede fallar por cualquiera de los siguientes motivos:

• No se pudo completar la ejecución de un trabajo.

  Por ejemplo, podría haber ocurrido un error de permisos.

• Un usuario detuvo la ejecución de un trabajo desde ese trabajo.

  Si finalizas la ejecución de un trabajo, este fallará y podrás reintentarlo.

• No se pudo realizar una prueba de verificación.

  En el caso de un trabajo de verificación, falló una prueba de verificación. Aunque el trabajo de verificación se completó correctamente, falló una de tus pruebas de verificación, y propagamos ese error 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 reintentar un trabajo con errores, haz lo siguiente:

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

¿Qué sigue?

• Obtén más información sobre cómo funcionan las estrategias de implementación en Cloud Deploy.

• Consulta la documentación sobre la arquitectura del servicio de Cloud Deploy para obtener más información sobre cómo se relacionan las versiones, las fases, los trabajos y las ejecuciones de trabajos con el resto de Cloud Deploy.