Administrar lanzamientos

Una implementación de Cloud Deploy incluye fases. Una fase es una agrupación ordenada y lógica de tareas 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). Además, 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 hay ejecuciones de 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.

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

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

• canary-25
• canary-50
• stable

Estos nombres de fase son estándar: canary-[PERCENTAGE] para las etapas canary y stable para la fase del 100%. Sin embargo, si configuras una canaria manual o 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 en una estrategia de implementación estándar, sin verificación de implementación habilitada, hay una fase (stable).

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

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

Cómo omitir fases la primera vez

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

Por este motivo, cuando implementas una versión canary por primera vez, omitimos las fases de la versión canary y ejecutamos la fase stable. Después de eso, se implementa la aplicación, y las implementaciones canary futuras incluirán las fases 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 será raro omitir esta fase.

Estados dentro de un lanzamiento

Las implementaciones, 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 los lanzamientos que un usuario canceló.

• CANCELLING

  Un usuario canceló el lanzamiento, pero la cancelación aún no se procesó.

• HALTED

  En una implementación en paralelo, si uno o más lanzamientos secundarios fallan, 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 un lanzamiento de controlador detenido, sigue cualquiera de estos pasos:

  • Cancela el lanzamiento del controlador

  • Vuelve a intentar los trabajos con errores en los lanzamientos secundarios o ignóralos

• IN_PROGRESS

  Se está procesando una ejecución de trabajo.

• FAILED

  Se produjo un error en una tarea y el usuario no eligió ignorarlo.

• PENDING

  Aún no se ha iniciado el procesamiento del lanzamiento. 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 a que se renderice la versión.

• SUCCEEDED

  El lanzamiento finalizó sin errores.

Estados de fase

Una fase tendrá uno de los siguientes estados:

• PENDING

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

• IN_PROGRESS

  Comenzó la fase.

• SUCCEEDED

  La fase se completó correctamente.

• FAILED

  Una tarea de la fase falló 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 omite la fase stable en los casos en 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 de trabajo

Un trabajo tendrá uno de los siguientes estados:

• ABORTED

  Si falla una fase, se abortan las fases posteriores.

  Si un trabajo falla y esa falla no se ignora, se abortan los trabajos posteriores. Por ejemplo, si una fase incluye un trabajo de implementación y uno de verificación, y el trabajo de implementación falla, se aborta el trabajo de verificación.

• DISABLED

  Es posible que algunas tareas de una fase estén inhabilitadas. Por ejemplo, las fases siempre incluyen trabajos de verificación, 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

  Una ejecución de trabajo para este trabajo falló y el usuario no eligió ignorar la falla.

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

• IGNORED

  Una ejecución de trabajo falló, y el usuario eligió ignorar la falla.

• IN_PROGRESS

  Se está ejecutando una ejecución de trabajo para este trabajo.

• PENDING

  La ejecución de la tarea está esperando comenzar porque no finalizó otra fase o tarea.

• SKIPPED

  Cuando ejecutas una estrategia de implementación, como una versión canary, Cloud Deploy omite la fase stable en los casos en 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 dentro de las fases omitidas.

• SUCCEEDED

  La ejecución del trabajo finalizó correctamente y comenzó el siguiente trabajo de la fase, o bien comenzó la siguiente fase o está lista para comenzar (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 finalizó la ejecución de la tarea, pero aún no se finalizó.

• SUCCEEDED

  Cuando una ejecución de trabajo finaliza correctamente, sin errores ni que un usuario la finalice, 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 un lanzamiento de Cloud Deploy:

• Adelantar el lanzamiento

• Cancela el lanzamiento

• Cómo finalizar una ejecución de trabajo

• Cómo omitir un trabajo

• Cómo volver a intentar un trabajo fallido

Si usas la implementación en paralelo con una estrategia de implementación de versiones canary, consulta este documento.

Cómo adelantar un lanzamiento

En el caso de los destinos configurados para usar una estrategia de implementación distinta de la "estándar", debes avanzar el lanzamiento de fase a fase.

Por ejemplo, si tienes un objetivo configurado para realizar una implementación canary simple con solo las fases del 50% y stable (100%), deberás avanzar el lanzamiento 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

Cancela un lanzamiento

Puedes cancelar cualquier lanzamiento que no haya terminado. También puedes cancelar una implementación que falló para evitar que se realicen más acciones (como ignorarla o volver a intentarla). 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 estará en un estado CANCELLING hasta que se completen todas las ejecuciones de trabajos pendientes. Puedes finalizar trabajos pendientes que no quieras esperar. Una vez que el lanzamiento sea CANCELLED, ya no se podrá 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. Es posible que desees hacerlo, por ejemplo, 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 finalizarlo.

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 trabajo, este se considera con errores y puedes hacer lo siguiente:

• Déjalo así y no tengas en cuenta el lanzamiento con errores.
• Cómo volver a intentar el trabajo
• Ignora el trabajo y continúa con el siguiente trabajo o fase del lanzamiento.

Cómo ignorar un trabajo

Puedes ignorar un trabajo con errores y pasar de inmediato al siguiente trabajo de la fase. Es posible que esa tarea fallara por cualquier motivo, por ejemplo, porque tú o alguien más finalizaron una ejecución de esa tarea.

Un trabajo con errores significa que la fase y el lanzamiento fallaron. Sin embargo, si ignoras el error, tanto la fase como el lanzamiento pueden avanzar 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ó. La tarea 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 finalizó una ejecución de trabajo desde ese trabajo.

  Si finalizas una ejecución de trabajo, se producirá un trabajo con errores, que puedes reintentar.

• Falló una prueba de verificación.

  En un trabajo de verificación, una prueba de verificación falló. Aunque el trabajo de verificación se completó correctamente, una de tus pruebas de verificación falló, y lo propagamos al trabajo de verificación. En este caso, reintentarías la tarea 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 de la arquitectura del servicio de Cloud Deploy para obtener más información sobre cómo se integran los lanzamientos, las fases, los trabajos y las ejecuciones de trabajos con el resto de Cloud Deploy.