La entrega empieza el primer día

Imaginamos la entrega como una ceremonia de fin de proyecto: algunas reuniones, un documento de cien páginas escrito con prisa, un archivo de repositorios. Luego el siguiente equipo descubre que el documento describe un sistema que ya no existe, que la CI lleva cuatro meses en rojo y que nadie sabe dónde vive el certificado que caduca el martes.

Una entrega que funciona no es un evento: es una propiedad del proyecto, mantenida desde el primer día. La pregunta guía es simple: si el equipo cambiara mañana, ¿qué debería estar escrito hoy? Todo lo que sigue se deriva de esa pregunta.

Lo que realmente se transmite

Un software no se reduce a su código fuente. Lo que se transmite es la capacidad de operarlo, y cabe en cinco inventarios:

el runbook: cómo desplegar, restaurar, diagnosticar las averías conocidas, con los comandos exactos;
el mapa de accesos: entornos, servicios de terceros, DNS, certificados y los secretos asociados, guardados en un cofre y no en la memoria de una persona;
las decisiones: un diario de decisiones de arquitectura cortas y fechadas, que explica los porqués que el código no dice;
la deuda asumida: la lista honesta de lo frágil, lo rodeado y lo temporal, porque la deuda oculta es la que cuesta;
el calendario: caducidades de certificados y dominios, fines de soporte de versiones mayores, renovaciones de licencias.

Si uno de estos inventarios no existe, la entrega lo descubrirá en el peor momento.

El entorno reproducible es la base

Toda la documentación del mundo no sustituye a un entorno que se reconstruye con un comando. Infraestructura descrita como código, versiones fijadas con lockfiles comiteados, datos de desarrollo generados o anonimizados, y una CI que permanece verde: la CI verde es el verdadero contrato de entrega, la prueba ejecutable de que el sistema es el que se describe.

La prueba más honesta cuesta media jornada: que alguien que nunca tocó el proyecto lo instale siguiendo solo el README. Cada pregunta que haga es un agujero en la entrega, y cada agujero tapado beneficia de inmediato al equipo actual.

El mantenimiento es una cadencia, no una reacción

El mantenimiento fracasa cuando solo existe como reacción: una vulnerabilidad mediática, una avería, una subida de versión forzada. Funciona cuando tiene ritmo, y el ritmo cabe en tres niveles:

Las herramientas de automatización (Renovate, Dependabot) abren las propuestas; la CI decide; el equipo arbitra. Una actualización menor que espera seis meses se convierte de hecho en una mayor: los escalones pequeños subidos a menudo siempre ganan al gran escalón sufrido.

Dos reglas hacen sostenible la cadencia. Primero, un presupuesto: una ventana recurrente reservada en el calendario, innegociable, porque el mantenimiento que depende del «tiempo que sobre» no existe. Segundo, una política de versiones explícita: qué piezas siguen la última versión, cuáles siguen el soporte a largo plazo, y hasta cuándo.

Semver es una convención, no una promesa

El versionado semántico expresa la intención del autor, no la realidad de tu sistema. Una menor puede romper un comportamiento del que dependías sin saberlo. La confianza viene de otro lado: tests que cubren los usos reales del proyecto, un changelog leído antes de subir de versión, y actualizaciones en lotes pequeños, aislados, fáciles de revertir. Por eso funcionan las ventanas mensuales agrupadas: un lote razonable, probado junto, reversible junto.

Medir la salud, no solo la actividad

Un software entregado debe llevar sus instrumentos de a bordo: unos pocos indicadores de disponibilidad y de error que alertan a humanos, la lista de dependencias en fin de vida, la edad media del retraso de actualización. Pocos indicadores, pero mirados. Un panel que nadie abre es un artefacto de reunión, no un instrumento.

La prueba final: entregar las llaves en vacío

La mejor verificación de una entrega ocurre antes de que sea necesaria: un ejercicio en el que alguien externo al proyecto toma un incidente simulado, del diagnóstico al parche desplegado, usando solo lo documentado. El ejercicio cuesta un día y devuelve la única información que importa: ¿sobreviviría el sistema a la marcha de sus autores?

La checklist que aplicamos

Runbook operable: desplegar, restaurar, diagnosticar, con los comandos.
Accesos y secretos inventariados en un cofre, nunca en una cabeza.
Diario de decisiones de arquitectura al hilo del trabajo.
Deuda y rodeos documentados sin complacencia.
Entorno reconstruible con un comando, CI verde exigida.
Cadencia: seguridad en días, menores mensuales, mayores planificadas.
Propuestas de actualización automatizadas, arbitraje humano.
Calendario de caducidades: certificados, dominios, fines de soporte.
Ejercicio de entrega en vacío una vez al año.

Un software bien entregado no es un software perfecto. Es un software del que el siguiente equipo puede decir, al cabo de una semana: «sabemos dónde pisamos».