Despliegue: llevar el código a personas reales

Tu proyecto funciona. Se lo has enseñado a tus amigos en tu portátil, y funcionaba. Así que lo subes a un servidor, repartes el enlace, y se rompe al instante. El mismo código, los mismos archivos, todo igual. Lo único que ha cambiado es dónde se ejecuta. Ese momento tiene nombre, y el nombre es un chiste que la gente cuenta porque le pasa a todo el mundo: «pero en mi máquina funcionaba».

Se rompió porque tu portátil nunca estaba ejecutando solo tu código. También estaba aportando cien cosas de las que tu código depende en silencio: en qué puerto escuchar, dónde vive la base de datos, qué claves de API usar, qué versión del lenguaje hay instalada, qué archivos dan la casualidad de estar en esa carpeta. Nada de eso está en tu código, así que nada de eso viajó con tu código. Los sitios donde se ejecuta tu código se llaman entornos. Lo normal son tres: tu portátil, donde construyes y donde romper cosas no pasa nada; staging, una copia de la configuración real donde el equipo comprueba antes de que los usuarios vean nada; y producción, lo de verdad, con personas reales y dinero real. El mismo programa corre en los tres, y los valores son distintos en cada uno.

env:         laptop     staging    production
-----------  ---------  ---------  -----------
PORT         3000       8080       80
API_KEY      test       test       live
LOG_LEVEL    debug      info       warn

Antes de que el código pueda correr en un servidor, muchas veces hay que convertirlo en algo que el servidor pueda ejecutar: eso es la compilación. Compilar TypeScript a JavaScript, empaquetar muchos archivos en uno, reducir imágenes, producir una carpeta lista para arrancar. La distinción importa porque son dos pasos distintos con dos formas distintas de fallar. Un fallo de compilación ocurre en tu máquina, antes de desplegar nada, y es barato: todavía no ha llegado nada a los usuarios. Un fallo en tiempo de ejecución ocurre en el servidor, con usuarios mirando. Quieres que el mayor número posible de fallos sean fallos de compilación.

src/cart.ts       ---> dist/app.js
package.json      ---> node_modules/

ts ---> js

$ npm start
PORT=80 listening

Así que la versión honesta de «funciona en mi máquina» es una lista de comprobación, y es corta. ¿La configuración aquí es distinta: puerto, base de datos, claves? ¿Falta una dependencia o tiene otra versión? ¿El archivo que el código espera está de verdad en esta máquina, con las mismas mayúsculas y minúsculas? ¿Tiene esta máquina permiso para usar la red, la carpeta, el puerto? Y la que todo el mundo olvida: ¿sigue funcionando ahora, a esta hora, con esta cantidad de tráfico? Ninguna de esas preguntas va de lo listo que es tu código. Van del mundo en el que ha aterrizado.

Cada despliegue es también una pequeña apuesta. Así que antes de desplegar, decide cómo vas a volver. Ese plan tiene nombre: una reversión. Significa volver a la versión anterior que se sabía que funcionaba, normalmente con un comando, y debería tardar segundos, no horas. El sentido de una reversión no es arreglar nada: es parar el daño mientras averiguas qué ha ido mal. Fíjate en lo que exige. La versión anterior tiene que seguir existiendo y seguir funcionando. Los datos tienen que sobrevivir al viaje de vuelta, y esa es la parte difícil: si la versión nueva ya escribió un tipo nuevo de registro en la base de datos, la vieja tiene que tolerarlo. Y tienes que enterarte de que está roto, lo que significa mirar qué pasa justo después del despliegue en vez de suponerlo.