Orbit
Reverter uma Implementação
If a deployment breaks production, you can put an earlier build back in front of traffic in seconds without rebuilding anything. This guide covers how rollback works, how to pick the right…
Se uma implementação prejudicar a produção, pode colocar uma construção anterior em frente do tráfego em segundos sem reconstruir nada. Este guia aborda como funciona a reversão, como escolher a implementação correta, as reversões automáticas que o Orbit pode executar para si e o que fazer depois de ter revertido.
Como Funciona a Reversão
O Orbit mantém o artefato empacotado de cada construção bem-sucedida. Uma reversão não executa novamente o seu instalação ou o seu comando de construção: promove um artefato que já existe e já foi entregue, pelo que é concluída em segundos e não pode falhar por nenhuma das razões pelas quais uma construção pode falhar.
É exatamente por isso que se deve recorrer a ela primeiro. Reverter é mais rápido e muito mais previsível do que tentar corrigir para a frente enquanto o seu site está quebrado.
Reverter Para uma Implementação Anterior
- Abra o seu projeto em Orbit.
- Abra o separador Deployments.
- Encontre a última implementação que sabe que estava correta.
- Clique em Roll back nessa linha e confirme.
A confirmação diz exatamente o que vai acontecer: o tráfego será entregue da construção mais antiga imediatamente, e a implementação atual será substituída.
Também pode reverter a partir da página de detalhe da própria implementação, onde o botão diz Rollback to o hash curto do commit.
A implementação restaurada recebe o distintivo CURRENT. A implementação de que se afastou permanece no histórico com o estado Rolled back.
A reversão não é destrutiva e não precisa de ser desfeita. Nada é eliminado, nenhum histórico é reescrito e o seu repositório não é afetado. O seu próximo push bem-sucedido para o ramo de produção simplesmente se torna a nova versão em direto da forma habitual.
Identificar a Implementação Correta
Cada linha no separador Deployments mostra a mensagem de commit e hash curto, o ramo, o estado, quando foi implementado e quem o fez push. A que está em direto tem o distintivo CURRENT.
Normalmente quer a implementação imediatamente anterior à que causou o problema. Duas coisas ajudam a ter a certeza:
- Compare. Abra a implementação suspeita e clique em Compare para fazer uma comparação contra a anterior: tempo de construção, tamanho do artefato, estado da cache, framework e a diferença do artefato ao nível dos ficheiros.
- Deployment notes. Qualquer implementação pode ter uma nota de até 500 caracteres. Adicionar "hotfix for payment bug" ou "feature flag X on" no momento não custa nada e torna o histórico legível meses depois, que é exatamente quando o precisa.
Reverter para um artefato não reverte as suas variáveis de ambiente, regras de redirecionamento ou cabeçalhos de resposta. Esses são lidos no momento do pedido ou da construção, não embutidos no artefato. Se o incidente foi causado por uma mudança de configuração em vez de uma mudança de código, reverter o código não vai corrigi-lo. A página de detalhe da implementação faz uma comparação das variáveis que foram injetadas no momento da construção contra a sua configuração atual, que é a forma mais rápida de distinguir os dois casos.
Reversão Automática
O Orbit pode fazer isto por si antes de ter sequer notado. Todas as três definições estão em Settings.
Auto-Rollback On Failure
Em Runtime, ative Auto-rollback on failure. Se um deploy de produção falhar, a última implementação saudável é restaurada automaticamente e os visitantes não veem qualquer tempo de inatividade. O Staging tem um botão de alternância equivalente próprio.
Health Check
Em Health check, defina um Health check path, por exemplo / ou /api/health. Depois de cada deploy de produção, o Orbit obtém esse caminho. Se não devolver uma resposta 2xx dentro de 15 segundos, a implementação saudável anterior é restaurada.
Smoke Tests
Em Smoke tests, liste até 10 caminhos separados por vírgulas, por exemplo /,/blog,/api/health. Depois de cada deploy bem-sucedido, o Orbit envia um GET para cada um e regista sucesso ou falha. Se algum falhar e a reversão automática estiver ativada, a implementação anterior é restaurada. O resultado aparece na página de implementação como Smoke tests passed ou uma contagem de falhas, e diz Triggered rollback quando causou um.
Uma verificação de saúde numa rota que realmente exercita a sua base de dados vale muito mais do que uma na página inicial. Uma implementação quebrada que ainda serve uma página inicial em cache passará uma verificação / e falhará uma real.
Reversão Versus Deploy Lock
Se não está pronto para reverter mas quer impedir que algo novo vá para o ar enquanto investiga, bloqueie as implementações:
- Abra o projeto.
- Clique em Lock deploys.
- Adicione uma razão, por exemplo "investigating production issue".
As implementações acionadas por push são então silenciosamente ignoradas, e um banner diz Production deploys are locked com a sua razão. As implementações manuais ainda funcionam, o que é intencional: o bloqueio impede implementações acidentais, não a correcção que está a enviar. Clique em Unlock deploys para o remover.
Um bloqueio e uma reversão funcionam bem em conjunto. Reverta primeiro para restaurar o serviço, depois bloqueie para que nenhuma fusão de rotina de ninguém desfaça isso enquanto está a diagnosticar.
Promover Staging Para Produção
Se executar um ambiente de staging, pode colocar uma construção de staging testada em produção sem fazer push de nada.
- Abra a visão geral do projeto e encontre a secção Staging.
- Se o staging está à frente da produção, aparece Promote to production.
- Clique nele e confirme.
Leia a confirmação com cuidado, porque existem dois comportamentos de promoção diferentes no Orbit e não são intercambiáveis. Promover a partir da visão geral do projeto aciona uma fresh production build at the same commit, utilizando variáveis de ambiente de produção e comandos de construção de produção. O artefato de staging não é reutilizado. Promover uma implementação de staging específica a partir da sua página de detalhe indica claramente que a construção de staging vai para o ar imediatamente sem uma reconstrução. Se as suas variáveis de ambiente de staging e produção forem diferentes, o primeiro caminho produzirá um artefato diferente do que testou.
O Orbit também pode fazer a promoção por si. Auto-promote staging em Settings promove staging para produção após várias horas de staging saudável com smoke tests a passar, verificado a cada 15 minutos.
Depois de uma Reversão
Corrija o problema subjacente no seu repositório e faça push de um novo commit. Isso aciona uma construção normal que se torna a nova versão em direto. Se bloqueou implementações, desbloqueie-as primeiro, ou o push será ignorado.
O separador Activity do projeto regista a reversão juntamente com tudo o resto que aconteceu, portanto existe um registo de auditoria de quem reverteu o quê e quando.
O Que Limita O Quão Longe Pode Voltar
A reversão precisa que o artefato ainda exista. Duas definições controlam isso:
- A janela de histórico de implementação do seu plano: 7 dias em Launch, 30 em Liftoff, 90 em Apex.
- A definição Artifact retention do projeto, que mantém um número de artefatos bem-sucedidos por ambiente, de 10 a 500, tendo como padrão 50.
O artefato da implementação atualmente em direto é sempre mantido independentemente de qualquer uma das duas.
Se implementar muitas vezes por dia, a contagem de artefatos é o limite que atingirá primeiro, não a contagem de dias. Cinquenta implementações podem ser uma única semana. Aumente Artifact retention em vez de descobrir o limite durante um incidente.