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

Reimplantar e reverter uma implantação com o CodeDeploy

O CodeDeploy reverte as implantações redistribuindo uma revisão previamente implantada 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 obter 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, o CodeDeploy primeiro tenta remover de cada instância participante todos os arquivos que foram instalados com êxito da última vez. O 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 o arquivo de limpeza existir, o CodeDeploy vai usá-lo 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, o CodeDeploy removerá apenas os dois primeiros arquivos de texto e os dois arquivos de script, deixando intactos os dois últimos arquivos de texto:

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, o CodeDeploy não tentará reverter ou reconciliar ações realizadas por qualquer script em implantações anteriores durante reimplantações subsequentes, sejam reversões manuais ou automáticas. Por exemplo, se os arquivos c.bat e d.bat contiverem lógica para não recriar os arquivos e.txt e f.txt caso estes já existam, as versões antigas de e.txt e de f.txt permanecerão inalteradas sempre que o CodeDeploy executar c.bat e d.bat nas 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 agente do CodeDeploy remove de cada instância todos os arquivos instalados pela implantação mais recente. Se arquivos que não faziam parte de uma implantação anterior aparecerem em localizações de implantação de destino, você poderá escolher o que o CodeDeploy deve 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 oAWS CLI, consulteCrie uma implantação 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. Outra opção é carregar arquivos na instância caso os seus aplicativos já estejam no seu ambiente de produção, mas você queira usar o CodeDeploy 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: