5.4Despliegue y CI/CD (Git, servidor, alojamiento)
Lo esencial en 30 segundos
- Desplegar = poner en línea: hacer correr la app en un servidor accesible — alojamiento compartido simple para empezar, PaaS/VPS para más control.
- CI/CD = entrega auto: en cada push, probar (PHPUnit) luego desplegar si todo pasa — fin del FTP manual arriesgado.
- Secretos fuera del código: config y secretos en variables de entorno (.env fuera del depósito) — nunca en Git.
Mini-caso hilado — Riad pone en línea en Constantina
La tienda contenerizada de Riad corre bien — pero solo en los puestos del equipo en Constantina. La despliega: depósito Git conectado, variables de entorno informadas en el alojamiento, HTTPS activo, errores registrados en lugar de mostrados. Luego añade un pipeline: en cada push, los tests PHPUnit corren, y el despliegue sigue solo si pasan. Último episodio de los casos 5.1-5.3 — Riad entrega un verdadero servicio en línea.
Último episodio de los casos 5.1-5.3 — Riad cierra concepción, rendimiento y Docker con la puesta en producción.
1. Alojar y desplegar vía Git
El despliegue hace correr la aplicación en un servidor accesible en Internet (en lugar de localhost). PHP tiene la ventaja de ser muy extendido y fácil de alojar: el alojamiento compartido (lo más simple y económico — el alojador lo gestiona todo — ideal para empezar y los pequeños sitios, con poco control), las plataformas PaaS (despliegue simplificado desde el depósito Git), el VPS (más control pero más responsabilidades: instalar PHP, Nginx/Apache, MySQL, asegurar, HTTPS), la nube para la envergadura. Papel central de Git: ya no se transfieren los archivos «a mano» por FTP (fuente de errores) — el servidor recupera el código desde el depósito, más fiable y trazable. Riad empieza por un compartido para la vitrina, y apunta a un VPS cuando la tienda crece.
Recomendación: compartido para poner sus proyectos en línea rápido, PaaS para un despliegue simplificado moderno, VPS para aprender la administración o ganar en control.
2. CI/CD y esenciales de producción
El CI/CD automatiza el camino código → producción. La integración continua: en cada push, un pipeline lanza los tests (PHPUnit) y el análisis de calidad para atrapar los problemas pronto. El despliegue continuo: si todo pasa, el código se despliega automáticamente. GitHub Actions (o GitLab CI) crea estos pipelines. Beneficios: automatización (fin de los gestos manuales fastidiosos), fiabilidad (nada roto parte a producción), rapidez, trazabilidad. Esenciales de producción PHP: secretos y config por entorno (archivo .env fuera del depósito), HTTPS indispensable, errores no mostrados (registrados — pueden divulgar informaciones sensibles), OPcache activado, autoloader Composer optimizado, migraciones ejecutadas al desplegar, entornos separados (dev/staging/prod). Riad escribe su primer pipeline: instalar, probar, desplegar si verde — es la culminación, no solo crear sino entregar.
Incluso simple, un pipeline lo cambia todo: los tests ya nunca se «olvidan» antes de un despliegue.
3. Elegir sin equivocarse
El compromiso fundamental: simplicidad contra control. Compartido: simplicidad extrema para empezar, poco control. PaaS: simplicidad moderna sin gestionar servidor. VPS: control total y flexibilidad, pero usted lo gestiona todo (seguridad, actualizaciones, copias de seguridad). Para un prototipo, un despliegue simple basta; en cuanto un proyecto es serio, desplegado regularmente o en equipo, incluso un CI/CD simple aporta un verdadero valor. Riad compara las ofertas de los alojadores (fórmulas y límites que evolucionan a menudo, verifica la documentación actual al elegir) y hace validar la elección de infraestructura sensible por su DSI antes de exponer datos reales, copias de la base incluidas.
En todos los casos, los esenciales quedan: secretos en variables de entorno, HTTPS, errores registrados, OPcache, copias de seguridad, entornos separados.
🔎 Ejemplo concreto — El pipeline de Riad
En cada push: instalar, probar, desplegar si verde.
# GitHub Actions (.github/workflows/ci.yml)
# en cada push :
# composer install → vendor/bin/phpunit → desplegar si verde
# secretos y config : variables de entorno (.env fuera del depósito)
# producción : HTTPS + OPcache + errores registradosLectura: el pipeline es la puerta: nada roto pasa.
Lección: los secretos viven en el entorno, nunca en el depósito.
Vocabulario de la sección
- Despliegue
- Hacer correr la app en un servidor accesible en Internet.
Ejemplo sencillo: La tienda de Riad deja localhost por una dirección pública.
Lo que no es: enviar archivos por FTP a mano.
Reflejo: ¿mi app es accesible fuera de mi puesto?
- Alojamiento compartido
- Servidor compartido donde el alojador gestiona PHP, la base y el servidor web.
Ejemplo sencillo: Riad pone allí la vitrina en línea rápido y con poco presupuesto.
Lo que no es: un servidor que se administra uno mismo.
Reflejo: ¿necesito control, o simplicidad?
- VPS
- Servidor virtual alquilado que se administra uno mismo.
Ejemplo sencillo: Riad instalaría allí PHP, MySQL y el HTTPS él mismo.
Lo que no es: un alojamiento donde todo está gestionado.
Reflejo: ¿estoy listo para asumir seguridad y copias?
- CI/CD
- Pipeline que prueba en cada push y despliega si todo pasa.
Ejemplo sencillo: El push de Riad dispara PHPUnit luego la puesta en línea auto.
Lo que no es: un despliegue manual a golpes de FTP.
Reflejo: ¿un push puede salir a prod sin tests?
- Variables de entorno
- Config y secretos aportados por el entorno, fuera del código.
Ejemplo sencillo: La contraseña base de Riad vive en el .env, nunca en Git.
Lo que no es: un secreto escrito en duro en el código.
Reflejo: ¿un secreto ronda en mi depósito?
En la práctica — Desplegar y automatizar una aplicación PHP
- Elija un alojamiento adaptado (compartido para un pequeño sitio, PaaS/VPS para más control) y despliegue su aplicación vía Git (no FTP manual).
- Configure la producción: secretos y parámetros vía variables de entorno (.env fuera del depósito), HTTPS, errores registrados (no mostrados), OPcache activado.
- Ponga en marcha un pipeline CI/CD (GitHub Actions): en cada push, lanzar los tests (PHPUnit) y desplegar si todo pasa.
- Gestione las migraciones de base al desplegar (framework) y unos entornos separados (dev / staging / producción).
Guion listo para decir — anunciar la puesta en línea
«Nuestra tienda está lista para salir de localhost: la despliego vía Git — secretos en variables de entorno, HTTPS activo, errores registrados. Añado un pipeline simple: PHPUnit en cada push, despliegue solo si todo pasa. Antes de exponer datos reales, hago validar la elección de infraestructura y las copias por la DSI.»
A decir al responsable para hacer validar la puesta en línea y el circuito DSI en los datos sensibles.
Modelo copiar-pegar — pipeline CI PHP genérico
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
- run: composer install --no-progress
- run: vendor/bin/phpunitSolo / presupuesto pequeño
Riad solo: un compartido + un pipeline que prueba en cada push basta — sin servidor que administrar.
TPE / equipo reducido
Entornos dev y prod separados, secretos fuera del depósito: cada push probado antes de la puesta en línea.
PYME en Constantina
Riad hace validar el alojador, los accesos y las copias por la DSI en Constantina antes de exponer datos reales de clientes.
Equipo que empieza
Pareja: uno escribe el pipeline, el otro verifica secretos, HTTPS y copias; revisión antes del primer despliegue auto.
✓ Buenas prácticas
- Empezar con un alojamiento simple (compartido/PaaS): en línea rápido, HTTPS gestionado.
- Poner config y secretos en variables de entorno (.env fuera del depósito, nunca en Git).
- Automatizar tests + despliegue con un pipeline CI/CD (GitHub Actions).
✗ Errores frecuentes
- Poner secretos en el código o el depósito Git.
- Desplegar sin HTTPS ni copias verificadas.
- Desplegar manualmente por FTP, a ciegas (sin tests automatizados antes).
Puntos clave
- DESPLEGAR = hacer correr la app PHP en un servidor accesible en Internet. Opciones: ALOJAMIENTO COMPARTIDO (simple, económico), PaaS, VPS (control + responsabilidades), nube. PHP es fácil de alojar.
- Desplegar vía GIT (el servidor recupera el código) en lugar de por FTP manual (fiable, trazable). CI/CD (GitHub Actions) automatiza: CI (tests PHPUnit en cada push) + CD (desplegar si pasa).
- Configuración y SECRETOS: vía variables de entorno (.env FUERA del depósito Git), nunca codificados en duro. Esenciales prod: HTTPS, errores NO mostrados (registrados), OPcache activado, autoloader Composer optimizado, migraciones.
- Este nivel CONECTA todo: lenguaje → web → bases → POO → frameworks → seguridad → tests → optimización → Docker → LLEVAR A PRODUCCIÓN. Saber ENTREGAR (desplegar + automatizar) culmina el desarrollador PHP autónomo.
Reto 48h — aplique mañana
Despliegue 1 app (depósito Git + HTTPS) con sus secretos en variables de entorno: ¿un push dispara los tests PHPUnit?
- Puedo explicar CI vs CD en una frase.
- Mi app está en línea (HTTPS) sin secreto en Git.
- Sé cuándo pasar del compartido al VPS.
Preguntas frecuentes
¿Cómo elegir dónde y cómo alojar una aplicación PHP, sobre todo cuando se empieza?
Según el tamaño del proyecto, la necesidad de control y su nivel. El alojamiento compartido es lo más simple y económico — el alojador lo gestiona todo — ideal para empezar y los pequeños sitios (PHP está masivamente soportado, una baza). Las plataformas PaaS simplifican el despliegue desde Git, sin gestionar servidor. El VPS da más control (versiones, config) pero más responsabilidades (instalación, seguridad, HTTPS, copias) — formador, más exigente. Recomendación: empiece compartido o PaaS para poner sus proyectos en línea; pase al VPS para aprender la administración. Compare las ofertas al elegir (evolucionan) y haga validar por la DSI antes de exponer datos sensibles.
¿Cuáles son los puntos esenciales a no olvidar en la puesta en producción de una aplicación PHP?
La lista: secretos por entorno (.env fuera del depósito, nunca en Git); HTTPS obligatorio; errores no mostrados (registrados — los detalles técnicos divulgados son explotables); OPcache activado y autoloader Composer optimizado (rendimiento); migraciones ejecutadas al desplegar; entornos separados (dev/staging/prod); copias planificadas y restauración probada. Cada uno de estos puntos olvidado cuesta caro: falla de seguridad, lentitud sin razón, o pérdida de datos. El pipeline CI/CD cierra la puerta: nada no probado parte a producción.
¿Qué hace un pipeline CI/CD?