Édison Salcedo publicaba la página de inventario de una ferretería de Barranquilla arrastrando una carpeta en FileZilla hasta el hospedaje compartido, y así funcionó ocho meses. Un viernes en la tarde subió una versión que no sabía leer el archivo de existencias de la semana anterior, y descubrió que la versión que sí servía ya no existía en ninguna parte. La había sobrescrito él mismo. La ferretería contó tornillos a mano hasta el lunes.
Nada en esa historia trata de escribir código, y todo en ella es este tema. La puesta en producción es el conjunto de prácticas que vuelven un cambio reversible, repetible y revisable por alguien que no eres tú, y es la materia que el resumen del pilar llama la que nadie avisó que fuera una materia.
Reversible antes que nada
La propiedad que le habría salvado el fin de semana a Édison no son las pruebas y no son los contenedores. Es que un rollback es un despliegue de la versión anterior, y tiene que costar lo mismo. Si volver es un procedimiento distinto de avanzar, se va a improvisar en el peor momento posible y lo va a improvisar la persona más asustada que haya a la mano. Un despliegue bien hecho es un cambio de interruptor entre dos versiones que siguen existiendo las dos, y la anterior se conserva justamente para que la respuesta a un mal viernes sea un comando y no una noche.
La misma idea, una capa más abajo, es por qué se guarda una historia. Hay dos comandos que deshacen y no son intercambiables: git revert crea un commit nuevo; git reset mueve la rama. Revert es el que resulta seguro sobre cualquier cosa que otra persona ya tenga, porque agrega un cambio que deshace un cambio y deja el registro de los dos. Reset reescribe a dónde apunta la rama, que es la herramienta correcta sobre trabajo que nadie ha visto y una manera de destruirle la tarde a una colega sobre trabajo que sí vio. Esa distinción es la mitad práctica de el control de versiones.
Por qué subir por FTP no es una manera chiquita de desplegar
Aquí conviene decir con nombre y apellido cómo se publica de verdad en este mercado, porque la edición en inglés da por hecha otra cosa. La mayoría de los sitios chicos de México y Colombia viven en un hospedaje compartido con panel de control, contratado en pesos y pagado por año adelantado, y se actualizan arrastrando archivos con un cliente de FTP. Es barato, funciona y no es motivo de vergüenza.
Tiene una sola propiedad que importa, y es la que dejó a Édison sin salida. Subir por FTP sobrescribe, así que no queda versión anterior a la cual volver. No es que el respaldo estuviera mal hecho: el mecanismo no tiene idea de que existan versiones. Escribe encima, archivo por archivo, y a media subida el sitio está mitad viejo y mitad nuevo, que es un estado que nadie eligió y que los clientes sí alcanzan a ver.
El arreglo no cuesta dinero y no obliga a abandonar el hospedaje que ya se pagó por doce meses. Se sube a una carpeta nueva y se cambia de carpeta al final, con lo cual volver es exactamente el mismo trabajo que salir:
- subir todo a
tienda-nueva, sin tocar lo que está en línea - renombrar
tiendaatienda-2026-09-05 - renombrar
tienda-nuevaatienda - para volver, dos renombradas más, y la versión buena sigue en disco
Son dos pasos de más y compran la simetría entera. El cambio ocurre en el instante del renombrado en vez de durar los cuatro minutos de la subida, y la versión anterior queda ahí hasta que alguien decida borrarla. Quien pueda salir del FTP encontrará que las plataformas que despliegan un repositorio al hacer push traen esto de fábrica, y ese es el asunto de el despliegue.
La máquina que no tiene nada
El despliegue de Édison funcionaba porque su portátil había acumulado ocho meses de ajustes chicos: una biblioteca instalada alguna vez, una variable de entorno puesta en el perfil de la terminal, una carpeta que resultó estar ahí. Nada de eso estaba anotado, y nada de eso llegó al hospedaje salvo cuando él lo puso a mano.
El pipeline corre en una máquina que no tiene nada, y por eso es honesto. Un servidor de compilación arranca de una caja vacía cada vez, así que todo lo que el proyecto necesite tiene que estar declarado en algún archivo que pueda registrarlo. Ese es el valor real de CI y CD, y vale más que la automatización: es una auditoría continua y sin misericordia de si el proyecto lo puede construir alguien que no es su autor. En un mercado donde el trabajo remoto se consigue justamente demostrando eso, la auditoría tiene un segundo lector.
El mismo instinto, un paso más allá, produce el contenedor. Una imagen de contenedor es las dependencias, el runtime y el código en un archivo, construida una vez y ejecutada idéntica donde caiga. Elimina la clase entera de falla en que el servidor tiene otra versión de algo que el portátil, que es para lo que sirven los contenedores. Lo que no elimina es la obligación de saber qué entró en la imagen: un contenedor construido sobre una base sin fijar es la misma dependencia sin declarar de antes, sellada en una caja y despachada con más confianza.
Viernes en la tarde
Qué detiene cada capa, y qué deja pasar de largo
Cuatro capas entre un cambio y una ferretería contando tornillos a mano, y cada una es transparente a la falla que atrapa la siguiente.
- Las pruebas+Comportamiento que antes servía y ahora no→Todo lo que nadie pensó en describir, y cada diferencia de entorno
- La construcción desde cero+La biblioteca sin declarar y la variable puesta en el perfil de la terminal→Código equivocado de una manera que compila perfecto
- El contenedor+Que el servidor y el portátil no coincidan en una versión→Un mal cambio, fielmente e idéntico, en todas partes
- La versión anterior conservada+Todo lo que las otras tres dejaron pasar, mientras alguien se da cuenta→Nada, y es la capa que se borra para ahorrar disco
El sello es darse cuenta, y aquí no es una capa. Las cuatro dan por hecho que alguien se entera, y Édison se enteró porque le timbró la ferretería.
La evidencia, el orden y el atasco
El argumento a favor de las pruebas que convence a la gente no es que atrapan errores, porque quien empieza observa con razón que atrapan sobre todo los errores en los que el autor ya estaba pensando. El argumento que se sostiene es que las pruebas son lo que vuelve seguro hacer un cambio. Édison puede reescribir el lector de existencias un martes con exactamente la confianza que le dé cuánto de su comportamiento esté anotado como algo que una máquina revisa.
Por eso las pruebas están planteadas alrededor de sobrevivir y no de tener razón. La primera prueba útil no es una prueba unitaria. Es la que corre la cosa completa contra el archivo de existencias de la semana pasada y revisa el total, porque esa fue la falla que Édison de verdad tuvo, y porque una prueba escrita contra una entrada real del pasado no necesita ninguna teoría sobre cuáles son las unidades.
El orden que sirve es control de versiones, después una manera de correr la cosa desde cero, después pruebas, después automatizar la salida. Casi todo el mundo hace el cuarto primero, porque es el que trae las herramientas interesantes, y termina con una automatización que despliega algo que nadie puede revertir. Y el atasco es el que nombra el resumen del pilar: llega justo después del primer programa que sí funciona, la sintaxis tenía sentido, la terminal no, y alguien concluye que es malo para programar. No lo es. La evidencia concreta es que nada de la dificultad tiene que ver con el lenguaje que acaba de aprender, y por eso esto vive adentro de programación y no al lado.
Qué abrir en 2026, y lo que cuesta desde acá
Git no es opcional y no lo es desde que le tomó el lugar a Subversion durante los años diez. Es gratis, y la hora de mayor rendimiento de este tema es la que se pasa entendiendo que un commit es una fotografía y una rama es un apuntador a una: después de eso, casi toda la confusión se resuelve sola.
GitHub Actions es el pipeline por omisión para lo que ya vive en GitHub, es gratis para repositorios públicos y reemplazó a Jenkins en la mayoría de los equipos chicos, que es lo que siguen suponiendo los tutoriales anteriores a 2019 más o menos. Docker sigue siendo la manera en que se construyen los contenedores y es gratis para uso individual.
La cuenta desde acá es corta y vale la pena tenerla junta. Git, Docker y un repositorio privado en GitHub o GitLab no cobran nada. Los minutos de pipeline son gratis mientras el repositorio sea público y se cobran en dólares cuando es privado y se pasa del plan incluido, que es el primer renglón en dólares que aparece en este tema. El hospedaje compartido se sigue pagando en pesos, y las plataformas que despliegan al hacer push tienen un plan gratuito real que alcanza para un sitio de una ferretería. Nada de esto está bloqueado y todo pide tarjeta solo cuando se pasa del plan gratuito.
Un asistente de código escribe de inmediato un archivo de pipeline pasable y se equivoca con toda confianza en las credenciales y los permisos, que es justo la parte donde equivocarse sale caro en vez de molesto. Lo que nada de esto cubre es qué pasa después del despliegue, cuando la cosa está corriendo y alguien tiene que darse cuenta de que se detuvo. Las dos preguntas de al lado son por qué una página se siente lenta, que vive en el desarrollo web, y qué pasa con la información cuando el servidor se cae a media escritura, que vive en las bases de datos. La que va debajo de las tres es los fundamentos de programación.