Cómo funcionan las ejecuciones de canalización

En esta sección se proporciona una descripción general de la forma en que se CodePipeline procesa un conjunto de cambios. CodePipelinerealiza un seguimiento de cada ejecución de una canalización que se inicia cuando una canalización se inicia manualmente o se realiza un cambio en el código fuente. CodePipeline utiliza los siguientes modos de ejecución para controlar el progreso de cada ejecución a lo largo de la canalización.

• Modo reemplazado: una ejecución más reciente puede reemplazar a una anterior. Esta es la opción predeterminada.

• Modo en cola: las ejecuciones se procesan una a una en el orden en que están en cola. Esto requiere el tipo de canalización V2.

• Modo PARALELO: en el modo PARALELO, las ejecuciones se ejecutan de forma simultánea e independiente unas de otras. Las ejecuciones no esperan a que se completen otras ejecuciones para empezar o finalizar. Esto requiere una canalización del tipo V2.

Cómo se inician las ejecuciones de canalización

Puedes iniciar una ejecución al cambiar el código fuente o iniciar la canalización manualmente. También puede activar una ejecución mediante una regla de Amazon CloudWatch Events que programe. Por ejemplo, cuando se envía un cambio de código fuente a un repositorio configurado como acción de origen de la canalización, la canalización detecta el cambio e inicia una ejecución.

nota

Si una canalización contiene varias acciones de origen, todas ellas se vuelven a ejecutar aunque solo se detecte un cambio para una de ellas.

Cómo se procesan las revisiones de origen en las ejecuciones en proceso

Para cada ejecución en proceso que comience con cambios en el código fuente (revisiones del código fuente), las revisiones del código fuente se determinan de la siguiente manera.

• En el caso de las canalizaciones con una CodeCommit fuente, el HEAD se clona CodePipeline en el momento en que se envía la confirmación. Por ejemplo, se envía una confirmación, lo que inicia la canalización para la ejecución 1. En el momento en que se envía una segunda confirmación, se inicia el proceso de ejecución 2.

  nota

  En el caso de las canalizaciones en modo PARALELO con una CodeCommit fuente, independientemente de la confirmación que haya desencadenado la ejecución de la canalización, la acción fuente siempre clonará el HEAD en el momento en que se inicie. Para obtener más información, consulte CodeCommit o las revisiones del código fuente de S3 en modo paralelo podrían no coincidir con el EventBridge evento .

• En el caso de las canalizaciones con una fuente de S3, se EventBridge utiliza el evento de la actualización del bucket de S3. Por ejemplo, el evento se genera cuando se actualiza un archivo en el bucket de origen, lo que inicia la canalización para la ejecución 1. En el momento en que se realiza el evento de una segunda actualización del bucket, se inicia el proceso de ejecución 2.

  nota

  En el caso de las canalizaciones en modo PARALELO con una fuente S3, independientemente de la etiqueta de imagen que haya activado la ejecución, la acción de origen siempre empezará con la etiqueta de imagen más reciente. Para obtener más información, consulte CodeCommit o las revisiones del código fuente de S3 en modo paralelo podrían no coincidir con el EventBridge evento .

• En el caso de las canalizaciones con una fuente de conexiones, como Bitbucket, el HEAD se clona CodePipeline en el momento en que se envía la confirmación. Por ejemplo, para una canalización en modo paralelo, se envía una confirmación, que inicia la canalización para la ejecución 1, y la segunda ejecución de la canalización utiliza la segunda confirmación.

Cómo se detienen las ejecuciones de canalización

Para utilizar la consola para detener una ejecución de canalización, puede seleccionar Stop execution (Detener la ejecución) en la página de visualización de canalización, en la página de historial de ejecución o en la página de historial detallado. Para utilizar la CLI para detener una ejecución de canalización, utilice el comando stop-pipeline-execution. Para obtener más información, consulte Detenga la ejecución de una canalización en CodePipeline.

Hay dos formas de detener una ejecución de canalización:

• Detener y esperar: todas las ejecuciones de acción en curso pueden completarse y las acciones posteriores no se inician. La ejecución de canalización no continúa en etapas posteriores. No puede utilizar esta opción en una ejecución que ya se encuentra en un estado Stopping.

• Detener y abandonar: todas las ejecuciones de acción en curso se abandonan y no se completan, y las acciones posteriores no se inician. La ejecución de canalización no continúa en etapas posteriores. Puede utilizar esta opción en una ejecución que ya se encuentra en un estado Stopping.

  nota

  Esta opción puede conducir a tareas con error o fuera de secuencia.

Cada opción da lugar a una secuencia diferente de fases de canalización y ejecución de acciones, como se indica a continuación.

Opción 1: Detener y esperar

Cuando elige detener y esperar, la ejecución seleccionada continúa hasta que se completen las acciones en curso. Por ejemplo, la siguiente ejecución de canalización se ha detenido mientras la acción de compilación estaba en curso.

1. En la vista de canalización, se muestra el banner del mensaje de realización correcta y la acción de compilación continúa hasta que se completa. El estado de ejecución de canalización es Stopping (Deteniéndose).

   En la vista de historial, el estado de las acciones en curso, como la acción de compilación, es In progress (En curso) hasta que se completa la acción de compilación. Mientras las acciones están en curso, el estado de ejecución de canalización es Stopping (Deteniéndose).

2. La ejecución se detiene cuando el proceso de detención se completa. Si la acción de compilación se completa correctamente, su estado es Succeeded (Correcto) y la ejecución de canalización muestra un estado de Stopping (Deteniéndose). Las acciones posteriores no se inician. El botón Retry (Reintentar) está habilitado.

   En la vista de historial, el estado de ejecución es Stopped (Detenido) después de completar la acción en curso.

   

Opción 2: Detener y abandonar

Cuando elige detener y abandonar, la ejecución seleccionada no espera a que se completen las acciones en curso. Las acciones se abandonan. Por ejemplo, la siguiente ejecución de canalización se ha detenido y abandonado mientras la acción de compilación estaba en curso.

1. En la vista de canalización, se muestra el mensaje de banner de realización correcta, la acción de compilación muestra un estado de In progress (En curso) y la ejecución de canalización muestra un estado de Stopping (Deteniéndose).

2. Después de que la ejecución de canalización se detiene, la acción de compilación muestra un estado de Abandoned (Abandonado) y la ejecución de canalización muestra un estado de Stopped (Detenido). Las acciones posteriores no se inician. El botón Retry (Reintentar) está habilitado.

3. En la vista de historial, el estado de ejecución es Stopped (Detenido).

   

Casos de uso para detener una ejecución de canalización

Le recomendamos que utilice la opción de detener y esperar para detener una ejecución de canalización. Esta opción es más segura porque evita posibles errores o posibles out-of-sequence tareas en proceso. Cuando se suspende una acción CodePipeline, el proveedor de la acción continúa con las tareas relacionadas con la acción. En el caso de una AWS CloudFormation acción, la acción de despliegue en proceso se suspende, pero la actualización de la pila podría continuar y provocar un error en la actualización.

Como ejemplo de acciones abandonadas que pueden dar lugar a out-of-sequence tareas, si implementa un archivo grande (1 GB) mediante una acción de implementación de S3 y decide detener y abandonar la acción mientras la implementación ya está en curso, la acción se suspende en Amazon S3 CodePipeline, pero continúa en Amazon S3. Amazon S3 no encuentra ninguna instrucción para cancelar la carga. A continuación, si inicia una nueva ejecución de canalización con un archivo muy pequeño, ahora hay dos implementaciones en curso. Debido a que el tamaño del archivo de la nueva ejecución es pequeño, la nueva implementación se completa mientras que la implementación anterior aún se está cargando. Cuando finaliza la implementación anterior, el archivo nuevo se sobrescribe con el anterior.

Es posible que desee utilizar la opción de detener y abandonar en el caso en que tenga una acción personalizada. Por ejemplo, puede abandonar una acción personalizada con un trabajo que no necesita terminarse antes de iniciar una nueva ejecución con una corrección de errores.

Cómo se procesan las ejecuciones en modo SUSTITUIDO

El modo predeterminado para procesar las ejecuciones es el modo SUPERSEDED. Una ejecución consta de un conjunto de cambios recogidos y procesados por la ejecución. Las canalizaciones pueden procesar varias ejecuciones al mismo tiempo. Cada ejecución se ejecuta a través de la canalización por separado. La canalización procesa cada ejecución en orden y puede reemplazar una ejecución anterior por otra posterior. Las siguientes reglas se utilizan para procesar las ejecuciones en una canalización en el modo SUPERSEDED.

Regla 1: las etapas se bloquean cuando se está procesando una ejecución

Dado que cada etapa puede procesar solo una ejecución a la vez, la etapa se bloquea mientras está en curso. Cuando la ejecución completa una etapa, pasa a la siguiente etapa de la canalización.

Antes: Stage 1 is locked as Execution 1 enters. Después: Stage 2 is locked as Execution 1 enters.

Regla 2: ejecuciones posteriores esperan a que se desbloquee la etapa

Mientras una etapa está bloqueada, las ejecuciones en espera se llevan a cabo delante de la etapa bloqueada. Todas las acciones configuradas para una etapa se deben completar correctamente para que la etapa se considere completada Un error libera el bloqueo en la etapa. Cuando se detiene una ejecución, esta no continúa en una etapa y la etapa se desbloquea.

nota

Antes de detener una ejecución, le recomendamos que desactive la transición antes de la etapa. De esta forma, cuando la etapa se desbloquea debido a la ejecución detenida, la etapa no acepta una ejecución de canalización posterior.

Antes: Stage 2 is locked as Execution 1 enters. Después: Execution 2 exits Stage 1 and waits between stages.

Regla 3: las ejecuciones en espera se sustituyen por ejecuciones más recientes

Las ejecuciones solo se sustituyen entre etapas. Una etapa bloqueada tiene una ejecución delante de la etapa a la espera de que la etapa se complete. Una ejecución más reciente adelanta a una ejecución en espera y continúa a la siguiente etapa tan pronto como se desbloquea la etapa. La ejecución sustituida no continúa. En este ejemplo, Ejecución 2 ha sido sustituido por Ejecución 3 mientras esperaba la etapa bloqueada. La ejecución 3 entra en la etapa siguiente.

Antes: la ejecución 2 espera entre etapas mientras que la ejecución 3 entra en la etapa 1. Después: la ejecución 3 sale de la etapa 1. La ejecución 2 se sustituye por la ejecución 3.

Para obtener más información sobre las consideraciones relacionadas con la visualización y el cambio entre los modos de ejecución, consulte. Establecer o cambiar el modo de ejecución de la canalización Para obtener más información sobre las cuotas con modos de ejecución, consulteCuotas en AWS CodePipeline.

Cómo se procesan las ejecuciones en modo COLA

En el caso de las canalizaciones en modo COLA, las etapas se bloquean cuando se procesa una ejecución; sin embargo, las ejecuciones en espera no sustituyen a las que ya se han iniciado.

Las ejecuciones en espera se agrupan en los puntos de entrada en fases bloqueadas en el orden en que llegan a la fase, formando una cola de ejecuciones en espera. Con el modo EN COLA, puedes tener varias colas en la misma canalización. Cuando una ejecución en cola entra en una fase, la fase se bloquea y no pueden entrar otras ejecuciones. Este comportamiento sigue siendo el mismo que en el modo SUPERSEDED. Cuando la ejecución finaliza la etapa, la etapa queda desbloqueada y lista para la siguiente ejecución.

El siguiente diagrama muestra cómo se ejecutan las etapas de un proceso de canalización en modo COLA. Por ejemplo, mientras la etapa de origen procesa la ejecución 5, las ejecuciones de la 6 y la 7 forman la cola #1 y esperan en el punto de entrada de la etapa. La siguiente ejecución de la cola se procesará una vez que se desbloquee la etapa.

Para obtener más información sobre las consideraciones a la hora de ver los modos de ejecución y cambiar de uno a otro, consulteEstablecer o cambiar el modo de ejecución de la canalización. Para obtener más información sobre las cuotas con modos de ejecución, consulteCuotas en AWS CodePipeline.

Cómo se procesan las ejecuciones en modo PARALELO

En el caso de las canalizaciones en modo PARALELO, las ejecuciones son independientes entre sí y no tienen que esperar a que se completen las demás para empezar. No hay colas. Para ver las ejecuciones paralelas en proceso, utilice la vista del historial de ejecuciones.

Utilice el modo PARALELO en entornos de desarrollo en los que cada función tiene su propia rama de funciones y se despliega en destinos que no comparten otros usuarios.

Para obtener más información sobre las consideraciones a la hora de ver los modos de ejecución y cambiar de uno a otro, consulteEstablecer o cambiar el modo de ejecución de la canalización. Para obtener más información sobre las cuotas con modos de ejecución, consulteCuotas en AWS CodePipeline.

Gestión del flujo de canalización

El flujo de ejecuciones de canalización puede controlarse mediante:

• Una transición, que controla el flujo de ejecuciones en la etapa. Las transiciones se pueden habilitar o deshabilitar. Cuando una transición está deshabilitada, las ejecuciones de canalizaciones no pueden entrar en la etapa. La ejecución en canalización que espera entrar en una etapa en la que la transición está deshabilitada se denomina ejecución entrante. Después de habilitar la transición, una ejecución entrante se moverá a la etapa y la bloqueará.

  Similar a las ejecuciones en espera de una etapa bloqueada, cuando una transición está deshabilitada, la ejecución que espera entrar en la etapa todavía puede ser sustituida por una nueva ejecución. Cuando se vuelve a habilitar una transición deshabilitada, entra en la etapa la ejecución más reciente, incluida la que sustituyó las ejecuciones anteriores mientras la transición estaba deshabilitada.

• Una acción de aprobación, que impide que una canalización pase a la siguiente acción hasta que se conceda permiso (por ejemplo, mediante la aprobación manual de una identidad autorizada). Puede utilizar una acción de aprobación si desea controlar el tiempo en que una canalización pasa a una etapa de producción final, por ejemplo.

  nota

  Una etapa con una acción de aprobación se bloquea hasta que se apruebe o rechace la acción de aprobación o se haya agotado el tiempo de espera. Una acción de aprobación con tiempo de espera se procesa de la misma manera que una acción con error.

• Un error, cuando una acción en una etapa no se completa correctamente. La revisión no pasa a la siguiente acción de la etapa o a la siguiente etapa de la canalización. Puede ocurrir lo siguiente:

  • Se repite manualmente la etapa que contiene las acciones con error. Esto reanuda la ejecución (reintenta las acciones con error y, si tienen éxito, continúa en la etapa/canalización).

  • Otra ejecución entra en la etapa con error y sustituye a la ejecución con error. En este punto, la ejecución con error no se puede volver a intentar.

Estructura recomendada de canalizaciones

Al decidir cómo debe fluir un cambio de código a través de su canalización, lo mejor es agrupar acciones relacionadas dentro de una etapa para que, cuando la etapa se bloquee, todas las acciones procesen la misma ejecución. Puede crear una etapa para cada entorno de Región de AWS aplicación o zona de disponibilidad, etc. Una canalización con demasiadas etapas (es decir, demasiado detallada) puede permitir demasiados cambios simultáneos, mientras que una canalización con muchas acciones en una etapa grande (demasiado amplia) puede tardar demasiado en lanzar un cambio.

Por ejemplo, una acción de prueba después de una acción de implementación en la misma etapa está garantizada para probar el mismo cambio que se ha implementado. En este ejemplo, se implementa un cambio en un entorno de prueba, se prueba y, a continuación, se implementa el último cambio desde el entorno de prueba en un entorno de producción. En el ejemplo recomendado, el entorno de prueba y el entorno de producción son etapas separadas.

Izquierda: acciones relacionadas de prueba, implementación y aprobación agrupadas (recomendado). Derecha: acciones relacionadas en etapas separadas (no recomendado).

Cómo funcionan las ejecuciones entrantes

Una ejecución entrante es una ejecución que espera a que una etapa, transición o acción no disponible esté disponible antes de continuar. Es posible que la siguiente etapa, transición o acción no esté disponible porque:

• Otra ejecución ya ha entrado en la siguiente etapa y la ha bloqueado.

• La transición para entrar en la siguiente etapa está desactivada.

Puede deshabilitar una transición para detener una ejecución entrante si quiere controlar si una ejecución actual tiene tiempo de completarse en las etapas posteriores o si desea detener todas las acciones en un momento determinado. Para determinar si tiene una ejecución entrante, puede ver la canalización en la consola o ver el resultado desde el comando get-pipeline-state.

Las ejecuciones entrantes se realizan con las siguientes consideraciones:

• En cuanto la acción, la transición o la fase bloqueada estén disponibles, la ejecución entrante en curso entrará en la fase y continuará su proceso.

• Mientras la ejecución entrante está en espera, se puede detener manualmente. Una ejecución entrante puede tener un estado InProgress, Stopped o Failed.

• Cuando una ejecución entrante se detiene o se produce un error, no se puede volver a intentar porque no hay acciones fallidas que reintentar. Cuando se detiene una ejecución entrante y se habilita la transición, la ejecución entrante detenida no continúa en la fase.

Puede ver o detener una ejecución entrante.