CI/CD para proyectos PHP: GitHub Actions de la A a la Z

Introducción: Por qué CI/CD es el nuevo estándar del desarrollo PHP

El desarrollo PHP moderno es impensable sin automatización. El despliegue manual, ejecutar pruebas "a ojo" y revisar el código en el último momento es un camino directo a errores en producción. CI/CD (Integración Continua / Despliegue Continuo) resuelve estos problemas integrando verificaciones y despliegue de código directamente en tu flujo de trabajo.

GitHub Actions es una herramienta potente y gratuita para integrar CI/CD directamente en el repositorio. En este artículo, analizaremos cómo configurar un pipeline completo para un proyecto PHP en Laravel o Symfony: desde la instalación de dependencias hasta el despliegue en el servidor. Obtendrás configuraciones listas y comprensión de cada etapa.

1. Fundamentos de GitHub Actions: estructura de Workflow para PHP

Un Workflow en GitHub Actions es un proceso automatizado definido en un archivo YAML dentro de la carpeta .github/workflows/. Para un proyecto PHP, un workflow típico incluye:

\n
• Disparadores: push a la rama main, pull request.
\n
• Runner: Ubuntu latest (soporte para PHP).
\n
• Pasos: Checkout, instalación de PHP, Composer, pruebas, linters.
\n

Veamos el archivo 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 se ejecuta en cada push. Verifica que el código se compile y las pruebas pasen. Observa la acción shivammathur/setup-php — es el estándar de facto para PHP.

2. Configuración avanzada: análisis estático, linters y almacenamiento en caché

CI no se limita solo a pruebas. Para mantener la calidad del código, añade análisis estático (PHPStan, Psalm) y verificación de estilo (PHP CS Fixer).

2.1. Añadiendo PHPStan y PHP CS Fixer

Instálalos como dependencias de desarrollo:

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

Complementa los pasos en el 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

Consejo: usa --dry-run para no modificar archivos, solo verificar. Si el estilo se viola, el CI fallará y el desarrollador lo corregirá.

2.2. Almacenamiento en caché de dependencias de Composer

Cada ejecución de CI descarga los paquetes nuevamente, lo cual es lento. Habilitamos el almacenamiento en caché:

    - 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

Ahora las ejecuciones repetidas serán 2-3 veces más rápidas.

3. Pruebas con base de datos y servicios Docker

Muchas aplicaciones PHP requieren MySQL, PostgreSQL o Redis para las pruebas. GitHub Actions permite ejecutar contenedores de servicio (Service Containers).

3.1. Ejemplo con MySQL y Laravel

Supongamos que tu proyecto usa Laravel con MySQL. Añadimos el servicio y configuramos .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