CI/CD para projetos PHP: GitHub Actions do A ao Z

Introdução: Por que CI/CD é o novo padrão do desenvolvimento PHP

O desenvolvimento PHP moderno é impensável sem automação. Deploy manual, execução de testes "no olho" e verificação de código no último momento — é o caminho direto para bugs em produção. CI/CD (Continuous Integration / Continuous Deployment) resolve esses problemas, integrando verificações e implantação de código diretamente no seu fluxo de trabalho.

GitHub Actions é uma ferramenta poderosa e gratuita para incorporar CI/CD diretamente no repositório. Neste artigo, vamos detalhar como configurar um pipeline completo para um projeto PHP em Laravel ou Symfony: desde a instalação de dependências até o deploy no servidor. Você obterá configurações prontas e compreensão de cada etapa.

1. Fundamentos do GitHub Actions: estrutura do Workflow para PHP

Workflow no GitHub Actions é um processo automatizado, definido em um arquivo YAML na pasta .github/workflows/. Para um projeto PHP, um workflow típico inclui:

\n
• Gatilhos: push para o branch main, pull request.
\n
• Runner: Ubuntu latest (suporte a PHP).
\n
• Etapas: Checkout, instalação do PHP, Composer, testes, linters.
\n

Vamos analisar o arquivo mínimo ci.yml:

name: PHP CI\n\non:\n  push:\n    branches: [ main ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n\n    steps:\n    - uses: actions/checkout@v3\n\n    - name: Setup PHP\n      uses: shivammathur/setup-php@v2\n      with:\n        php-version: '8.2'\n        extensions: mbstring, pdo_mysql, xml\n        coverage: xdebug\n\n    - name: Install Composer dependencies\n      run: composer install --no-progress --prefer-dist\n\n    - name: Run PHPUnit\n      run: vendor/bin/phpunit --testdox

Este workflow é executado a cada push. Ele verifica se o código compila e os testes passam. Observe a action shivammathur/setup-php — ela é, de fato, o padrão para PHP.

2. Configuração avançada: análise estática, linters e cache

O CI não se limita apenas a testes. Para manter a qualidade do código, adicione análise estática (PHPStan, Psalm) e verificação de estilo (PHP CS Fixer).

2.1. Adicionando PHPStan e PHP CS Fixer

Instale-os como dependências de desenvolvimento:

composer require --dev phpstan/phpstan friendsofphp/php-cs-fixer

Complemente as etapas no workflow:

    - name: Run PHPStan\n      run: vendor/bin/phpstan analyse --memory-limit=1G\n\n    - name: Check code style\n      run: vendor/bin/php-cs-fixer fix --dry-run --diff

Dica: use --dry-run para não alterar arquivos, apenas verificar. Se o estilo estiver violado — o CI falhará e o desenvolvedor corrigirá.

2.2. Cache de dependências do Composer

Cada execução do CI baixa os pacotes novamente — isso é demorado. Ativamos o cache:

    - name: Cache Composer packages\n      id: composer-cache\n      uses: actions/cache@v3\n      with:\n        path: vendor\n        key: ${{ runner.os }}-php-${{ hashFiles('**/composer.lock') }}\n        restore-keys: |\n          ${{ runner.os }}-php-\n\n    - name: Install dependencies\n      if: steps.composer-cache.outputs.cache-hit != 'true'\n      run: composer install --no-progress --prefer-dist

Agora, execuções repetidas serão 2 a 3 vezes mais rápidas.

3. Testes com banco de dados e serviços Docker

Muitas aplicações PHP exigem MySQL, PostgreSQL ou Redis para testes. O GitHub Actions permite executar contêineres de serviço (Service Containers).

3.1. Exemplo com MySQL e Laravel

Suponha que seu projeto use Laravel com MySQL. Adicionamos o serviço e configuramos o .env:

jobs:\n  test:\n    runs-on: ubuntu-latest\n    services:\n      mysql:\n        image: mysql:8.0\n        env:\n          MYSQL_ROOT_PASSWORD: root\n          MYSQ