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

Introducción a CI/CD para proyectos PHP con GitHub Actions

El desarrollo moderno de aplicaciones PHP es imposible sin automatización. Las pruebas y el despliegue manuales no solo son lentos, sino que también son propensos a errores. CI/CD (Continuous Integration / Continuous Deployment) resuelve estos problemas automatizando la verificación del código y su entrega al servidor. Una de las herramientas más populares para esto es GitHub Actions.

GitHub Actions es una plataforma integrada para automatizar flujos de trabajo (workflows) que permite ejecutar pruebas, linters, compilaciones y despliegues directamente desde tu repositorio en GitHub. En este artículo, analizaremos cómo configurar un pipeline completo de CI/CD para un proyecto PHP: desde la ejecución simple de pruebas hasta el despliegue automático en un servidor de producción.

Usaremos un ejemplo basado en Laravel, pero todos los principios son aplicables a cualquier framework PHP (Symfony, Yii, WordPress, etc.). Aprenderás cómo escribir configuraciones YAML, usar matrices de prueba, almacenar en caché dependencias y desplegar código de forma segura.

Parte principal

1. Fundamentos de GitHub Actions: estructura de un workflow

Un workflow es un proceso automatizado que se ejecuta en respuesta a un evento específico (push, pull request, creación de tag). Cada workflow se describe en un archivo YAML que se almacena en el directorio .github/workflows/ de tu repositorio.

Estructura básica del archivo .github/workflows/ci.yml:

name: CI Pipeline

on:  push:    branches: [ main, develop ]  pull_request:    branches: [ main ]

jobs:  test:    runs-on: ubuntu-latest

    steps:      - name: Checkout repository        uses: actions/checkout@v4

      - name: Setup PHP        uses: shivammathur/setup-php@v2        with:          php-version: '8.2'          extensions: mbstring, xml, bcmath, pdo_mysql          coverage: xdebug

      - name: Install dependencies        run: composer install --no-progress --prefer-dist

      - name: Run PHPUnit tests        run: vendor/bin/phpunit --coverage-text

Analicemos los elementos clave:

• on — disparadores: push en main/develop, pull request en main.
• jobs — conjunto de tareas (jobs) que se ejecutan en paralelo o secuencialmente.
• runs-on — sistema operativo para la ejecución (normalmente ubuntu-latest).
• steps — secuencia de pasos dentro de un job.
• uses — actions predefinidas del marketplace (por ejemplo, shivammathur/setup-php).
• run — ejecución de un comando shell.

2. Configuración avanzada: matriz de prueba y almacenamiento en caché

Para proyectos grandes, es útil probar múltiples versiones de PHP y dependencias simultáneamente. Esto se logra mediante una matriz de estrategias (matrix strategy). También es importante almacenar en caché la carpeta vendor de Composer para acelerar la ejecución del workflow.

Ejemplo con matriz y caché:

name: Advanced CI

on: [push, pull_request]

jobs:  test:    runs-on: ubuntu-latest    strategy:      matrix:        php: [ '8.1', '8.2', '8.3' ]        dependency-stability: [ prefer-stable, prefer-lowest ]

    steps:      - uses: actions/checkout@v4

      - name: Setup PHP        uses: shivammathur/setup-php@v2        with:          php-version: ${{ matrix.php }}          extensions: mbstring, pdo, gd          coverage: none

      - name: Cache Composer packages        uses: actions/cache@v3        with:          path: vendor          key: ${{ runner.os }}-php-${{ matrix.php }}-composer-${{ hashFiles('**/composer.lock') }}          restore-keys: |            ${{ runner.os }}-php-${{ matrix.php }}-composer-

      - name: Install dependencies        run: composer install --${{ matrix.dependency-stability }} --no-interaction

      - name: Run test