As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

CodePipeline conceitos

Modelar e configurar seu processo de lançamento automatizado é mais fácil se você entender os conceitos e termos usados em AWS CodePipeline. Aqui estão alguns conceitos que você deve conhecer ao usar CodePipeline.

Para obter um exemplo de DevOps pipeline, consulteDevOps exemplo de pipeline.

Os seguintes termos são usados em CodePipeline:

Pipelines

Um pipeline é uma estrutura de fluxo de trabalho que descreve como as alterações de software passam pelo processo de lançamento. Cada pipeline é composto por uma série de estágios.

Estágios

Um estágio é uma unidade lógica que você pode usar para isolar um ambiente e limitar o número de alterações simultâneas nesse ambiente. Cada estágio contém ações que são executadas nos artefatosdo aplicativo. Seu código-fonte é um exemplo de artefato. Um estágio pode ser um estágio de compilação, em que o código-fonte é compilado e os testes são executados. Também pode ser um estágio de implantação, em que o código é implantado em ambientes de tempo de execução. Cada estágio é composto por uma série de ações seriais ou paralelas.

Transições

Uma transição é o ponto em que uma execução de pipeline passa para o próximo estágio no pipeline. Você pode desativar a transição de entrada de um estágio para impedir que execuções entrem nesse estágio e habilitar a transição para permitir que as execuções continuem. Quando mais de uma execução chega a uma transição desabilitada, somente a execução mais recente continua com o próximo estágio quando a transição está habilitada. Isso significa que execuções mais recentes continuam substituindo execuções em espera enquanto a transição está desabilitada e, após a transição ser habilitada, a execução que continua é a execução de substituição.

Ações

Uma ação é um conjunto de operações executadas no código do aplicativo e configuradas para que as ações sejam executadas no pipeline em um ponto especificado. Isso pode incluir itens, como uma ação de origem de uma alteração no código, uma ação para implantar o aplicativo em instâncias e assim por diante. Por exemplo, um estágio de implantação pode conter uma ação de implantação que implanta código em um serviço de computação como Amazon EC2 ou. AWS Lambda

Os tipos de CodePipeline ação válidos são source buildtest,deploy,approval,, invoke e. Para obter uma lista de provedores de ação, consulte Provedores de ação válidos em CodePipeline .

As ações podem ser executadas em série ou em paralelo. Para obter informações sobre ações seriais e paralelas em um estágio, consulte as informações runOrder nos requisitos de estrutura de ação.

Execuções de pipeline

Uma execução é um conjunto de alterações liberadas por um pipeline. Cada execução de pipeline é única e tem seu próprio ID. Uma execução corresponde a um conjunto de alterações, como uma confirmação mesclada ou uma liberação manual da última confirmação. Duas execuções podem liberar o mesmo conjunto de alterações em momentos diferentes.

Embora um pipeline possa processar várias execuções ao mesmo tempo, um estágio do pipeline processa apenas uma execução por vez. Para fazer isso, um estágio é bloqueado enquanto processa uma execução. Duas execuções de pipeline não podem ocupar o mesmo estágio ao mesmo tempo. A execução que está esperando para entrar no estágio ocupado é chamada de execução de entrada. Uma execução de entrada ainda pode falhar, ser substituída ou ser interrompida manualmente. Para obter mais informações sobre como as execuções de entrada funcionam, consulte Como funcionam as execuções de entrada.

As execuções de pipeline atravessam estágios de pipeline em ordem. Os status válidos para pipelines são InProgress, Stopping, Stopped, Succeeded, Superseded e Failed.

Para obter mais informações, consulte PipelineExecution.

Execuções interrompidas

A execução do pipeline pode ser interrompida manualmente para que a execução do pipeline em andamento não continue pelo pipeline. Se for interrompida manualmente, uma execução de pipeline mostrará um status Stopping até que ela seja completamente interrompida. Depois, ela mostrará um status Stopped. Uma execução de pipeline Stopped pode ser repetida.

Há duas maneiras de interromper a execução de um pipeline:

Para obter informações sobre casos de uso para interromper uma execução e detalhes de sequência para essas opções, consulte Como as execuções de pipeline são interrompidas.

Execuções com falha

Se uma execução falhar, ela será parada e não atravessará o pipeline completamente. Seu status é FAILED e o estágio é desbloqueado. Uma execução mais recente pode recuperar o atraso e entrar no estágio desbloqueado e bloqueá-lo. Você pode tentar uma execução com falha novamente, a menos que a execução com falha tenha sido substituída ou não possa ser repetida. Você pode reverter um estágio com falha para uma execução anterior bem-sucedida.

Modos de execução

Para fornecer o conjunto mais recente de alterações por meio de um pipeline, execuções mais recentes passam e substituem execuções menos recentes que já estão sendo executadas por meio do pipeline. Quando isso ocorre, a execução mais antiga é substituída pela execução mais recente. Uma execução pode ser substituída por uma execução mais recente em um determinado ponto, que é o ponto entre estágios. SUPERSEDEDé o modo de execução padrão.

No SUPERSEDED modo, se uma execução estiver esperando para entrar em um estágio bloqueado, uma execução mais recente pode recuperá-la e substituí-la. A execução mais recente agora aguarda o desbloqueio do estágio, e a execução substituída é interrompida com um status SUPERSEDED. Quando uma execução de pipeline é substituída, a execução é interrompida e não atravessa completamente o pipeline. Não é mais possível tentar a execução substituída novamente depois que ela tiver sido substituída nesse estágio. Outros modos de execução disponíveis são o QUEUED modo PARALLEL ou.

Para obter mais informações sobre modos de execução e estágios bloqueados, consulteComo as execuções são processadas no SUPERSEDED modo.

Operações de palco

Quando a execução de um pipeline passa por um estágio, o estágio está no processo de concluir todas as ações dentro dele. Para obter informações sobre como as operações de estágio funcionam e informações sobre estágios bloqueados, consulteComo as execuções são processadas no SUPERSEDED modo.

Os status válidos dos estágios são InProgress, Stopping, Stopped, Succeeded e Failed. Você pode repetir um estágio com falha, a menos que o estágio com falha não possa ser repetido. Para obter mais informações, consulte StageExecution. Você pode reverter um estágio para uma execução anterior bem-sucedida especificada. Um estágio pode ser configurado para reverter automaticamente em caso de falha, conforme detalhado emConfigurando a reversão de estágio. Para obter mais informações, consulte RollbackStage.

Execuções de ação

Uma execução de ação é o processo de conclusão de uma ação configurada que opera em artefatos designados. Esses podem ser artefatos de entrada, artefatos de saída ou ambos. Por exemplo, uma ação de compilação pode executar comandos de compilação em um artefato de entrada, como compilar o código-fonte do aplicativo. Os detalhes da execução da ação incluem um ID de execução da ação, o gatilho de origem de execução do pipeline relacionado e os artefatos de entrada e saída da ação.

Os status válidos das ações são InProgress, Abandoned, Succeeded e Failed. Para obter mais informações, consulte ActionExecution.

Tipos de execução

A execução de um pipeline ou estágio pode ser uma execução padrão ou revertida.

Para tipos padrão, a execução tem um ID exclusivo e é uma execução completa do pipeline. Uma reversão do pipeline tem um estágio a ser revertido e uma execução bem-sucedida do estágio como a execução alvo para a qual reverter. A execução do pipeline de destino é usada para recuperar revisões e variáveis de origem para que o estágio seja executado novamente.

Tipos de ação

Os tipos de ação são ações pré-configuradas que estão disponíveis para seleção em CodePipeline. O tipo de ação é definido por seu proprietário, provedor, versão e categorial O tipo de ação fornece parâmetros personalizados que são usados para concluir as tarefas de ação em um pipeline.

Para obter informações sobre os produtos Serviços da AWS e serviços de terceiros que você pode integrar ao seu pipeline com base no tipo de ação, consulteIntegrações com tipos de CodePipeline ação.

Para obter informações sobre os modelos de integração compatíveis com os tipos de ação em CodePipeline, consulteReferência do modelo de integração.

Para obter informações sobre como provedores terceirizados podem configurar e gerenciar tipos de ação em CodePipeline, consulteComo trabalhar com tipos de ação.

Artefatos

Os artefatos se referem à coleta de dados, como código-fonte de aplicativo, aplicativos criados, dependências, arquivos de definições, modelos e assim por diante, que são trabalhados por ações de pipeline. Os artefatos são produzidos por algumas ações e consumidos por outras. Em um pipeline, os artefatos podem ser o conjunto de arquivos trabalhados por uma ação (artefatos de entrada) ou a saída atualizada de uma ação concluída (artefatos de saída).

As ações passam a saída para outra ação para processamento adicional usando o bucket de artefatos do pipeline. CodePipeline copia artefatos para a loja de artefatos, onde a ação os coleta. Para obter mais informações sobre artefatos, consulte Artefatos de entrada e saída.

Revisões de origem

Quando você faz uma alteração no código-fonte, uma versão é criada. Uma revisão de origem é a versão de uma alteração de origem que aciona uma execução de pipeline. Uma execução processa as revisões da fonte. Para repositórios GitHub e CodeCommit repositórios, esse é o commit. Para buckets ou ações do S3, essa é a versão do objeto.

É possível iniciar a execução de um pipeline com uma revisão de origem, como uma confirmação, especificada por você. A execução processará a revisão especificada e substituirá o que teria sido a revisão usada para a execução. Para obter mais informações, consulte Iniciar um pipeline com uma substituição da revisão de origem.

Acionadores

Os gatilhos são eventos que acionam seu pipeline. Alguns gatilhos, como o acionamento de um pipeline manualmente, estão disponíveis para todos os provedores de ação de origem em um pipeline. Determinados gatilhos dependem do provedor de origem de um pipeline. Por exemplo, CloudWatch os eventos devem ser configurados com recursos de eventos da Amazon CloudWatch que tenham o pipeline ARN adicionado como destino na regra do evento. O Amazon CloudWatch Events é o gatilho recomendado para detecção automática de alterações em pipelines com uma ação de origem CodeCommit ou S3. Os webhooks são um tipo de gatilho configurado para eventos de repositórios de terceiros. Por exemplo, o WebhookV2 é um tipo de gatilho que permite que as tags Git sejam usadas para iniciar pipelines com provedores de origem terceirizados, como GitHub .com, GitHub Enterprise Server, .com, autogerenciado ou GitLab Bitbucket Cloud. GitLab Na configuração do pipeline, você pode especificar um filtro para acionadores, como push ou pull request. Você pode filtrar eventos de push de código em tags, ramificações ou caminhos de arquivo do Git. Você pode filtrar eventos de pull request em eventos (abertos, atualizados, fechados), ramificações ou caminhos de arquivo.

Para obter mais informações sobre gatilhos, consulte Inicie um funil em CodePipeline. Para assistir a um tutorial que explica como usar as tags Git como gatilhos no pipeline, consulte Tutorial: Usar tags do Git para iniciar o pipeline.

Variáveis

Uma variável é um valor que pode ser usado para configurar ações dinamicamente em seu pipeline. As variáveis podem ser declaradas no nível do pipeline ou emitidas por ações no pipeline. Os valores de variáveis são resolvidos no momento da execução do pipeline e podem ser visualizados no histórico da execução. Para variáveis declaradas no nível do pipeline, você pode definir valores padrão na configuração do pipeline ou substituí-los para uma determinada execução. Para variáveis emitidas por uma ação, o valor fica disponível após a conclusão bem-sucedida de uma ação. Para obter mais informações, consulte Referência de variáveis.

Condições

Uma condição contém um conjunto de regras que são avaliadas. Se todas as regras em uma condição forem bem-sucedidas, a condição será atendida. Você pode configurar condições para que, quando os critérios não forem atendidos, o resultado especificado, como a falha no estágio, seja ativado. As condições também são chamadas de portas porque permitem que você especifique quando uma execução entrará e passará por um estágio ou sairá do estágio depois de passar por ele. Isso é análogo a permitir que uma linha de tráfego em uma estrada se reúna em um portão fechado e, em seguida, especificar a abertura do portão para permitir o fluxo de tráfego em uma área. Os resultados dos tipos de condição incluem falhar no estágio ou reverter o estágio. As condições ajudam você a especificar quando essas ações acontecem em um estágio do pipeline. Você pode substituir as condições em tempo de execução.

Há três tipos de condições. As condições de entrada respondem à pergunta “Se as regras da condição forem atendidas, entre no estágio”. O estágio é bloqueado quando a execução entra no estágio e, em seguida, as regras são executadas. Para condições de falha, a regra é ativada quando um estágio falha, resultando na reversão de um estágio com falha. Para condições de sucesso, a regra é ativada quando um estágio é bem-sucedido, como verificar se há alarmes em uma execução bem-sucedida antes de continuar. Por exemplo, uma condição On Success resultaria na reversão de um estágio bem-sucedido se a CloudWatchAlarm regra constatasse que há alarmes no ambiente de implantação. Para obter mais informações, consulte Como funcionam as condições do palco?.

Regras

As condições usam uma ou mais regras pré-configuradas que executam e realizam verificações que, em seguida, ativarão o resultado configurado para quando a condição não for atendida. Por exemplo, atender a todas as regras de uma regra de condição de entrada que verifica o status do alarme e os horários das janelas de implantação implantará um estágio bem-sucedido após a aprovação de todas as verificações. Para obter mais informações, consulte Como funcionam as condições do palco?.