Bea Iglesias Roldán subió por FTP la web de reservas del balneario de Ourense un viernes a las siete. De los 412 ficheros llegaron 340 y se cortó la conexión. El sitio quedó con la mitad nueva y la mitad vieja, el formulario de reservas dejó de enviar, y no existía en ninguna parte una copia de lo que había antes.
El balneario cogió reservas por teléfono hasta el lunes. El error no fue subir un viernes: fue que subir era la única operación disponible y no tenía marcha atrás.
Una vuelta atrás es un despliegue de la versión anterior, y tiene que costar lo mismo. Cuando cuesta más, no se hace: se improvisa encima de lo roto, que es lo que pasó ahí.
Lo que le falta a una subida por FTP
Subir por FTP deja el sitio a medias si se corta, porque la subida no es atómica: cada fichero sustituye al suyo en el momento en que llega, así que durante unos minutos hay visitantes viendo una mezcla de dos versiones que nunca fue probada junta.
La forma de arreglarlo no necesita ninguna herramienta moderna y cabe en un servidor compartido. Se sube la versión nueva a una carpeta con su fecha, entera y sin tocar la que está sirviendo, y solo cuando ha llegado completa se cambia el enlace simbólico que apunta a la carpeta en uso. Un despliegue atómico cambia un enlace simbólico cuando ya está todo copiado, y esa operación tarda lo mismo que escribirla.
Lo que eso regala, además de que no haya mezcla, es la vuelta atrás: la carpeta anterior sigue ahí con su fecha, y volver es apuntar el enlace a la de antes. Diez segundos, sin subir nada. El despliegue es donde esto se monta entero, con los permisos y el reinicio incluidos.
Tres ruedas que solo giran juntas
Aquí no hay una primera cosa que aprender, y por eso este tema se siente como un muro. El historial, la construcción desde cero y las pruebas se sostienen entre sí: cada una es casi inútil sin las otras dos.
Sin historial no hay versión anterior a la que volver, que es lo que le pasó a Bea. Sin una construcción declarada, el historial guarda un código que solo arranca en un portátil concreto, con la versión de PHP que tenía puesta esa máquina. Y sin pruebas, las otras dos mueven cosas deprisa y nadie puede decir si algo sigue funcionando.
Lo que sale mal casi siempre es el orden en que se adoptan: primero se monta la automatización, que es lo vistoso, y se acaba automatizando un despliegue que nadie sabe deshacer. El orden que funciona es historial, entorno declarado, pruebas, y solo entonces la máquina que lo ejecuta todo sola.
git revert crea un commit y git reset mueve la rama
La herramienta de la primera rueda tiene dos formas de deshacer y confundirlas cuesta trabajo ajeno. git revert crea un commit nuevo y git reset mueve la rama: la primera deja el error visible en el historial y añade encima el arreglo, la segunda hace como si el error no hubiera existido.
La regla de trabajo sale de eso sin discusión. Sobre algo que ya está publicado, revert siempre, porque quien ya se descargó ese historial no puede seguir a una rama que ha cambiado por debajo. Sobre algo que solo está en tu máquina, reset es cómodo y no molesta a nadie.
El caso que se encuentra todo el mundo el primer mes es el commit con la contraseña dentro. Revert lo tapa y no lo borra: el valor sigue en el historial, accesible con dos comandos, así que la contraseña hay que cambiarla igual. Eso y el trabajo en paralelo son el control de versiones.
La máquina que no tiene nada
La segunda rueda se comprueba de una sola manera. El pipeline se ejecuta en una máquina que no tiene nada, y por eso no miente: arranca vacía, clona el repositorio, instala solo lo que el proyecto declara y ejecuta lo que se le pida. Cualquier cosa que funcione en el portátil y no ahí es una dependencia que no estaba escrita.
Esa es la utilidad real y llega antes que la de publicar solo. Un proyecto que pasa por una máquina limpia una vez al día no acumula el conocimiento oculto que hace que un despliegue dependa de una persona concreta, que en un equipo español de tres personas es exactamente lo que ocurre.
Una imagen de contenedor lleva las dependencias, el runtime y el código en un solo fichero, y es la forma de que esa máquina vacía y el servidor del balneario tengan lo mismo dentro. Lo que queda fuera de la imagen, y es donde vuelven los problemas, son los datos y los ficheros que sube la gente. Los contenedores tratan eso, y la máquina que lo ejecuta todo es la integración y entrega continuas.
Viernes por la tarde
Qué para cada capa, y qué entrega tal cual
Cuatro capas entre un cambio y un balneario cogiendo reservas por teléfono, y cada una es transparente justo para el fallo que caza la siguiente.
- Las pruebas+Lo que antes funcionaba y ahora no→Todo lo que nadie describió, y cualquier diferencia de entorno
- La construcción desde cero+La librería no declarada y la variable puesta en un perfil de shell→Código que está mal de una forma que compila perfecto
- El contenedor+Que el servidor y el portátil no se pongan de acuerdo sobre una versión→Un cambio equivocado, fielmente y por igual en todas partes
- La versión anterior guardada+Todo lo que las otras tres dejaron pasar, el tiempo que se tarde en notarlo→Nada, y es la capa que se borra cuando falta disco
El cierre es enterarse, y aquí no es una capa. Las cuatro dan por hecho que alguien se entera, y Bea se enteró porque llamó el balneario.
Qué para cada capa, y qué deja pasar
Las cuatro capas entre un cambio y un balneario cogiendo reservas por teléfono no son redundantes: cada una es transparente justo para el fallo que caza la siguiente. Las pruebas paran lo que antes funcionaba y ahora no, y dejan pasar todo lo que nadie describió. La construcción desde cero para la librería no declarada, y deja pasar el código que está mal y compila perfecto.
El contenedor para el desacuerdo de versiones entre el servidor y el portátil, y entrega fielmente el cambio equivocado a todas partes. La versión anterior guardada para todo lo que las otras tres dejaron pasar, y no deja pasar nada, y es la capa que se borra la primera cuando falta disco.
Lo que no es una capa aquí es enterarse. Las cuatro dan por hecho que alguien se entera, y Bea se enteró porque llamó el balneario. El testing es la capa de la que sale la evidencia, y la que decide cuánto de todo esto se puede automatizar sin miedo.
Dónde se para quien viene del módulo
El módulo de despliegue se aprueba dejando un servidor configurado: Apache o Tomcat instalado, un virtual host escrito, la aplicación respondiendo. Es una foto de un momento, y se corrige mirando esa foto.
Lo que no entra en la foto es la segunda vez. Un despliegue no es una instalación, es algo que ocurre cuarenta veces al año, y lo que decide si duele es si la número cuarenta y uno se puede deshacer en un minuto. Buena parte de la web pequeña española vive en alojamiento compartido con panel y FTP, donde ese minuto no existe por defecto y hay que fabricarlo con la carpeta con fecha y el enlace simbólico.
Y hay una capa más que aquí llega antes de lo que la gente espera: en cuanto el cliente es una administración pública, el marco de referencia no son las certificaciones estadounidenses sino el Esquema Nacional de Seguridad, y eso condiciona dónde se aloja y qué se registra de cada despliegue.
Qué abrir en 2026, y por dónde entrar
Git se escribió en 2005, sustituyó a Subversion y a copiar una carpeta antes de tocar nada, y es gratis y de código abierto. Es la rueda que hay que coger primero porque las otras dos se apoyan en ella.
GitHub Actions es gratis en repositorios públicos y sustituyó a Jenkins para casi cualquier equipo pequeño, que es lo que sigue dando por supuesto cualquier tutorial anterior a 2019. El fallo típico es empezar por aquí: automatizar un despliegue que nadie sabía deshacer solo consigue que el error salga más rápido.
Docker apareció en 2013, es gratis para uso individual, y sustituyó a una lista escrita de pasos de instalación que nadie mantenía al día. Con esos tres y una carpeta con fecha en el servidor, el balneario de Ourense habría vuelto atrás el viernes a las siete y cinco.
La pregunta que queda abierta no es de despliegue: si el cambio que salió mal había tocado la estructura de las tablas, volver el código atrás no vuelve atrás los datos, y eso es lo primero que hay que aprender de las bases de datos. Lo que se despliega suele ser una aplicación del desarrollo web, y las dependencias que la máquina vacía instala son las de los lenguajes de programación.