Definición
El despliegue es el proceso de llevar una versión del código desde donde se desarrolla hasta el servidor donde lo usan los usuarios reales.
Suena trivial y es donde se concentran muchos de los problemas serios, por una razón sencilla: es el único momento en que tocas producción. Todo lo demás se puede probar; el despliegue, hasta cierto punto, se hace y se ve qué pasa.
La diferencia entre un equipo tranquilo y uno que sufre no está en si despliega mucho o poco. Está en si el despliegue es repetible y reversible.
Formas de desplegar
Manual por FTP. Arrastrar ficheros con un cliente. Funciona y es la peor opción: no sabes qué versión hay arriba, una subida a medias deja el sitio roto, y no hay forma de volver atrás.
Por script. Un comando que empaqueta, sube y descomprime. Es el salto de calidad más grande por menos esfuerzo: repetible, rápido y siempre igual.
Con CI/CD. Al subir a la rama principal, un servidor compila, pasa las pruebas y despliega solo. Lo ideal cuando hay equipo.
Con contenedores. Se despliega una imagen entera, no ficheros sueltos.
Estrategias para no cortar el servicio
- Sustitución directa. Paras, subes, arrancas. Hay unos segundos de caída. Para muchos sitios es perfectamente aceptable.
- Azul-verde. Dos entornos idénticos: mientras uno atiende, actualizas el otro y cambias el tráfico de golpe. Volver atrás es cambiar el tráfico otra vez.
- Canario. Mandas el 5 % del tráfico a la versión nueva, miras los errores y, si va bien, subes el porcentaje.
- Banderas de funcionalidad. Despliegas el código con la función apagada y la enciendes cuando quieres. Separa desplegar de publicar, que es una idea muy potente.
Ejemplo práctico
Mis despliegues son por script, y hay una decisión concreta que conviene entender porque tiene una consecuencia que no es obvia.
El script empaqueta la carpeta compilada, la sube por SSH y la descomprime encima de lo que ya hay. Nunca borra nada. El motivo es bueno: bajo el mismo dominio conviven la web y dos aplicaciones más —el gimnasio y la de estudio— que tienen sus propias bases de datos con datos reales. Un despliegue que sincronizara borrando se llevaría por delante meses de entrenamientos registrados.
Ahora la consecuencia: lo que se subió una vez se queda para siempre. Al auditar la web me encontré un panel privado publicado y accesible: /app/agenda/, /app/economia/. Eran 24 MB y 686 ficheros de un despliegue viejo, de antes de que existiera el script que los excluye. El script funcionaba bien; simplemente nunca había borrado nada.
Dos lecciones de ahí. La primera: un despliegue que no borra necesita una limpieza periódica, porque acumula. La segunda: antes de tocar producción, saber exactamente qué hay arriba. Bajé una copia completa del servidor y la comparé con lo que debía haber. Esa comparación fue lo que sacó el problema.
Una lista antes de tocar producción
- ¿Está el código en el control de versiones y etiquetado?
- ¿Han pasado las pruebas?
- ¿Hay migraciones de base de datos? ¿Se han probado con datos reales?
- ¿Hay copia de seguridad reciente y comprobada?
- ¿Sé cómo volver atrás si sale mal?
- ¿Hay rutas de datos vivos que el despliegue no debe tocar?
- ¿Es buen momento? Un viernes a las siete de la tarde no lo es.
Errores comunes
- Desplegar sin poder volver atrás. La pregunta "¿y si sale mal?" hay que responderla antes, no durante.
- Cambiar el código y el esquema a la vez de forma incompatible. El código nuevo espera una columna que la migración crea después: hay una ventana en la que todo falla.
- Pisar ficheros de configuración de producción. Las credenciales del servidor no están en el repositorio, así que el despliegue tiene que excluirlas explícitamente.
- No versionar los assets. Sin huella en el nombre, los usuarios siguen viendo el CSS antiguo desde su caché.
- Desplegar sin mirar qué hay. Especialmente cuando varios proyectos comparten servidor.
- Hacerlo a mano "solo esta vez". Esa es la que sale mal.
Cuándo automatizarlo
En cuanto despliegues más de una vez al mes, o en cuanto haya alguien más. Convertir un despliegue manual en un script cuesta una tarde y elimina toda una categoría de errores: los de despiste.
Y aunque estés solo: dentro de seis meses no te vas a acordar de qué carpetas había que excluir. El script sí.
