CodePipeline conceptos - AWS CodePipeline

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

CodePipeline conceptos

Modelar y configurar su proceso de publicación automática es más fácil si comprende los conceptos y términos utilizados en él AWS CodePipeline. Estos son algunos conceptos que debe conocer a medida que los utilice CodePipeline.

Para ver un ejemplo de DevOps canalización, consulteDevOps ejemplo de canalización.

Los siguientes términos se utilizan en CodePipeline:

Canalizaciones

Una canalización es una construcción de flujo de trabajo que describe cómo los cambios en el software pasan por el proceso de lanzamiento. Cada canalización se compone de una serie de etapas.

Escenarios

Una etapa es una unidad lógica que puede utilizar para aislar un entorno y limitar el número de cambios simultáneos en ese entorno. Cada etapa contiene acciones que se realizan en los artefactos de la aplicación. El código fuente es un ejemplo de un artefacto. Una etapa podría ser una etapa de compilación, donde se compila el código fuente y se ejecutan pruebas. También puede ser una etapa de implementación, donde el código se implementa en entornos de tiempo de ejecución. Cada etapa se compone de una serie de acciones en serie o en paralelo.

Transiciones

Una transición es el punto en el que la ejecución de una canalización se mueve a la siguiente etapa de la canalización. Puede deshabilitar la transición entrante de una etapa para evitar que las ejecuciones entren en esa etapa y, a continuación, puede habilitar la transición para permitir que las ejecuciones continúen. Cuando llega más de una ejecución a una transición deshabilitada, solo la ejecución más reciente continúa hasta la siguiente etapa cuando se habilita la transición. Esto significa que las ejecuciones más recientes continúan sustituyendo a las ejecuciones en espera mientras la transición está deshabilitada y, a continuación, una vez habilitada la transición, la ejecución que continúa es la ejecución sustituida.

Una canalización consta de etapas, que contienen acciones, que están separadas por transiciones que se pueden habilitar y deshabilitar.

Acciones

Una acción es un conjunto de operaciones realizadas en el código de la aplicación y configuradas para que las acciones se ejecuten en la canalización en un punto especificado. Esto puede incluir cosas como una acción de origen a partir de un cambio de código, una acción para implementar la aplicación en instancias, etc. Por ejemplo, una etapa de despliegue puede contener una acción de despliegue que despliegue código en un servicio de cómputo como Amazon EC2 o AWS Lambda.

Los tipos de CodePipeline acción válidos son sourcebuild,test, deployapproval, yinvoke. Para obtener una lista de los proveedores de acciones, consulte Proveedores de acciones válidos en CodePipeline .

Las acciones se pueden ejecutar en serie o en paralelo. Para obtener información sobre las acciones en serie y paralelas en una etapa, consulte la información de runOrder en los requisitos de la estructura de acciones.

Ejecuciones de canalización

Una ejecución es un conjunto de cambios lanzados por una canalización. Cada ejecución de canalización es única y tiene su propio ID. Una ejecución corresponde a un conjunto de cambios, como una confirmación combinada o una versión manual de la última confirmación. Dos ejecuciones pueden lanzar el mismo conjunto de cambios en diferentes momentos.

Mientras que una canalización puede procesar varias ejecuciones al mismo tiempo, una etapa de canalización procesa solo una ejecución a la vez. Para hacer esto, una etapa se bloquea mientras procesa una ejecución. Dos ejecuciones de una canalización no pueden ocupar la misma etapa al mismo tiempo. La ejecución que espera para entrar en la etapa ocupada se denomina ejecución entrante. Una ejecución entrante aún puede fallar, ser reemplazada o detenida manualmente. Para obtener más información sobre cómo funcionan las ejecuciones entrantes, consulte Cómo funcionan las ejecuciones entrantes.

Las ejecuciones de canalizaciones atraviesan etapas de canalización en orden. Los estados válidos para las canalizaciones son InProgress, Stopping, Stopped, Succeeded, Superseded y Failed.

Para obtener más información, consulte PipelineExecution.

Ejecuciones detenidas

La ejecución de la canalización se puede detener manualmente para que la ejecución de la canalización en curso no continúe por la canalización. Si se detiene manualmente, una ejecución de canalización muestra un estado Stopping hasta que se detiene por completo. Después, muestra un estado Stopped. Se puede volver a intentar una ejecución de canalización Stopped.

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

  • Detener y esperar

  • Detener y abandonar

Para obtener información sobre los casos de uso para detener una ejecución y detalles de la secuencia para estas opciones, consulte Cómo se detienen las ejecuciones de canalización.

Ejecuciones con error

Si una ejecución genera un error, se detiene y no atraviesa completamente la canalización. Su estado es FAILED y la etapa está desbloqueada. Una ejecución más reciente puede ponerse al día y entrar en la etapa desbloqueada y bloquearla. Puede volver a intentar una ejecución fallida a menos que la ejecución fallida haya sido sustituida o no se pueda volver a intentar. Puede revertir una etapa fallida a una ejecución anterior exitosa.

Modos de ejecución

Para entregar el último conjunto de cambios a través de una canalización, las ejecuciones más recientes pasan y sustituyen las ejecuciones menos recientes que ya se ejecutan a través de la canalización. Cuando esto ocurre, la ejecución más reciente sustituye a la ejecución anterior. Una ejecución más reciente puede sustituir una ejecución en un punto determinado, que es el punto entre etapas. SUPERSEDEDes el modo de ejecución por defecto.

En SUPERSEDED el modo, si una ejecución está esperando para entrar en una fase bloqueada, una ejecución más reciente podría ponerla al día y sustituirla. La ejecución más reciente ahora espera a que la etapa se desbloquee y la ejecución sustituida se detiene con un estado SUPERSEDED. Cuando se sustituye una ejecución de canalización, la ejecución se detiene y no atraviesa completamente la canalización. Ya no puede volver a intentar la ejecución sustituida después de que se haya reemplazado en esta etapa. Otros modos de ejecución disponibles son el QUEUED modo PARALLEL o.

Para obtener más información sobre los modos de ejecución y las etapas bloqueadas, consulteCómo se procesan las ejecuciones en SUPERSEDED modo.

Etapa las operaciones

Cuando la ejecución de una canalización pasa por una etapa, ésta se encuentra en el proceso de completar todas las acciones incluidas en ella. Para obtener información sobre cómo funcionan las operaciones de las etapas e información sobre las etapas bloqueadas, consulteCómo se procesan las ejecuciones en SUPERSEDED modo.

Los estados válidos para las etapas son InProgress, Stopping, Stopped, Succeeded y Failed. Puede volver a intentar una etapa fallida a menos que la etapa fallida no se pueda volver a intentar. Para obtener más información, consulte StageExecution. Puede hacer retroceder una etapa a una ejecución exitosa anterior especificada. Se puede configurar una etapa para que se revierta automáticamente en caso de fallo, tal y como se detalla enConfiguración de la reversión de etapas. Para obtener más información, consulte RollbackStage.

Ejecuciones de acción

Una ejecución de acción es el proceso de completar una acción configurada que opera en artefactos designados. Estos pueden ser artefactos de entrada, artefactos de salida o ambos. Por ejemplo, una acción de compilación podría ejecutar comandos de compilación en un artefacto de entrada, como compilar código fuente de la aplicación. Los detalles de ejecución de acciones incluyen un ID de ejecución de acción, el desencadenador de origen de ejecución de canalización relacionado y los artefactos de entrada y salida de la acción.

Los estados válidos para las acciones son InProgress, Abandoned, Succeeded o Failed. Para obtener más información, consulte ActionExecution.

Tipos de ejecución

Una ejecución en canalización o fase puede ser una ejecución estándar o una ejecución inversa.

En el caso de los tipos estándar, la ejecución tiene un identificador único y es una ejecución en proceso completa. Una reversión en proceso tiene una etapa que debe revertirse y una ejecución exitosa como la ejecución objetivo a la que se debe retroceder. La ejecución del proceso objetivo se utiliza para recuperar las revisiones y variables de origen para que la etapa se vuelva a ejecutar.

Tipos de acción

Los tipos de acciones son acciones preconfiguradas que se pueden seleccionar en ellas. CodePipeline El tipo de acción se define mediante su propietario, proveedor, versión y categoría. El tipo de acción proporciona parámetros personalizados que se utilizan para completar las tareas de acción de una canalización.

Para obtener información sobre los productos Servicios de AWS y servicios de terceros que puedes integrar en tu proceso en función del tipo de acción, consultaIntegraciones con tipos de CodePipeline acciones.

Para obtener información sobre los modelos de integración compatibles con los tipos de acción CodePipeline, consulteReferencia del modelo de integración.

Para obtener información sobre cómo los proveedores externos pueden configurar y gestionar los tipos de acciones CodePipeline, consulteTrabajar con tipos de acciones.

Artefactos

Los artefactos se refieren a la recopilación de datos, como el código fuente de la aplicación, las aplicaciones compiladas, las dependencias, los archivos de definiciones, las plantillas, etc., en los que se trabaja mediante acciones de canalización. Algunas acciones producen artefactos y otras los consumen. En una canalización, los artefactos pueden ser el conjunto de archivos en los que trabaja una acción (artefactos de entrada) o la salida actualizada de una acción completada (artefactos de salida).

Las acciones pasan el resultado a otra acción para su posterior procesamiento mediante el depósito de artefactos de canalización. CodePipeline copia los artefactos a la tienda de artefactos, donde la acción los recoge. Para obtener más información acerca de los artefactos, consulte Artefactos de entrada y salida.

Revisiones de origen

Cuando se realiza un cambio de código fuente, se crea una nueva versión. Una revisión de código fuente es la versión de un cambio de código fuente que desencadena una ejecución de canalización. Una ejecución procesa las revisiones de la fuente. En el GitHub caso de CodeCommit los repositorios y repositorios, esta es la confirmación. Para acciones o buckets de S3, es la versión del objeto.

Puede iniciar la ejecución de una canalización con una revisión de código fuente, como una confirmación, que especifique. La ejecución procesará la revisión especificada y anulará la que hubiera sido la revisión utilizada para la ejecución. Para obtener más información, consulte Iniciar una canalización con una anulación de revisión de código fuente.

Desencadenadores

Los desencadenadores son eventos que inician tu canalización. Algunos desencadenadores, como el inicio manual de una canalización, están disponibles para todos los proveedores de acciones fuente de una canalización. Algunos desencadenadores dependen del proveedor de origen de la canalización. Por ejemplo, CloudWatch los eventos deben configurarse con recursos de eventos de Amazon a los CloudWatch que se haya ARN agregado la canalización como destino en la regla de eventos. Amazon CloudWatch Events es el activador recomendado para la detección automática de cambios en las canalizaciones con una acción de origen CodeCommit o S3. Los webhooks son un tipo de desencadenador que se configura para eventos de repositorios de terceros. Por ejemplo, WebHookV2 es un tipo de disparador que permite utilizar etiquetas de Git para iniciar canalizaciones con proveedores de fuentes de terceros, como GitHub .com, GitHub Enterprise Server, GitLab .com, GitLab self-managed o Bitbucket Cloud. En la configuración de canalización, puedes especificar un filtro para los activadores, como las solicitudes push o las pull request. Puedes filtrar los eventos de inserción de código en las etiquetas, ramas o rutas de archivos de Git. Puedes filtrar los eventos de las solicitudes de extracción por eventos (abiertos, actualizados, cerrados), ramas o rutas de archivos.

Para obtener más información acerca de los disparadores, consulte Iniciar una canalización en CodePipeline. Para ver un tutorial que te explica cómo usar las etiquetas de Git como desencadenadores de tu canalización, consulte Tutorial: Usar etiquetas de Git para iniciar la canalización.

Variables

La variable es un valor que puede utilizarse para configurar dinámicamente las acciones de su canalización. Las variables pueden declararse a nivel de canalización o emitirse mediante acciones en la canalización. Los valores de las variables se resuelven en el momento de la ejecución de la canalización y se pueden ver en el historial de ejecuciones. En el caso de las variables declaradas a nivel de canalización, puede definir los valores predeterminados en la configuración de la canalización o anularlos para una ejecución determinada. En el caso de las variables emitidas por una acción, el valor está disponible después de que la acción se complete correctamente. Para obtener más información, consulte Referencia de variables.

Condiciones

Una condición contiene un conjunto de reglas que se evalúan. Si todas las reglas de una condición se cumplen correctamente, se cumple la condición. Puede configurar las condiciones para que, cuando no se cumplan los criterios, se active el resultado especificado (por ejemplo, no superar la fase). Las condiciones también se denominan puertas porque permiten especificar cuándo una ejecución entrará y pasará por una etapa o saldrá de la etapa después de haberla atravesado. Esto equivale a permitir que una línea de tráfico de una carretera se junte en una puerta cerrada y, a continuación, especificar la apertura de la puerta para permitir el flujo de tráfico hacia una zona. Los resultados para los distintos tipos de condiciones incluyen reprobar la etapa o hacerla retroceder. Las condiciones ayudan a especificar cuándo se producen estas acciones en una fase de proceso. Puede anular las condiciones en tiempo de ejecución.

Existen tres tipos de condiciones. Las condiciones de entrada responden a la pregunta «Si se cumplen las reglas de la condición, entonces ingrese al escenario». La etapa se bloquea cuando la ejecución entra en la etapa y, a continuación, se ejecutan las reglas. En caso de fallo, la regla se activa cuando se produce un error en una etapa, con el resultado de anular una etapa fallida. En las condiciones de éxito, la regla se activa cuando una etapa se ejecuta correctamente, por ejemplo, cuando se comprueba si hay alarmas en una ejecución correcta antes de continuar. Por ejemplo, si la regla detecta que hay alarmas en el entorno de despliegue, se anulará una fase correcta si la CloudWatchAlarm regla detecta que hay alarmas en el entorno de despliegue. Para obtener más información, consulte ¿Cómo funcionan las condiciones del escenario?.

Reglas

Las condiciones utilizan una o más reglas preconfiguradas que se ejecutan y realizan comprobaciones que, a su vez, activarán el resultado configurado para cuando no se cumpla la condición. Por ejemplo, si se cumplen todas las reglas de una condición de entrada que comprueba el estado de las alarmas y los plazos de despliegue, se implementará correctamente una vez superadas todas las comprobaciones. Para obtener más información, consulte ¿Cómo funcionan las condiciones del escenario?.