Tipos de status do pipeline

Em determinados pontos, é importante entender as condições de erro ou de falha para um pipeline de referência. Do ponto de vista conceitual, uma execução de tarefa em um pipeline em conformidade pode resultar em dois tipos diferentes de status:

• Status de conformidade: o estado de aprovação ou de falha de uma verificação some ou de um conjunto de verificações.
• Status do pipeline: o estado de êxito ou de falha de uma execução de tarefa em si.

Uma falha em um teste, uma varredura ou uma verificação não causa a falha ou interrupção do pipeline em si; a tarefa que executa o teste é marcada como verde.

Do ponto de vista de conformidade, o resultado do teste de unidade não afeta a implementação. É possível implementar artefatos que tenham verificações com falha, mas o processo mantém evidências sobre essa atividade. O fluxo de conformidade não impede a liberação de uma correção quando há uma situação de indisponibilidade. Por exemplo, quando uma execução de uma tarefa de teste de unidade que encontrou testes com falha é marcada como verde, isso significa que The task ran successfully and found the following issues.

Caso uma tarefa falhe com um status vermelho, isso ocorre porque o pipeline não pode, ou não deve, continuar. As condições de exemplo de falha incluem:

• Erros em uma tarefa ou em um pipeline.
• Algum evento ocorrido torna desnecessário dar continuidade à execução do pipeline.

Por exemplo, a falha de uma construção de artefato durante a integração contínua é contrária à própria finalidade do processo de integração contínua.

Para manter a sincronização entre o status final do pipeline e os resultados de conformidade, utiliza-se uma tarefa no final do pipeline, que verifica os resultados de conformidade e configura o status de execução do pipeline como red ou green.

Pipelines de solicitações pull

O pipeline de solicitações pull executa verificações de status de conformidade pré-configuradas em uma solicitação pull para o repositório (repo) de aplicativo (app) especificado. Essas verificações de status podem impedir que você faça o merge do pull request no branch ativo padrão, geralmente master, se as verificações não forem bem-sucedidas. Abra ou atualize uma pull request no branch ativo padrão para acionar a execução do pipeline de pull request. Os usuários podem executar sua própria configuração para o pipeline e os testes em estágios customizados. Para obter mais informações sobre o pipeline de solicitações pull, consulte Pipeline de solicitações pull.

Pipeline de integração contínua

O pipeline de integração contínua constrói os artefatos implementáveis a partir dos repositórios (repos) do aplicativo (app). Antes de construir os artefatos, o pipeline verifica se o código foi escaneado e testado, como é feito para o processamento de solicitações pull. Os artefatos construídos também são escaneados em busca de vulnerabilidades e são inscritos no pipeline antes de serem considerados prontos para liberação e implementação no inventário. Ao contrário do pipeline de solicitações pull, o pipeline de integração contínua coleta artefatos de evidências e de resultados em cada estágio da construção, como as fases de teste, varredura e assinatura. Esses dados estão associados aos artefatos de construção e podem ser acompanhados pelo processo de implementação e gerenciamento de mudanças. Para obter mais informações sobre o pipeline de integração contínua, consulte Pipeline de integração contínua.

Pipeline de implementação contínua

O pipeline de implantação contínua gera todas as evidências e o conteúdo do resumo da solicitação de alteração. O pipeline implementa os artefatos de construção em um ambiente específico, como preparação ou produção e, em seguida, coleta, cria e faz upload de todos os arquivos de log, evidências e artefatos existentes, colocando-os no armazenamento de evidências. Para obter mais informações sobre o pipeline de implementação contínua, consulte Gasoduto de implementação contínua.

Pipeline de conformidade contínua

O pipeline de conformidade contínua varre periodicamente os artefatos implementados e seus repositórios de origem para vulnerabilidades mais recentes desde que os artefatos foram implementados em produção. O pipeline também ajuda a rastrear automaticamente os desvios com a data de vencimento e oferece reconhecimento do aplicativo. Para obter mais informações, consulte Pipeline de conformidade contínua.

Fluxo de trabalho de inventário

Consulte Evidências.

Consulte Inventário.

Cenário de inventário

No estado de implementação atual está o conteúdo a ser implementado em um ambiente. Cada commit promovido nas ramificações de destino possui como tag o Pipeline Run ID e o Change Request ID relevantes. Alguns commits podem ter várias tags, como quando uma implementação com falha é executada novamente. No inventário, são mantidas todas as informações necessárias para reproduzir as implementações.

Uso de tags

• latest: identifica o estado atual de implementação bem-sucedida e concluída do inventário em uma ramificação.
• pipeline run id: identifica o estado de inventário mais recente na ramificação, com o ID de execução do pipeline ou o número de construção da implementação real. Para evitar sobreposição do conteúdo do inventário, caso sejam acionadas implementações paralelas, use essa tag para fazer referência ao hash de ponto real do inventário no histórico da ramificação.
• change request id: opcional. Identifica o estado atual. Os IDs de solicitações de mudança são historicamente representados e rastreados no inventário.

Configuração de destino único com várias regiões

A configuração de destino único com várias regiões é uma iteração desse modelo, em que são introduzidas várias tags latest para um único ambiente de destino. Esse modelo permite que vários pipelines contínuos funcionem no mesmo destino para diferentes tipos de casos de uso.

Por exemplo, é possível usar o mesmo ambiente de destino para várias regiões (como us-south e eu-de) no ambiente de destino de produção e na ramificação de inventário.

Para especificar a região de implementação pelo pipeline de implementação contínua, use o parâmetro region. Para obter mais informações sobre esse parâmetro, consulte Parâmetros de pipeline de implementação contínua.

As equipes não precisam configurar uma filial diferente para cada região, como us-south-prod e eu-de-prod, e executar a promoção de forma redundante. Em vez disso, especifique esses destinos adicionais para a mesma ramificação do inventário e, em seguida, utilize-os como tags Git.

Nessa configuração, o ramo de produção tem várias tags latest no mesmo ramo, como us-south_prod_latest e eu-de_prod_latest, e cada pipeline de implantação contínua responsável por cada região pode usar essas tags para implantar.

Cenário de exemplo

Um conjunto de mudanças que eventualmente serão implementadas em todos os lugares, pode ser liberado primeiro para uma região específica. Em seguida, você pode implementar gradualmente esse conjunto de alterações em outras regiões usando pipelines de implementação contínua direcionados a essas regiões.