Avaliação da prontidão pré-implantação

Antes da criação de uma solicitação de mudança, o pipeline calcula a prontidão da implantação e define o sinalizador DEPLOYMENT_READY como true ou false. Esse sinalizador é derivado das evidências coletadas nos estágios CI e CD. Se alguma verificação de evidência indicar um desvio, uma verificação, varredura ou teste ausente ou malsucedido relacionado ao conjunto de artefatos implantado, DEPLOYMENT_READY será definido como false.

A solicitação de alteração é preparada com os seguintes campos provenientes do último PR de promoção mesclado com a ramificação de destino:

• risk
• impact
• priority
• assignee
• description
• purpose
• customer impact
• deployment impact
• backout plan

Criação de solicitação de mudança

A solicitação de modificação preparada é enviada em um dos dois estados iniciais, dependendo de DEPLOYMENT_READY:

O sistema de gerenciamento de mudanças também aprova automaticamente as solicitações de mudança quando a implementação não causa nenhum tempo de inatividade (a duração da interrupção é zero) e DEPLOYMENT_READY é true, e o risco de implantação está dentro de limites aceitáveis.

Caso as mudanças exijam um tempo de inatividade planejado, deve-se criar manualmente uma solicitação de mudança e enviá-la para aprovação. Após a aprovação, é possível iniciar a implementação, fornecendo o ID da solicitação de mudança. O pipeline verifica seu estado de aprovação e, em seguida, executa a implantação. Para obter mais informações, consulte Manualmente aprovando solicitações de mudança.

Anexos de pré-implantação

Imediatamente após a criação da solicitação de mudança, o pipeline anexa os seguintes artefatos ao registro CR:

• Lista técnica de implantação- lista todos os componentes incluídos na implantação
• Resumo Delta- postura de evidência de todos os componentes que participam da implantação
• Arquivo de configuração de verificações de evidências - anexado somente se o bloqueio baseado em verificações de evidências necessário estiver configurado no pipeline
• Perfil SCC- anexado somente se uma Configuração de Segurança e Conformidade estiver configurada

Portão de aprovação

Se a solicitação de alteração tiver sido criada como Não aprovada, ela será colocada em um estado não aprovado e enviada para revisão humana. Nenhuma implantação ocorre até que a aprovação seja concedida.

Você pode verificar o ID da solicitação de alteração criada nos registros do pipeline, aguardar a aprovação e, em seguida, reiniciar a implantação usando o mesmo ID da solicitação de alteração. O pipeline verifica o estado de aprovação e continua a implementação.

Testes de implantação e aceitação

Com o CR no estado Implement, o pipeline é executado:

• Implementação de CD- promove o código para o ambiente de destino
• Testes de aceitação- validam o resultado da implementação

Esses dois são estágios de execução orientados pelo usuário.

Encerramento do CR pós-implantação

Quando os testes de implantação e aceitação são aprovados, o pipeline anexa os artefatos de fechamento e encerra a solicitação de alteração:

• Resumo de encerramento- um resumo das evidências de todos os registros de inventário no nível de compromisso de destino.
• SBOM mesclado- a lista de materiais do software pós-implantação em todos os componentes do inventário.

O CR é então fechado com um close_category com base em DEPLOYMENT_READY no momento do fechamento:

Tipos de mudança

A Gestão de Solicitações de Mudança oferece suporte a dois tipos de mudança: de emergência ou regular.

Se a alteração atual for uma alteração de emergência, adicione a etiqueta “ emergency ” ao pull request da promoção.

Não há fluxo de emergência no lado do oleoduto da CI. No entanto, a configuração da propriedade CI pipeline/trigger skip-inventory-update-on-failure como um valor vazio ou 0 permite que o repositório de inventário seja atualizado mesmo que os problemas sejam detectados na execução do pipeline de CI. Com esse inventário atualizado, uma mudança de emergência pode ser ativada.

Escolha de um caminho de recuperação

Caminho 1: reversão completa usando o ouvinte de reversão dedicado

Se houver uma configuração de último estado conhecido, ou seja, um estado implantado anteriormente que seja confirmado como estável, o caminho mais rápido para a restauração do serviço é uma reversão total. Isso usa um ouvinte de reversão dedicado, criado especificamente para esse cenário e que não exige uma nova compilação ou promoção.

Para obter instruções passo a passo e os parâmetros a serem configurados, consulte Reversão total usando o ouvinte de reversão dedicado.

Caminho 2: Fix-forward como uma mudança emergencial

Se não houver um alvo de reversão viável ou se a investigação já tiver produzido um patch, a correção poderá ser implementada como uma alteração de emergência. Esse caminho faz um curto-circuito na lógica padrão de bloqueio de evidências: o pipeline permite que a alteração seja implementada imediatamente, e a solicitação de alteração está sujeita a revisão e aprovação retroativas após a resolução do incidente.

Usar esse caminho significa aceitar que o código implantado na produção ainda pode conter vulnerabilidades não resolvidas ou lacunas de evidências abertas. A restauração do serviço é tratada como a prioridade mais alta, e os itens de conformidade pendentes devem ser tratados após o encerramento do incidente.

Esses dois caminhos não são mutuamente exclusivos. Na prática, as equipes podem iniciar uma reversão total primeiro para restaurar o serviço imediatamente e, em seguida, fazer uma correção quando o patch estiver pronto e validado. O sequenciamento é deixado a critério do operador com base na situação em questão.

Procedimento de fixação prévia

Para implementar uma correção como uma alteração de emergência durante uma CIE, siga estas etapas:

1. Reconstrua o componente afetado. Execute o pipeline de CI para criar uma nova versão do artefato contendo a correção. Se as verificações de evidências de IC estiverem falhando devido a condições de incidentes, defina o pipeline ou a propriedade de acionamento skip-inventory-update-on-failure como um valor vazio ou 0 para permitir que o inventário seja atualizado apesar das falhas, de modo que a alteração de emergência possa prosseguir.

2. Promover a correção por meio de ambientes. Crie solicitações pull de promoção a partir do ambiente mais baixo e promova o aumento em direção à produção. Se o tempo permitir, verifique a correção em cada estágio antes de prosseguir com a promoção. Se a situação for crítica, promova diretamente a produção e reconcilie os ambientes inferiores depois que o serviço for restaurado.

3. Aplique a etiqueta de emergência. No pull request de promoção direcionado à produção, adicione o rótulo emergency. Isso sinaliza para o pipeline que o bloqueio de evidência padrão deve ser ignorado e a alteração deve ser tratada como uma implementação de emergência.

4. Implementar na produção. Execute o pipeline do CD. O pipeline detecta o rótulo de emergência, ignora a espera pela aprovação e prossegue imediatamente para os testes de implantação e aceitação. A solicitação de mudança é criada e fechada com close_category = successful with issues, refletindo que a mudança foi implementada em condições de emergência.

5. Reconciliar ambientes inferiores. Depois que o incidente de produção for resolvido, implemente o mesmo artefato de correção de emergência em ambientes inferiores - preparação, pré-produção e assim por diante - para que todos os ambientes estejam em um estado consistente com a produção. Se os ambientes inferiores foram verificados antes da promoção para produção, confirme se a mesma versão do artefato está em vigor em todas as camadas.

Obrigações pós-CIE

Uma implementação de emergência incorre em obrigações de conformidade que devem ser tratadas após o encerramento do incidente:

• A solicitação de alteração deve ser revisada retroativamente e aprovada pelos aprovadores apropriados.
• Todas as lacunas de evidências aceitas durante a emergência - vulnerabilidades não resolvidas, varreduras incompletas ou verificações com falha - devem ser corrigidas e o pipeline deve ser executado novamente em condições padrão.
• Uma análise de causa raiz (RCA) deve ser conduzida e documentada.

O registro da solicitação de mudança, incluindo o Delta Summary, o Closing Summary e o Merged SBOM anexado pelo pipeline, serve como a principal trilha de auditoria para a revisão pós-CIE.

Invocação do fluxo de emergência

O fluxo de emergência é iniciado pelo usuário:

1. O usuário executa o pipeline com o rótulo emergency aplicado ao pull request de promoção.
2. O pipeline detecta a designação de emergência e os testes de implantação e aceitação prosseguem imediatamente, sem esperar pela aprovação padrão.
3. O CR é encerrado com as notas finais conforme successful with issues.

Se a alteração atual for uma alteração de emergência, adicione a etiqueta " emergency " ao pull request de promoção antes de executar o pipeline.

Implantação pós-emergência

Depois que o fluxo de emergência conclui a implementação e os testes, ele se junta novamente ao fluxo padrão no estágio pós-implementação:

• O Resumo de Encerramento e o SBOM Mesclado estão anexados ao CR.
• O CR é fechado seguindo a mesma lógica DEPLOYMENT_READY baseada em close_category do fluxo padrão.

Se o tipo de CR for emergency, a solicitação de alteração deverá ser revisada e aprovada retroativamente após a implementação.

Condição de acionamento

O fluxo de reversão em linha é inserido quando a implantação ou os testes de aceitação não são aprovados. Em seguida, o pipeline avalia se o inline-rollback está ativado:

• Inline-Rollback não ativado: O CR é deixado aberto com close_category = unsuccessful e o pipeline é encerrado. Não há tentativa de recuperação automática.
• Reversão ativada: O script de reversão é executado para reverter o ambiente de destino, e os artefatos de reversão são reunidos e anexados ao CR.

Execução de reversão em linha

Quando a reversão em linha está ativada, o pipeline:

1. Executa o script de reversão em linha se a implantação ou o teste de aceitação falhar no pipeline de CD.
2. Coleta os seguintes artefatos:
   • Logs de reversão- saída da execução do script de reversão
   • Resumo de fechamento- reflete o resultado da reversão
   • SBOM mesclado- lista de materiais do software pós-rollback
3. Anexa todos os três artefatos ao registro CR aberto.

Encerramento do CR após a reversão

Após a reversão em linha e a anexação do artefato, o CR é deixado aberto com close_category = unsuccessful. Isso indica ao gerenciamento de mudanças que a implementação foi tentada, falhou e foi revertida automaticamente.

Um CR com close_category = unsuccessful é o resultado esperado e correto quando uma implantação é revertida, e não uma indicação de falha no processo. As equipes de operações devem usar os logs de reversão anexados para investigar a causa raiz.

Executar o pipeline com uma solicitação de alteração pré-aprovada

Você pode usar uma solicitação de mudança (CR) pré-aprovada para a implementação. Dois cenários são possíveis:

Quando o pipeline de CD reconhece que o CR foi criado por uma execução anterior do pipeline de CD, ele acelera o caminho da implantação:

• Reutilizando o delta pré-calculado e o resumo das evidências da evidência CR.
• Ignorando as etapas de revisão por pares e verificação de assinatura.
• Implantando o delta pré-calculado.

Quando o pipeline de CD não consegue determinar se o CR foi criado por uma execução anterior do pipeline de CD ou o CR fornecido não corresponde ao destino de implantação da execução atual:

• Não reutiliza nenhum delta pré-calculado ou resumos de evidências.
• Ele não ignora a revisão por pares nem a verificação da assinatura do artefato.
• Ele recalcula o delta e o resumo do zero.
• Ele não cria um novo CR, pois um já foi fornecido.

Reexecutar o pipeline em uma implantação com falha

Se você não quiser utilizar o gerenciamento automatizado de mudanças, pode apresentar, em vez disso, uma solicitação de mudança previamente criada e aprovada. A Rerun falhou implementações nos seguintes cenários:

• A última solicitação de alteração criada automaticamente não está pronta para implantação e não foi aprovada automaticamente. Você recebeu a aprovação e deve reiniciar a implementação usando a mesma solicitação de alteração.
• A implementação exige tempo de inatividade. Você criou a solicitação de mudança, ela foi aprovada e você seguiu a Política de Gerenciamento de Mudanças da sua organização.
• Não houve alteração em nenhum código ou configuração. Você criou a solicitação de mudança, explicou o que mudou, recebeu aprovação e iniciou uma implementação usando a solicitação de mudança aprovada.

A solicitação de alteração (CR) permanece aberta após a conclusão do pipeline de CD.

Você pode iniciar o pipeline de implantação contínua de referência do DevSecOps utilizando uma solicitação de alteração pré-aprovada e inserindo o ID da solicitação de alteração na propriedade change-request-id.

Se a propriedade change-request-id estiver definida, o pipeline ignora a coleta de dados para a solicitação de alteração e passa diretamente para a verificação do status de aprovação. Se o parâmetro **change-request-id** estiver definido como notAvailable por padrão, uma solicitação de alteração será criada automaticamente pelo pipeline.