Blog / Do zero ao ar: DNS, versionamento e deploy — as etapas que todo projeto precisa seguir
Do zero ao ar: DNS, versionamento e deploy — as etapas que todo projeto precisa seguir
Por Marcos Henrique Corrêa · tecnologia ·
Introdução
Colocar um projeto no ar costuma ser tratado como um único passo: "fazer o deploy". Na prática, é uma sequência de etapas, cada uma com um papel diferente. Quem não enxerga essa sequência tende a misturar as coisas — achar que comprar o domínio já hospeda o site, publicar mudanças sem histórico, testar direto nos dados reais.
O resultado aparece depois: site fora do ar, dados expostos ou um projeto preso a um único fornecedor.
Objetivo
Mostrar, de forma prática, o caminho completo entre comprar um domínio e ter um projeto funcionando em produção, explicando por que cada etapa existe, como foi feita e onde ela acontece. O caso usado como exemplo é o próprio blog marck0101.
Hipótese
Separar o processo em cinco etapas independentes — nome, endereço, código, dados e publicação — e resolver cada uma antes da próxima torna o projeto mais seguro, mais fácil de manter e menos dependente de qualquer fornecedor. E esse processo é mais simples do que parece.
Metodologia: as 5 etapas
1. Domínio
Por quê: comprar um domínio só reserva o nome — "marck0101.com.br" — em nome de um dono registrado. Pra onde esse nome aponta é outra decisão, separada. Essa é a confusão mais comum de quem está começando.
Como: o domínio foi registrado num registrador, sem contratar hospedagem junto.
Onde: no registrador de domínios.
O que importa: o domínio é um ativo do negócio: registre no nome da empresa ou do responsável, nunca de terceiros. E você não precisa hospedar o site onde comprou o domínio.
2. DNS
Por quê: o DNS é o sistema que traduz o nome do site no endereço real do servidor. É ele que liga o domínio à hospedagem.
Como: no painel do registrador, o DNS foi configurado pra apontar pra Vercel, uma plataforma diferente de onde o domínio foi comprado. Na prática, a regra é: "quando alguém acessar esse domínio, mande pra estes servidores".
Onde: painel do registrador, apontando pra Vercel.
O que importa: trocar de hospedagem vira uma mudança de configuração, não uma migração do domínio. A propagação leva de minutos a algumas horas; nesse intervalo o domínio não resolve, e isso é normal — não refaça a configuração, espere.
3. Versionamento
Por quê: sem histórico, não dá pra saber o que mudou em produção, nem voltar atrás com segurança.
Como: foram criados dois repositórios com Git — um pro backend, um pro frontend —, cada um com seu próprio histórico. A cada mudança enviada pra branch principal, a Vercel (conectada ao GitHub) gera uma nova versão e publica sozinha, sem passo manual.
Onde: GitHub, integrado à Vercel.
O que importa: toda mudança em produção tem rastro. Desfazer um erro é voltar uma versão, não resgatar um backup. E publicar deixa de depender de alguém fazendo upload manual.
4. Banco de dados
Por quê: testar direto nos dados reais é o jeito mais rápido de perder ou expor informação do negócio.
Como: o banco escolhido foi o MongoDB, em dois ambientes separados: uma cópia local pra desenvolvimento, onde dá pra quebrar, testar e recomeçar, e um banco na nuvem pra produção. O sistema escolhe automaticamente qual usar dependendo de onde está rodando.
Onde: MongoDB local (desenvolvimento) e MongoDB Atlas (produção).
O que importa: teste nunca encosta nos dados reais. O endereço de conexão fica em variáveis de ambiente, fora do código, e nunca vai pro GitHub.
5. Deploy
Por quê: site e API têm papéis diferentes. Misturar os dois dificulta manutenção e monitoramento.
Como: a Vercel hospeda os dois projetos, cada um no seu subdomínio: o frontend em blog.marck0101.com.br e a API em api.blog.marck0101.com.br.
Onde: Vercel.
O que importa: fica claro — pro time e pras ferramentas de monitoramento — o que é site e o que é API. Cada parte pode ser atualizada de forma independente.
Resultados
Com as cinco etapas resolvidas em ordem, o marck0101 ficou com:
Domínio e hospedagem independentes: trocar de hospedagem exige só mudar o DNS.
Publicação automática: cada mudança aprovada vai pro ar sem passo manual.
Rastreabilidade: toda alteração em produção tem histórico e pode ser desfeita.
Dados protegidos: desenvolvimento e produção nunca se misturam, e credenciais ficam fora do código.
Papéis claros: site e API em endereços próprios.
Limitações
Este é um projeto pessoal, de pequena escala. Temas como backup do banco, monitoramento, custos e times maiores não entraram aqui — cada um merece um artigo próprio.
Conclusão
A hipótese se confirma: colocar um projeto no ar não é um passo único, mas uma sequência de cinco etapas — domínio, DNS, versionamento, banco e deploy. Resolvidas em ordem, elas dão controle sobre o projeto sem exigir que você seja especialista. É isso que tira um projeto do "roda na minha máquina" e coloca ele no ar de verdade.
Antes de entrar nas decisões técnicas específicas de cada camada, vale uma pausa num ponto que não é sobre código nenhum: o que muda na forma de trabalhar quando a IA entra na equação — e se isso ajuda ou atrapalha.