Criativaria ✦
← voltar para guias
IntermediárioDevOps/InfraTodos

Deploy e DevOps para iniciantes

O que acontece quando você clica em 'deploy', como apps chegam ao ar, e os conceitos de DevOps que todo dev precisa entender mesmo sem ser especialista.

A maioria dos devs juniores escreve código mas não faz ideia de como ele chega até a produção. "Deploy" é aquilo que acontece depois do PR, ou algo que o sênior cuida. Entender o caminho do código até o app rodando é agora esperado até de devs que não são especialistas em infra.

Saber como funciona essa pipeline demistifica o clássico "funciona no meu local", ajuda a debugar problemas em produção e te torna um muito melhor colaborador com times de infra.

O caminho do código até o usuário

Primeiro, o modelo mental. Quando você faz push de código, não é magica que ele apareça no ar. Segue uma sequência:

  1. Código local (sua máquina): você escreve, testa localmente
  2. Repositório (GitHub/GitLab): você faz push e o repositório dispara o CI automaticamente
  3. CI (Integração Contínua): roda testes, faz build, verifica lint. Se falhar, o código não segue em frente
  4. Artefato: resultado do build, pode ser uma imagem Docker, um bundle JS, um jar Java
  5. CD (Deploy Contínuo ou Entrega Contínua): pega o artefato e coloca no servidor ou serviço de cloud
  6. Produção: onde os usuários finais acessam

A diferença entre CI e CD é importante: CI sempre roda (integrar e verificar), CD pode ser automático (continuous deployment) ou manual com um botão (continuous delivery).

Tipos de ambiente: local, staging, produção

Você precisa entender que existem três ambientes e eles não são iguais:

  • Local: sua máquina. Rápido para testar, mas pode ter diferenças do ambiente real: versão do Node diferente, variáveis de ambiente customizadas, banco de dados em SQLite enquanto produção usa PostgreSQL
  • Staging (homologação): espelho de produção. Onde você testa antes de liberar para usuários reais. Deve usar as mesmas configurações de produção, o mesmo banco de dados, a mesma infraestrutura: se só funciona local, o bug continua lá
  • Produção: o ambiente real onde os usuários estão. Mudanças aqui têm consequências reais

"Funciona no meu local" é um antipadrão clássico. A meta é que o código funcione igual em todos os ambientes. Docker ajuda bastante nisso: se roda em um container no local, roda em um container em produção, rodando tudo igual.

Docker: por que todo dev ouve esse nome

Docker empacota sua aplicação e todas as dependências em um container, um ambiente isolado e reproduzível. O mesmo container roda igual no local, no CI e em produção. Nada de "funciona aqui mas não lá".

Conceitos básicos que você precisa conhecer:

  • Imagem: a receita do container, definida no Dockerfile
  • Container: a instância rodando de uma imagem
  • Registry: onde imagens são armazenadas (Docker Hub, AWS ECR, GitHub Container Registry)

Um exemplo mínimo de Dockerfile para uma app Node.js:

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

A boa notícia: você não precisa escrever Dockerfiles do zero para começar. Plataformas como Railway e Render detectam a linguagem automaticamente e fazem o build por você.

Plataformas para começar a fazer deploy

Não existe uma resposta única, depende da complexidade do seu projeto. Aqui estão as opções realistas:

Zero config (para front-end e APIs simples):

  • Vercel: deploy de Next.js, React, Vue em segundos. Conecta seu GitHub e cada push faz deploy automático
  • Netlify: similar ao Vercel, excelente para sites estáticos e Jamstack
  • Railway: backend com banco de dados, ótimo para Node.js/Python/Ruby. Detecta o projeto automaticamente

Intermediário (mais controle):

  • Render: similar ao Railway, tem free tier generoso e documentação clara
  • Fly.io: roda containers Docker, preço transparente, boa documentação para iniciantes

Cloud providers (AWS/GCP/Azure): Curva de aprendizado bem maior, mas é onde os projetos reais vivem. Entender os serviços básicos da AWS (EC2, S3, RDS, Lambda) é habilidade valorizada no mercado. Se quiser aprofundar, o Roadmap Cloud do Zero cobre isso em detalhes.

O mínimo de DevOps que todo dev deveria saber

Você não precisa ser especialista em infra, mas entender esses conceitos faz você um dev muito melhor:

  • Variáveis de ambiente: configurações que mudam por ambiente (dev, staging, prod) ficam fora do código. Nunca comite .env com secrets reais
  • Logs: sua primeira fonte de verdade quando algo quebra em produção. Saiba sempre como acessar logs da aplicação no seu ambiente
  • Health checks: um endpoint /health que retorna 200 se a app está OK. Load balancers e orquestradores usam isso para saber se precisam reiniciar seu container
  • Rollback: se algo quebra em produção, você precisa saber como voltar para a versão anterior rapidamente. Um bom CI/CD faz isso com um clique
  • Monitoramento básico: saber quando sua app está fora do ar antes que o usuário reporte. Serviços como Sentry (erros) e UptimeRobot (uptime) são gratuitos para projetos pequenos

Checklist para você se auto-avaliar:

- [ ] Entendo a diferença entre CI (integrar e verificar) e CD (entregar para produção)?
- [ ] Já fiz deploy de pelo menos um projeto usando Vercel, Railway ou similar?
- [ ] Sei o que são variáveis de ambiente e por que não devo comitar o .env?
- [ ] Consigo acessar os logs da minha aplicação quando algo dá errado?
← voltar para o início