O que é deploy? Do código ao ambiente de produção
Entenda o que é deploy, como uma versão chega a um ambiente executável e por que build, release, healthcheck e rollback são etapas diferentes.
Quando alguém diz “fiz o deploy”, pode estar descrevendo coisas bem diferentes: copiar arquivos para um servidor, atualizar uma imagem de container, aplicar uma nova versão em um cluster, publicar uma função serverless ou promover um artefato para produção.
O detalhe técnico muda, mas a ideia central é a mesma: deploy é o processo de colocar uma versão de software em um ambiente onde ela pode ser executada.
Essa definição parece simples, mas ela ajuda a separar vários termos que costumam ser usados como sinônimos.
O caminho entre código e software executando
Um fluxo básico pode ser representado assim:
commit
↓
build
↓
testes
↓
artefato
↓
deploy
↓
healthcheck
↓
tráfego
Cada etapa responde uma pergunta diferente.
O build transforma código e dependências em algo executável ou distribuível. Pode produzir um binário, pacote, imagem de container, bundle ou outro artefato.
O artefato é a versão identificável que será promovida entre ambientes. Idealmente, você sabe exatamente qual commit, dependências e processo geraram aquele artefato.
O deploy coloca esse artefato em um ambiente e aplica as mudanças necessárias para que ele possa executar ali.
A verificação pós-deploy tenta responder se a versão realmente ficou disponível e funcional.
Só depois disso faz sentido pensar em expor tráfego, ampliar rollout ou declarar a mudança pronta.
Build não é deploy
Essa é uma das confusões mais comuns.
Se você executa npm run build, compila um binário Go, gera um .jar ou constrói uma imagem Docker, você criou um artefato. Esse artefato ainda pode estar apenas no seu computador ou em um registry.
O deploy começa quando essa versão é aplicada a um ambiente de execução.
Por isso, um pipeline pode ter build verde e ainda falhar no deploy por motivos como:
- credencial inválida;
- configuração ausente;
- migração incompatível;
- indisponibilidade do ambiente;
- permissão insuficiente;
- imagem inexistente no registry esperado;
- porta ou dependência configurada incorretamente.
Separar build e deploy melhora diagnóstico. Se você sabe em qual fronteira a falha aconteceu, reduz o espaço de investigação.
Deploy também não é release
Outro termo frequentemente misturado é release.
Deploy trata de colocar uma versão em um ambiente. Release trata de disponibilizar uma mudança para o usuário ou para o público-alvo.
Em muitos sistemas simples, os dois eventos acontecem quase ao mesmo tempo. Você sobe a nova versão e todos os usuários passam a recebê-la.
Mas eles não precisam ser acoplados.
Uma aplicação pode receber o deploy de uma funcionalidade desativada por feature flag. A versão está em produção, mas a funcionalidade ainda não foi liberada. Em outro cenário, uma nova versão pode ser implantada para uma pequena parcela dos usuários antes de uma liberação mais ampla.
Essa separação permite controlar risco. Você pode validar infraestrutura e comportamento antes de expor completamente a mudança.
Deploy não é apenas copiar código
Em sistemas antigos, deploy podia significar literalmente copiar arquivos para um servidor. Esse modelo ainda existe em alguns contextos, mas a ideia moderna é mais ampla.
Um deploy pode envolver:
- selecionar um artefato versionado;
- aplicar variáveis e configuração do ambiente;
- provisionar ou atualizar infraestrutura;
- executar migrações de banco;
- atualizar serviços ou containers;
- registrar a nova revisão;
- verificar readiness e healthchecks;
- controlar quando a nova versão recebe tráfego;
- registrar evidências para auditoria e rollback.
O importante é que o processo seja reproduzível e rastreável.
Se o deploy depende de alguém lembrar uma sequência de comandos que não está documentada ou automatizada, o sistema funciona enquanto aquela pessoa e aquele contexto continuam disponíveis. Isso é risco operacional.
Ambiente, configuração e artefato são partes diferentes
Uma boa prática conceitual é evitar construir um artefato diferente para cada ambiente quando não há necessidade.
A mesma versão pode ser promovida de teste para staging e produção enquanto configuração e segredos são fornecidos pelo ambiente.
Isso melhora a rastreabilidade porque você consegue dizer:
“o artefato que testamos é o mesmo que promovemos”.
A configuração, porém, precisa ser tratada com o mesmo cuidado. Uma versão correta com configuração errada continua sendo um deploy ruim.
Por isso, variáveis, endpoints, permissões, chaves, conexões e limites de recurso fazem parte da preparação do ambiente, mesmo quando não estão dentro do código-fonte.
Deploy concluído não significa sistema saudável
Um comando pode terminar com exit code zero e ainda deixar a aplicação em situação ruim.
Talvez o processo tenha iniciado, mas não consiga conectar ao banco. Talvez a nova versão responda HTTP 200 em uma rota simples, mas esteja falhando nas operações críticas. Talvez a aplicação esteja saudável, porém uma migração tenha aumentado a latência além do aceitável.
Por isso, o deploy precisa de verificação posterior.
Healthchecks ajudam a responder perguntas específicas como:
- o processo está vivo?
- a aplicação está pronta para receber tráfego?
- uma dependência essencial está acessível?
Mas healthcheck também não substitui observabilidade. Ele é um sinal estreito. Logs, métricas, traces e indicadores de negócio podem revelar problemas que um endpoint de readiness não enxerga.
Em outras palavras:
deploy terminou
≠
rollout ficou disponível
≠
sistema está saudável
≠
usuário está tendo boa experiência
Quanto mais importante o sistema, mais explícitas precisam ser essas fronteiras.
Rollback não deve ser improviso
Se uma nova versão causa problema, a pergunta inevitável é: como voltar?
Rollback é a capacidade de retornar a uma versão ou estado conhecido como estável. Em plataformas como Kubernetes, por exemplo, o histórico de revisões pode permitir voltar a uma revisão anterior de um Deployment.
Mas rollback real pode ser mais difícil do que trocar uma imagem.
Mudanças de banco de dados, filas, contratos de API e efeitos externos podem não ser reversíveis automaticamente. Por isso, uma estratégia madura pensa em compatibilidade antes da implantação.
Uma migração destrutiva que remove uma coluna utilizada pela versão anterior pode tornar o rollback do código insuficiente. Um deploy seguro precisa considerar esses acoplamentos antes do incidente.
Três estratégias de deploy que você vai encontrar
Existem muitas estratégias, mas três aparecem com frequência e ajudam a construir o modelo mental.
Rolling update
A nova versão substitui a antiga gradualmente. Algumas instâncias novas entram enquanto antigas saem. O objetivo costuma ser atualizar sem interromper todo o serviço de uma vez.
Esse modelo exige atenção a compatibilidade entre versões durante a transição, porque por algum tempo versões diferentes podem coexistir.
Blue/green
Dois ambientes ou grupos equivalentes representam a versão atual e a nova. A nova versão é preparada e validada separadamente; depois o tráfego é trocado.
Isso pode tornar rollback de tráfego muito rápido, mas aumenta custo e exige disciplina para manter ambientes realmente equivalentes.
Canary
Uma nova versão recebe apenas uma pequena parte do tráfego ou um subconjunto de usuários. A equipe observa sinais antes de ampliar a exposição.
Canary não é simplesmente “subir uma instância nova”. Ele depende de medir se aquela pequena exposição está produzindo comportamento aceitável.
Nenhuma dessas estratégias é requisito universal. Um site pequeno em uma única VPS pode precisar de uma solução muito mais simples. A estratégia deve ser proporcional ao risco, custo e arquitetura do sistema.
O que continuous delivery tem a ver com deploy
Continuous delivery busca manter o software em condição de ser liberado de forma confiável e com baixo risco quando necessário.
Isso muda a forma de pensar deploy. Em vez de tratá-lo como um evento raro e tenso, a equipe trabalha para que a capacidade de implantar seja exercitada constantemente.
Isso envolve práticas como testes automatizados, integração frequente, versionamento, automação, observabilidade e redução do tamanho das mudanças.
Continuous delivery não significa necessariamente que toda mudança vai automaticamente para produção. Essa última ideia está mais próxima de continuous deployment, em que mudanças aprovadas pelo pipeline seguem automaticamente para produção conforme a política do sistema.
Onde o deploy realmente pode falhar
É útil pensar no deploy como uma sequência de fronteiras, porque cada uma tem modos de falha próprios.
Antes do ambiente receber a nova versão, o artefato precisa existir, estar íntegro e corresponder ao commit esperado. Durante a implantação, credenciais, configuração, rede, storage e permissões precisam estar coerentes. Depois que o processo inicia, a aplicação ainda precisa provar que consegue servir tráfego e cumprir sua função.
Por isso, uma esteira profissional costuma separar pelo menos três perguntas:
- conseguimos instalar ou iniciar a versão?
- a nova versão está pronta para receber tráfego?
- o comportamento depois da mudança continua aceitável?
Misturar tudo em um único “deu certo” cria falsos positivos. Um script pode terminar com sucesso enquanto a aplicação inicia em loop de erro, ou pode responder ao healthcheck e ainda degradar uma operação importante.
Como observar um deploy na prática
Mesmo sem ter um pipeline sofisticado, você pode treinar esse modelo mental olhando para qualquer aplicação que já publica.
Escolha um projeto pequeno e responda:
- qual é o artefato que representa a versão?
- em qual ambiente ele é instalado ou iniciado?
- onde ficam configuração e segredos?
- como sabemos que a aplicação iniciou?
- como sabemos que está pronta para tráfego?
- qual evidência indica que a versão está funcionando bem depois do deploy?
- como voltamos para a versão anterior?
Se você não consegue responder uma dessas perguntas, encontrou uma lacuna real do processo.
O objetivo inicial não é implantar Kubernetes, blue/green ou canary. É tornar explícitas as fronteiras que hoje podem estar escondidas em comandos manuais.
Um bom deploy é verificável
Quando o processo termina, deve existir evidência suficiente para dizer qual versão foi implantada, onde ela está executando e quais verificações passaram.
Isso pode incluir:
- SHA do commit;
- versão ou tag do artefato;
- identificador do ambiente;
- resultado do pipeline;
- resultado de healthchecks;
- logs de inicialização;
- métricas após a mudança;
- registro de quem ou qual automação executou a promoção.
Essa rastreabilidade reduz o tempo de diagnóstico quando algo dá errado. Em vez de perguntar “o que mudou?”, você começa a investigação com uma versão identificada e uma linha do tempo concreta.
O próximo passo: automatizar a esteira
Depois que você entende deploy como processo, CI/CD deixa de parecer apenas um arquivo YAML.
CI/CD é a forma de transformar várias dessas verificações em uma esteira repetível: integrar mudanças, executar testes, produzir artefatos, aplicar gates e, conforme a política do projeto, promover versões para ambientes.
A próxima pergunta da jornada é justamente essa: o que é CI/CD e como ele organiza o caminho entre commit e produção?
Antes de automatizar tudo, porém, preserve a distinção mais importante deste artigo:
build cria o artefato
deploy coloca a versão no ambiente
release expõe a mudança ao público
healthcheck prova uma capacidade específica
observabilidade mostra o comportamento mais amplo
rollback oferece uma saída controlada
Quando essas fronteiras ficam claras, ferramentas deixam de ser receitas isoladas e passam a ocupar um lugar compreensível dentro do sistema de entrega.
Uma resposta