CI/CD na prática: deploy automático com Git na sua VPS

Se você ainda publica seu site arrastando arquivos por FTP, conhece a dor: é lento, é fácil esquecer um arquivo, e um upload pela metade quebra o site. CI/CD resolve isso: você dá um git push e o servidor se atualiza sozinho, de forma consistente. Não é só para grandes times — dá para montar algo simples e poderoso numa VPS.

O que é CI/CD (sem complicar)

• CI (Integração Contínua) — a cada mudança no código, testes e verificações rodam automaticamente.
• CD (Entrega/Deploy Contínuo) — o código aprovado é publicado automaticamente no servidor.

Para um projeto pessoal ou pequeno, o coração do valor está no CD: publicar sem esforço manual, sempre do mesmo jeito. É previsível, rápido e reversível.

Nível 1: deploy com git pull (o mais simples)

O jeito mais direto: o servidor tem um clone do repositório, e o deploy é um git pull.

1. Na VPS, clone o repositório na pasta do site.
2. Crie um script de deploy deploy.sh:

#!/bin/bash
cd /var/www/meusite
git pull origin main
# passos extras do seu projeto, por exemplo:
# composer install --no-dev
# npm ci && npm run build
# systemctl reload php8.2-fpm
echo "Deploy concluído: $(date)"

3. Quando quiser publicar, rode ./deploy.sh no servidor (ou via SSH da sua máquina). Fim do FTP.

Já é um salto enorme: atômico, versionado e com histórico. O próximo passo é tirar o "rodar na mão".

Nível 2: deploy automático por webhook

Faça o git push disparar o deploy sozinho. O GitHub/GitLab pode chamar uma URL (webhook) na sua VPS a cada push. Um pequeno endpoint recebe a chamada e executa o deploy.sh.

Pontos de atenção:

• Valide a assinatura do webhook (segredo compartilhado) para ninguém disparar deploy à toa.
• Rode o deploy com um usuário de permissão adequada.
• Registre logs de cada deploy.

Agora é literalmente: git push → site atualizado em segundos.

Nível 3: GitHub Actions com deploy por SSH

Para incluir testes antes de publicar (o "CI" de verdade), o GitHub Actions é o padrão. Um workflow roda a cada push: instala dependências, roda os testes e, se tudo passar, conecta na VPS por SSH e executa o deploy.

O esqueleto de um workflow (.github/workflows/deploy.yml):

name: Deploy
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # ... rodar testes aqui ...
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: cd /var/www/meusite && ./deploy.sh

As credenciais ficam nos Secrets do repositório (nunca no código). Use uma chave SSH dedicada ao deploy, com acesso mínimo — veja SSH seguro.

Boas práticas de deploy

• Nunca guarde senhas/chaves no repositório — use secrets e arquivos .env fora do versionamento.
• Faça backup antes de deploys que mexem no banco. Veja backup de banco.
• Tenha um caminho de rollback — com Git, é voltar para o commit anterior e rodar o deploy de novo.
• Deploys que reiniciam serviços: faça em horário de baixo movimento.
• Para apps em contêiner, o deploy vira docker compose pull && up -d — veja Docker em produção.

Precisa de acesso SSH e controle — precisa de VPS

CI/CD com deploy por SSH exige acesso root/SSH ao servidor, impossível numa compartilhada. A VittHost oferece VPS com root e IP dedicado, no Brasil e no Canadá:

👉 Ver planos de VPS

Pare de arrastar arquivos — com um git push, o servidor se atualiza sozinho.