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á.

Reimplante e reverta uma implantação com CodeDeploy

CodeDeploy reverte as implantações reimplantando uma revisão implantada anteriormente de um aplicativo como uma nova implantação. Essas implantações revertidas são tecnicamente novas implantações, com novos ID de implantação, e não versões restauradas de uma implantação anterior.

Implantações podem ser revertidas automaticamente ou manualmente.

Reversões automáticas

Você pode configurar um grupo de implantação ou uma implantação para reversão automática quando uma implantação falhar ou quando um limite de monitoramento especificado for atendido. Nesse caso, a última versão conhecida em bom estado de uma revisão de aplicativo é implantada. Reversões automáticas são configuradas quando um aplicativo é criado ou quando um grupo de implantação é criado ou atualizado.

Ao criar uma nova implantação, você também pode optar por substituir a configuração de reversão automática que foi especificada para o grupo de implantação.

Para obter mais informações sobre como configurar reversões automáticas, consulte Configurar opções avançadas para um grupo de implantação.

Reversões manuais

Se você não tiver configurado reversões automáticas, poderá reverter manualmente uma implantação criando uma nova implantação que usa qualquer revisão de aplicativo implantada anteriormente e seguindo as etapas para reimplementar uma revisão. Isso pode ser feito quando um aplicativo entra em um estado desconhecido. Em vez de gastar muito tempo com a solução de problemas, você pode reimplantar o aplicativo para um bom estado de operação conhecido. Para ter mais informações, consulte Crie uma implantação com CodeDeploy.

Fluxo de trabalho de reversão e reimplantação

Quando a reversão automática é iniciada, ou quando você inicia manualmente uma reimplantação ou reversão manual, CodeDeploy primeiro tenta remover de cada instância participante todos os arquivos que foram instalados com sucesso pela última vez. CodeDeploy faz isso verificando o arquivo de limpeza:

/opt/codedeploy-agent/deployment-root/deployment-instructions/deployment-group-ID-cleanuparquivo (para instâncias Amazon Linux, etc.)

C:\ProgramData\Amazon\CodeDeploy\deployment-instructions\deployment-group-ID-cleanuparquivo (para instâncias do Windows Server)

Se ele existir, CodeDeploy usa o arquivo de limpeza para remover da instância todos os arquivos listados antes de iniciar a nova implantação.

Por exemplo, os dois primeiros arquivos de texto e os dois arquivos de script já foram implantados em uma instância do Amazon EC2 que executa o Windows Server, e os scripts criaram mais dois arquivos de texto durante os eventos de ciclo de vida de implantação:

c:\temp\a.txt (previously deployed by CodeDeploy)
c:\temp\b.txt (previously deployed by CodeDeploy)
c:\temp\c.bat (previously deployed by CodeDeploy)
c:\temp\d.bat (previously deployed by CodeDeploy)
c:\temp\e.txt (previously created by c.bat)
c:\temp\f.txt (previously created by d.bat)

O arquivo de limpeza listará apenas os dois primeiros arquivos de texto e dois arquivos de script:

c:\temp\a.txt
c:\temp\b.txt 
c:\temp\c.bat 
c:\temp\d.bat 

Antes da nova implantação, CodeDeploy removerá somente os dois primeiros arquivos de texto e os dois arquivos de script, deixando os dois últimos arquivos de texto intocados:

c:\temp\a.txt will be removed
c:\temp\b.txt will be removed
c:\temp\c.bat will be removed
c:\temp\d.bat will be removed
c:\temp\e.txt will remain
c:\temp\f.txt will remain

Como parte desse processo, não CodeDeploy tentará reverter ou reconciliar nenhuma ação realizada por nenhum script em implantações anteriores durante reimplantações subsequentes, sejam reversões manuais ou automáticas. Por exemplo, se os d.bat arquivos c.bat e contiverem lógica para não recriar os f.txt arquivos e.txt e se eles já existirem, as versões antigas de e.txt e f.txt permanecerão inalteradas sempre que forem CodeDeploy executadas c.bat e d.bat em implantações subsequentes. Você pode adicionar lógica a c.bat e d.bat para sempre verificar e excluir versões antigas de e.txt e f.txt antes de criar novas.

Comportamento de reversão com conteúdo existente

Como parte do processo de implantação, o CodeDeploy agente remove de cada instância todos os arquivos instalados pela implantação mais recente. Se os arquivos que não faziam parte de uma implantação anterior aparecerem nos locais de implantação de destino, você poderá escolher o CodeDeploy que fazer com eles durante a próxima implantação:

É possível escolher esse comportamento ao criar uma implantação. Criar uma configuração de implantação no console, consulte Criar uma implantação de EC2 /On-Premises Compute Platform (console). Se estiver criando uma implantação com o AWS CLI, consulteCriar uma implantação de EC2 /On-Premises Compute Platform () CLI.

Você pode optar por manter os arquivos que deseja que façam parte da próxima implantação sem precisar adicioná-los ao pacote de revisão de aplicativo. Por exemplo, você pode carregar diretamente na instância os arquivos que são necessários para a implantação, mas que não foram adicionados ao pacote de revisão de aplicativo. Ou você pode fazer upload de arquivos para a instância se seus aplicativos já estiverem em seu ambiente de produção, mas você quiser CodeDeploy usá-los pela primeira vez para implantá-los.

No caso de reversões em que a mais recente revisão de aplicativo implantada com êxito for reimplantada devido a uma falha de implantação, a opção de tratamento de conteúdo para essa última implementação bem-sucedida será aplicada à implantação de reversão.

No entanto, se a implantação que falhou tiver sido configurada para substituir arquivos, em vez de mantê-los, um resultado inesperado poderá ocorrer durante a reversão. Especificamente, os arquivos que você esperava que fossem mantidos talvez sejam removidos pela implantação com falha. Os arquivos não estão na instância quando a implantação de reversão é executada.

No exemplo a seguir, existem três implementações. Nenhum arquivo substituído (excluído) durante a segunda implementação com falha estará mais disponível (não pode ser mantido) quando a revisão de aplicativo 1 for implantada novamente durante a implantação 3: