Viernes 6:30 p.m.: corrección FTP urgente, archivo olvidado, caché de código de operación no borrado, retroceso imposible porque nadie etiquetó la versión anterior. El equipo tiene dos desarrolladores y un fundador: ningún ingeniero de plataforma dedicado ni un gran presupuesto de infraestructura. Sin embargo, un oleoducto de treinta líneas habría desplegado la misma corrección en dos minutos, con historia.
Este escenario se repite tan pronto como el despliegue manual se convierte en la norma bajo presión. CI/CD para un equipo pequeño no es un catálogo de herramientas DevOps. Se trata de automatizar las acciones que ya realiza y dejar de confiar la producción a clics manuales cansados.
La ambición correcta no es “hacer como los gigantes de la web”. Ya no implementa la producción desde la computadora portátil del sofá, sin el permiso explícito del viernes por la noche.
Comience poco a poco: un flujo de trabajo que une, pruebe e implemente en la etapa de preparación suele ser suficiente durante la primera semana. Agregue producción manual solo cuando la puesta en escena haya demostrado ser confiable, y no al revés.
El oleoducto mínimo viable
1. Activador: presione "principal" o combine la solicitud de extracción.
2. Install + lint + test, que a menudo se interrumpe en la producción (sintaxis, pruebas de pago, migraciones en seco).
3. Compilación: artefacto versionado (archivo, imagen de Docker, recursos compilados).
4. Implementar preparación: automático; prueba de humo rizo o dramaturgo ligero.
5. Implementar prod: manual aprobado o etiqueta v*; Notificación floja o por correo electrónico.
| Paso | Herramienta común | Omitir si… |
|---|---|---|
| Pelusa | ESLint, PHPStan | Nunca: coste casi nulo |
| Pruebas | PHPUnit, broma | Sólo prototipo desechable |
| Construir | npm ejecutar compilación | PHP puro sin activos |
| Implementar | SSH + rsync, Nube inteligente, Forge | Compartido sin SSH |
Primero automatice lo que ya ha provocado una interrupción. El resto espera.
Método de alojamiento e implementación
VPS + SSH: script idempotente, lanzamientos en /var/www/releases/ más enlace simbólico actual, retroceso = redireccionamiento de enlace.
PaaS (Clever Cloud, Platform.sh, Render): implementación de git push; CI llama a CLI o webhook.
Compartido: CI limitada; a veces sólo FTP. Considere migrar a VPS o PaaS cuando realice la implementación más de dos veces por semana.
El modo de implementación condiciona la canalización: una PaaS como Clever Cloud acepta un envío de Git desde el CI; un VPS solicita SSH y un script idempotente. Elegir el alojamiento y la canalización juntos evita crear cuarenta puestos de trabajo para un servicio compartido que sólo acepta FTP.
Compare hosts adecuados para la implementación de Git en nuestra comparación.
Ejemplo de flujo de trabajo mínimo
Un archivo .github/workflows/deploy.yml de treinta líneas suele ser suficiente: activación en main, instalación de dependencias, lint, pruebas, compilación, implementación de SSH en preproducción. La producción sigue activada manualmente mediante workflow_dispatch o etiqueta. Documente las variables secretas en el archivo README interno (host SSH, clave privada, ruta de implementación) para que el procedimiento sobreviva a la partida del desarrollador.
Errores de equipos pequeños
Un canal de veinticinco minutos termina por omitirse: nadie espera, el FTP regresa. Borrar secretos en un .env cometido "por olvido" sigue siendo la causa más común de compromiso. Producción automática sin preproducción convierte cada fusión en una ruleta rusa. La falta de reversión documentada provoca pánico ante el primer fallo. Finalmente, sin notificaciones, la implementación fallida la descubre el cliente, nunca el equipo.
Reversión sin dramas
Etiquetas Git en cada versión de producción. Artefactos conservados en N versiones. Enlace simbólico PaaS o retroceso en un solo comando. Base: migraciones reversibles o copia de seguridad previa a la implementación; consulte estrategia de copia de seguridad.
La cumbre: Automatización que nunca se ejecuta
Más valen tres escenarios siempre verdes que una catedral sin pasar por alto.
Decide y avanza sin puntos ciegos
Comience enumerando las últimas tres interrupciones relacionadas con la implementación: esta es su acumulación prioritaria. Luego, escriba un flujo de trabajo de hasta cinco pasos que cubra esos riesgos específicos. Conecte los secretos de la forja y la implementación automática en preproducción. Requerir una prueba de humo antes de entrar en producción. Documente el procedimiento de reversión en una página accesible para todo el equipo. Si coloca el artefacto en un contenedor, consulte también nuestra guía Docker para principiantes.
Preguntas frecuentes
¿Qué herramienta de CI para dos desarrolladores?
GitHub Actions o GitLab CI son más que suficientes. Evite el Jenkins autohospedado siempre que la administración cueste más que las ganancias: dos desarrolladores no tienen tiempo para mantener una forja de CI junto con el producto.
¿Qué probar antes de implementar?
El linter, las pruebas críticas y una construcción limpia forman la base. Agregue una prueba HTTP de preproducción si la tiene; no es necesario una cobertura exhaustiva para comenzar.
¿Implementar producción automática desde la combinación?
Demasiado arriesgado sin preproducción. Implementar preproducción automáticamente; Mantenga la producción manual o activada por etiqueta después de la validación.
¿Dónde almacenar los secretos de CI?
En los secretos cifrados de la fragua, nunca en el almacén. Planifique la rotación cuando el equipo se vaya.
CI/CD para un equipo pequeño no es "hacer como Google". Ya no implementa la producción desde la computadora portátil del sofá, sin permiso explícito el viernes por la noche.