Teste de realidade da produção
A aplicação não fez deploy. Melhor agora do que com utilizadores.
O erro de deploy é evidência. Guarde a fase e a primeira mensagem útil antes de outra alteração a substituir.
01
O que aconteceu?
O código da preview encontra filesystem limpo, runtime, comando, porta, domínio, segredos e base de dados diferentes.
02
Porque é que isto acontece
- Dependências ou lockfile não coincidem.
- O serviço ou healthcheck usa a porta ou caminho errado.
- Faltam segredos de produção ou a migração corre fora de ordem.
03
O que pode verificar
- Identifique install, build, start, healthcheck ou primeiro pedido.
- Registe versões, comandos, exit code e primeiro erro relevante.
- Construa o mesmo commit num ambiente limpo de produção.
NÃO TÉCNICO
Hosting e servidores não são o seu problema.
Uma falha de deploy é um evento técnico, mas não exige de si uma resposta técnica.
- Não precisa de aprender Docker, servidores ou linha de comandos para voltar a funcionar.
- Não continue a clicar em "deploy" à espera que corra diferente da próxima vez — uma falha inalterada não se resolve sozinha.
- Anote exatamente quando falhou e que mensagem, se alguma, apareceu.
- Decida se quer que seja alojado por si, ou ligado a hosting ou infraestrutura que já tenha.
O Shipvise pode fornecer um ambiente gerido para tudo, ou ligar-se à sua configuração existente — de qualquer forma, o deploy passa a ser problema de outra pessoa, não seu.
04
Como testar a correção em segurança
Faça a correção num branch separado, valide-a num staging próximo de produção e publique exatamente a versão aprovada. Mantenha disponível o último artefacto estável e um rollback testado.
05
Quando precisa de um programador
É preciso um programador quando os logs apontam simultaneamente para infraestrutura e código da aplicação, ou quando uma migração falhada possa ter alterado dados. O Shipvise oferece deploys em staging, verificados e explicitamente aprovados, com opções de rollback e hosting — sem infraestrutura própria, o Shipvise pode alojar por si; com infraestrutura própria, faz o deploy através dela.
FAQ
Perguntas que as pessoas realmente fazem
Porque passa localmente?
Caches, runtime, filesystem, dependências, variáveis e comandos podem diferir.
Porque funciona a pré-visualização mas não a produção?
Os ambientes de pré-visualização costumam fornecer routing, variáveis ou serviços que a produção não tem por defeito. Compare os dois ambientes componente a componente antes de mudar o código da aplicação.
Tenho de gerir hosting, domínios e servidores sozinho?
Não. O Shipvise pode fornecer um ambiente gerido e tratar do domínio e da configuração do runtime, ou ligar-se ao hosting e infraestrutura que já tem.
Devo repetir o deploy?
Só perante uma falha transitória confirmada; configuração determinística não melhora com repetição.
O que é preciso para um rollback seguro?
Um artefacto anterior que funcionava, alterações de base de dados retrocompatíveis (ou nenhuma) e uma forma conhecida de reverter o tráfego ou a versão em execução sem adivinhar.
Preciso de aprender Docker para fazer deploy de uma aplicação criada por IA?
Não. O Docker é só uma forma de empacotar uma aplicação para correr de forma consistente entre ambientes. Se não tem a sua própria infraestrutura, o Shipvise pode correr a aplicação num ambiente gerido por si; se já tem, pode fazer o deploy através do que já usa.
O que significa realmente um deploy falhado?
Significa que a aplicação nunca chegou a um estado em que pudesse servir tráfego real — a falha aconteceu durante a instalação, o build, o arranque ou uma verificação de saúde, antes de qualquer utilizador a ver. É uma falha mais segura do que uma que chega à produção e avaria em direto.