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.
Conceptos de CodePipeline
El modelado y la configuración del proceso de lanzamiento automatizado es más fácil si comprende los conceptos y términos utilizados en AWS CodePipeline. Aquí encontrará algunos conceptos que debe conocer sobre el uso de CodePipeline.
Para obtener un ejemplo de una canalización de DevOps, consulte DevOps ejemplo de canalización.
Los siguientes términos se utilizan en CodePipeline:
Temas
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.](images/pipeline-elements-workflow.png)
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 implementación puede contener una acción de implementación que implemente código en un servicio informático como Amazon EC2 o AWS Lambda.
Los tipos de acciones de CodePipeline válidos son source
, build
, test
, deploy
, approval
y invoke
. 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 que se realizara correctamente.
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. SUPERSEDED es el modo de ejecución predeterminado.
En el modo SUPERSEDED, si una ejecución está esperando para entrar en una etapa bloqueada, una ejecución más reciente podría ponerse 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 modo PARALELO o EN COLA.
Para obtener más información acerca de los modos de ejecución y las etapas bloqueadas, consulte Procesamiento de ejecuciones en el modo SUPERSEDED.
Operaciones de etapas
Cuando una ejecución de canalización se ejecuta a través de una etapa, la etapa se encontrará en el proceso de completar todas las acciones que haya en ella. Para obtener información sobre cómo funcionan las operaciones de etapas e información sobre las etapas bloqueadas, consulte Procesamiento de ejecuciones en el modo SUPERSEDED.
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 revertir una etapa a una ejecución anterior que se realizara correctamente. Se puede configurar una etapa para que se revierta automáticamente en caso de fallo, tal y como se detalla en Configuració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 de etapa o canalización puede ser una ejecución estándar o una ejecución revertida.
En el caso de los tipos estándar, la ejecución tiene un identificador único y es una ejecución de canalización completa. La reversión de una canalización tiene una etapa que debe revertirse y una ejecución exitosa de la etapa como la ejecución de destino a la que se debe revertir. La ejecución de la canalización de destino se utiliza para recuperar las variables y revisiones de origen para que la etapa se vuelva a ejecutar.
Tipos de acción
Los tipos de acciones son acciones preconfiguradas que están disponibles para su selección en 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 servicios de Servicios de AWS y los productos y servicios de socios que puede integrar en su canalización según el tipo de acción, consulte Integraciones con tipos de CodePipeline acciones.
Para obtener información sobre los modelos de integración compatibles con los tipos de acción en CodePipeline, consulte Referencia del modelo de integración.
Para obtener información sobre cómo los proveedores externos pueden configurar y administrar los tipos de acciones en CodePipeline, consulte Trabajar 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 bucket de artefactos de canalización. CodePipeline copia los artefactos en el almacén 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 origen. En los repositorios de GitHub y CodeCommit, 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, los eventos de CloudWatch deben configurarse con recursos de eventos de Amazon CloudWatch a los que se haya agregado el ARN de la canalización como destino en la regla del evento. Eventos de Amazon CloudWatch es el desencadenador recomendado para la detección automática de cambios en las canalizaciones con una acción de origen de 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 desencadenador que permite usar etiquetas de Git para iniciar canalizaciones con proveedores de origen externos, como GitHub.com, GitHub Enterprise Server, GitLab.com, GitLab self-managed o Bitbucket Cloud. En la configuración de la canalización, puede especificar un filtro para los desencadenadores, como las solicitudes de inserción o de extracción. Puede filtrar los eventos de inserción de código en ramificaciones, rutas de archivo o etiquetas de Git. También puede filtrar los eventos de solicitud de extracción por evento (abierto, actualizado, cerrado), ramificaciones o rutas de archivo.
Para obtener más información acerca de los disparadores, consulte Inicio de 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 realizan correctamente, se cumple la condición. Puede configurar las condiciones para que, cuando no se cumplan los criterios, se active el resultado especificado como, por ejemplo, que la etapa falle. Las condiciones también se denominan “puertas”, ya que permiten especificar cuándo una ejecución entrará y se ejecutará en una etapa, o bien cuándo saldrá de la etapa después de haberse ejecutado en ella. Como analogía, 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 dicha puerta para permitir el flujo de tráfico hacia una zona determinada. Los resultados para los tipos de condición incluyen el fallo de la etapa o la reversión de la etapa. Las condiciones ayudan a especificar cuándo se producen estas acciones en una etapa de canalización. Es posible 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, la ejecución puede entrar en la etapa”. La etapa se bloquea cuando la ejecución entra en dicha etapa y, a continuación, se ejecutan las reglas. En condiciones de fallo, la regla se activa cuando se produce un error en una etapa, con el resultado de revertir una etapa fallida. En condiciones de éxito, la regla se activa cuando una etapa se realiza correctamente, por ejemplo, cuando se comprueba si hay alarmas en una ejecución correcta antes de continuar. Por ejemplo, si la regla CloudWatchAlarm detecta que hay alarmas en el entorno de implementación, la condición de éxito provocará la reversión de una etapa correcta. Para obtener más información, consulte Funcionamiento de las condiciones de las etapas.
Reglas
Las condiciones utilizan una o más reglas preconfiguradas que se ejecutan y que realizan comprobaciones que, a su vez, activarán el resultado configurado cuando no se cumpla una condición. Por ejemplo, si se cumplen todas las reglas de una regla de condición de entrada que comprueba el estado de las alarmas y los plazos de implementación, se implementará correctamente una etapa después de que todas las comprobaciones se superen. Para obtener más información, consulte Funcionamiento de las condiciones de las etapas.