Pipeline CI/CD para PHP do zero: guia prático de configuração

Por que usar CI/CD se você não é um robô?

Imagine: sexta-feira à noite, você acabou de finalizar uma funcionalidade, faz o upload do código para o servidor via FTP (sim, isso ainda acontece) e… o site cai com uma tela branca da morte. Familiar? Se você tivesse um pipeline CI/CD para PHP, tudo teria acontecido automaticamente: os testes falhariam já no momento do push, o código não iria para produção, e você poderia ir tomar um café tranquilo.

Continuous Integration e Continuous Delivery (ou Deployment) não são apenas siglas da moda. São seus assistentes pessoais que verificam o código, executam testes, fazem linting, geram artefatos e fazem deploy no servidor. Neste artigo, vou mostrar como configurar um pipeline CI/CD para PHP do zero usando GitHub Actions. Sem abstrações — apenas código real e exemplos funcionais.

O que é um pipeline CI/CD e por que desenvolvedores PHP precisam dele

Um pipeline CI/CD é uma sequência de etapas automáticas executadas toda vez que você envia código para o repositório. Para PHP, isso é especialmente importante porque:

\n
• PHP é uma linguagem dinâmica, e muitos erros (digitação, tipos incorretos) só aparecem em tempo de execução.
\n
• O deploy muitas vezes é feito "de qualquer jeito" — via SCP, rsync ou até FTP (um desabafo).
\n
• As equipes crescem, e as verificações manuais se tornam um gargalo.
\n

Ao configurar CI/CD para PHP, você ganha:

\n
• Testes automáticos a cada push.
\n
• Verificação de estilo de código (PSR-12, seu padrão interno).
\n
• Deploy automático para staging/production.
\n
• Notificações no Telegram/Slack sobre o status da build.
\n

Escolhendo a ferramenta: por que GitHub Actions?

Existem muitas opções: Jenkins, GitLab CI, Bitbucket Pipelines, CircleCI. Mas para configurar um pipeline CI/CD para PHP do zero, recomendo o GitHub Actions. Por quê?

\n
• Gratuito para repositórios públicos (e 2000 minutos por mês para privados — mais que suficiente).
• Tudo em um só lugar — código, issues, actions.
• Ecossistema enorme de ações prontas — não precisa reinventar a roda.

Mas se você usa GitLab — os princípios são os mesmos, apenas a sintaxe YAML é diferente. Vamos nessa.

Passo 1: Estrutura do repositório e arquivos básicos

Para demonstração, vamos usar um projeto PHP típico com Laravel (mas a abordagem funciona para qualquer framework). Sua estrutura deve ser assim:

my-php-app/\n├── .github/\n│   └── workflows/\n│       └── ci-cd.yml\n├── src/\n├── tests/\n├── composer.json\n├── phpunit.xml\n└── .php_cs.dist (se usar PHP-CS-Fixer)

Crie a pasta .github/workflows/ e o arquivo ci-cd.yml — este é o coração do seu pipeline.

Passo 2: YAML básico — Integração Contínua (CI)

Vamos começar simples: executar testes e linting a cada push na main ou pull request. Aqui está um pipeline CI/CD para PHP mínimo:

name: PHP CI/CD Pipeline\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n\n    steps:\n      - uses: actions/checkout@v4\n\n      - name: Setup PHP\n        uses: shivammathur/setup-php@v2\n        with:\n          php-version: '8.2'\n          extensions: mbstring, pdo, sqlite, gd\n          coverage: xdebug\n\n      - name: Install dependencies\n        run: composer install --prefer-dist --no-progress\n\n      - name: Run PHP CS Fixer (Lint)\n        run: vendor/bin/php-cs-fixer fix --dry-run --diff\n\n      - name: Run PHPStan (Static Analysis)\n        run: vendor/bin/phpstan analyse src --level=5\n\n      - name: Run Tests\n        run: vendor/bin/phpunit --coverage-text

O que está acontecendo aqui?

\n
• checkout — baixa o código.
\n
• setup-php —