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
Dockerfilepara 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 namain." - "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_TOKENacima. - 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.