Every Monday I Ship to Nobody

Todos los lunes por la noche corro un release a producción. Uno reciente promovió dieciocho servicios, cuatro de ellos llegando a producción por primera vez en su vida. Antes, un congelamiento de código. Antes de eso, un sábado entero recorriendo un plan de pruebas escrito. Esa misma noche, un runbook con un orden explícito y una lista de unas treinta y cinco casillas.

La plataforma que esto despliega todavía no tiene clientes pagando en producción.

Escrito así suena a un hombre ensayando servicio de mesas en un restaurante vacío. Quiero defender que no lo es — y ser honesto sobre lo que cuesta.

Qué es el tren, concretamente

Los releases salen semanalmente, los lunes por la noche, y cada uno es un estado con letra: todo lo que ya estaba vivo, más un conjunto específico de cambios, desplegado en conjunto. "¿Esta funcionalidad está en producción?" tiene una única respuesta autoritativa, y no es un git log.

Unos días antes, el trabajo se congela. El sábado es la puerta de pruebas: un plan escrito, personas reales, dispositivos reales, recorrido por un humano. El lunes por la noche el runbook se ejecuta en un orden fijo, y todo lo riesgoso sale apagado.

Cuatro documentos, una cadencia, y nada de esto es ceremonia automatizada. Son decisiones escritas antes de la noche en que hacen falta.

El congelamiento no es disciplina, es aritmética

Esta es la parte que no es una preferencia.

No promuevo funcionalidades. Promuevo ramas. Cuando un servicio sale, todo lo que se haya integrado a su rama de desarrollo se va con él — no la pieza en la que yo estaba pensando, sino todo.

Ese único hecho mecánico es de donde sale el congelamiento. Cualquier cosa integrada después del corte se sube al tren, la haya querido o no, probada o no. Sin congelamiento, la pregunta "¿qué hay en este release?" no tiene respuesta estable justo en el momento en que más la necesito. Con congelamiento, el conjunto queda cerrado antes de probarse, y lo que probé el sábado es lo que sale el lunes.

Mucha gente describe los congelamientos como cautela. El mío es contabilidad.

Desplegar y liberar son dos verbos distintos

La costumbre más útil que he adoptado es separar el código está corriendo en producción de el comportamiento está encendido.

Todo lo que tiene radio de impacto real sale a oscuras: desplegado, conectado e inerte. Encenderlo pasa a ser una decisión aparte, otro día, tomada deliberadamente, con el despliegue ya demostrado. Si se porta mal, el arreglo es un cambio de configuración y no un rollback a las once de la noche.

Esto cuesta casi nada de construir y convierte la categoría más aterradora de release en dos categorías ordinarias.

La pregunta que no supe responder

La razón por la que todo esto existe es vergonzosa, así que ahí va.

Alguien me preguntó si cierta funcionalidad estaba viva en producción, y no pude responder con confianza. Sabía que estaba integrada. Estaba bastante seguro de que se había desplegado. Si estaba realmente corriendo y verificada — habría tenido que ir a mirar.

Integrado, desplegado y verificado son tres estados distintos, y yo los venía colapsando en una sola palabra: "listo". Así es como terminas asumiendo que una protección está encendida cuando no lo está, o reconstruyendo algo que ya se había desplegado.

Así que ahora hay un registro, y una funcionalidad solo está viva cuando se comprobó contra producción — no integrada, no desplegada, comprobada — con una nota de cómo. "Construido pero no desplegado" y "solo en dev" son estados de primera clase, con nombre propio, porque fingir que estaban vivos es exactamente de donde vino el dolor.

Por qué antes de los clientes, y no después

La objeción obvia es que esto es exagerado para un producto por el que todavía nadie paga, y la objeción tiene peso real. Respondería dos cosas.

La primera es que un proceso que ya corriste tres veces es aburrido, y aburrido es el único estado útil para un proceso la noche en que por fin importa. Nadie aprende un procedimiento de release durante su primer incidente de verdad. Lo aprendes ahora, mientras el costo de equivocarte es un redespliegue y una hora de tu noche.

La segunda es que ya está rindiendo. El congelamiento ha atrapado cambios que se habrían subido al tren sin probar. El recorrido del sábado ha encontrado cosas que pasaron todas las verificaciones automáticas. El registro me ha corregido — más de una vez — cuando estaba por construir algo que ya existía, o por confiar en algo que en realidad no estaba encendido.

Ninguna de esas cosas necesitaba un cliente para valer la pena.

Lo que cuesta

Es más lento, y quiero decirlo sin rodeos en vez de fingir que la disciplina es gratis.

Hay trabajo terminado que se queda en una rama de desarrollo hasta una semana antes de que alguien pueda usarlo. Eso es genuinamente frustrante un miércoles, cuando algo pequeño y obviamente seguro está listo y simplemente... espera. He pensado en abrir una excepción para cambios chicos, y no lo he hecho, porque "obviamente seguro" es precisamente el juicio del que querría que un proceso me protegiera en un mal día.

También hay una cantidad real de escritura. El runbook y la lista toman una tarde, cada semana, y ningún usuario los va a ver jamás.

Pago las dos cosas a propósito. No porque haga los releases emocionantes, sino porque los hace aburridos, deliberadamente, antes de la semana en que voy a necesitar con urgencia que lo sean.