~/VibeHandbook
PDF grátis

Capítulo 13 · 05

Como a IA monta deploys e configuração

É aqui que o vibe coding brilha. Configuração de é exatamente o tipo de trabalho preciso, bem documentado e repetitivo em que a IA é excelente. Você direciona; ela escreve.

Prompts eficazes soam assim:

  • "Adicione um Dockerfile para este app Node e uma configuração do Railway para fazer o deploy."
  • "Escreva um workflow do GitHub Actions que faça o deploy da pasta dist/ no Cloudflare Pages a cada push na main."
  • "Estou recebendo um timeout de cold-start na minha função — o que provavelmente está errado e como corrijo a configuração?"

Aqui está o tipo de arquivo que a IA vai produzir para você — um workflow de deploy que publica um site estático automaticamente sempre que você faz push de código:

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci && npm run build
      - name: Publish to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CF_API_TOKEN }}
          command: pages deploy dist --project-name=my-app

Você não precisa memorizar essa sintaxe. Você precisa reconhecer o que ela faz: a cada push na main, ela baixa seu código, faz o build e publica o resultado. Quando algo quebra, você cola o erro de volta para a IA e pede que ela corrija a configuração.

Muitos construtores pulam o arquivo do GitHub Actions completamente no início e simplesmente fazem o deploy do próprio com um comando. Essa costuma ser a forma mais rápida de ver algo no ar no primeiro dia. O mesmo deploy do Cloudflare Pages fica assim pela linha de comando:

# instale a CLI (Command Line Interface, interface de linha de comando) uma vez
npm install -g wrangler

# faça o build do seu site, depois envie a pasta de saída ao ar
npm run build
wrangler pages deploy dist --project-name=my-app

A primeira execução vai pedir que você faça login pelo navegador; depois disso é um único comando. O trade-off é simples: o comando de terminal é ótimo para "publicar agora", e o arquivo do GitHub Actions é ótimo para "publicar automaticamente para sempre". A maioria dos projetos começa com o primeiro e adiciona o segundo quando os deploys viram rotina. Peça à IA o que fizer mais sentido para o momento em que você está.

Algumas dicas de direcionamento que evitam dor de cabeça real:

  • Faça a IA explicar antes de agir. "Antes de escrever a configuração, me diga qual tipo de hospedagem combina com este projeto e por quê." Isso pega excesso de engenharia cedo.
  • Mantenha segredos fora do código. Chaves de e senhas vão nas variáveis de ambiente / cofre de segredos da plataforma, nunca em arquivos que você commita. Peça à IA para usar uma referência de segredo, como no CF_API_TOKEN acima.
  • Faça deploy cedo, faça deploy sempre. Coloque um "hello world" no ar no primeiro dia. Um pipeline que já funciona desde o início é muito mais fácil de depurar do que um montado só no lançamento.
  • Pergunte de antemão qual é a história do rollback (reversão). "Se esse deploy quebrar, como eu volto para a versão que funcionava?" Boas plataformas mantêm seus deploys anteriores a um clique de distância. Saber que o botão de desfazer existe antes de precisar dele transforma um pânico às 2 da manhã em um dar de ombros.

Quer offline?

Baixe o livro inteiro em PDF ou EPUB — grátis.