Pipeline CI/CD para PHP desde cero: guía paso a paso

¿Para qué necesitas CI/CD si no eres un robot?

Imagina: viernes por la tarde, acabas de terminar una funcionalidad, subes el código al servidor por FTP (sí, todavía pasa), y… el sitio se cae con una pantalla blanca de la muerte. ¿Te suena? Si hubieras tenido un pipeline CI/CD para PHP, todo habría ocurrido automáticamente: los tests habrían fallado al hacer push, el código no habría llegado a producción, y tú te habrías ido tranquilo a tomar un café.

Integración Continua y Entrega/Despliegue Continuos (CI/CD) no son solo siglas de moda. Son tu asistente personal que revisa el código, ejecuta tests, aplica linting, genera artefactos y despliega en el servidor. En este artículo te mostraré cómo configurar un pipeline CI/CD para PHP desde cero usando GitHub Actions. Sin teoría abstracta, solo código real y ejemplos prácticos.

¿Qué es un pipeline CI/CD y por qué lo necesita un desarrollador PHP?

Un pipeline CI/CD es una secuencia de pasos automáticos que se ejecutan cada vez que subes código al repositorio. Para PHP es especialmente importante porque:

\n
• PHP es un lenguaje dinámico y muchos errores (tipográficos, tipos incorrectos) aparecen solo en tiempo de ejecución.
\n
• El despliegue suele hacerse "a la rápida" con SCP, rsync o incluso FTP (un grito al cielo).
\n
• Los equipos crecen y las revisiones manuales se convierten en un cuello de botella.
\n

Al configurar CI/CD para PHP, obtienes:

\n
• Pruebas automáticas en cada push.
\n
• Revisión del estilo de código (PSR-12, tu estándar interno).
\n
• Despliegue automático en staging/producción.
\n
• Notificaciones en Telegram/Slack sobre el estado de la compilación.
\n

Eligiendo la herramienta: ¿por qué GitHub Actions?

Hay muchas opciones: Jenkins, GitLab CI, Bitbucket Pipelines, CircleCI. Pero para configurar un pipeline CI/CD para PHP desde cero, recomiendo GitHub Actions. ¿Por qué?

\n
• Gratuito para repositorios públicos (y 2000 minutos al mes para privados, más que suficiente).
\n
• Todo en un mismo lugar: código, issues, actions.
\n
• Ecosistema enorme de acciones predefinidas: no necesitas reinventar la rueda.
\n

Pero si usas GitLab, los principios son los mismos, solo cambia la sintaxis YAML. ¡Empecemos!

Paso 1: Estructura del repositorio y archivos básicos

Para la demostración, usaremos un proyecto PHP típico con Laravel (pero el enfoque funciona con cualquier framework). Tu estructura debería verse así:

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

Crea la carpeta .github/workflows/ y el archivo ci-cd.yml — este es el corazón de tu pipeline.

Paso 2: YAML básico — Integración Continua (CI)

Empecemos con algo simple: ejecutar tests y linting en cada push a main o en cada pull request. Este es un pipeline CI/CD para PHP mínimo:

name: Pipeline CI/CD PHP\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: Configurar 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: Instalar dependencias\n        run: composer install --prefer-dist --no-progress\n\n      - name: Ejecutar PHP CS Fixer (Linting)\n        run: vendor/bin/php-cs-fixer fix --dry-run --diff\n\n      - name: Ejecutar PHPStan (Análisis estático)\n        run: vendor/bin/phpstan analyse src --level=5\n\n      - name: Ejecutar Tests\n        run: vendor/bin/phpunit --coverage-text

¿Qué ocurre aquí?

\n
• checkout — descarga el código.
\n
• setup-php —