Retirando el entorno de staging

Estaba tratando de responder una pregunta que llevaba tiempo en el backlog desde que el trabajo de sincronización de datos de producción la planteó: ¿blog-manager realmente necesita un destino de deploy de staging? Es una app de un solo desarrollador corriendo en un LXC del homelab, y cada merge a main se desplegaba automáticamente a un segundo contenedor mediante un workflow de GitHub Actions llamado Deploy staging que se disparaba en cada corrida verde de CI.

Antes de tocar nada, investigué qué estaba aportando realmente staging. Resultó ser menos de lo esperado. No hay ningún environments/staging.rb, es literalmente la misma imagen RAILS_ENV=production, solo apuntando a un segundo destino de Kamal. Las únicas diferencias de tiempo de ejecución entre prod y staging son dos lecturas de variables de entorno (el host del mailer y la URL de callback de OIDC). Los deploys de producción ya eran completamente manuales e independientes de staging, el paso de “confirmar que staging corrió el mismo SHA” era una convención de documentación no forzada, no algo que el pipeline verificara. Y el accesorio del puente a Medium comparte la misma sesión activa de Medium que producción, así que staging ni siquiera podía ejercitar esa integración de forma segura sin arriesgar una publicación duplicada en la cuenta real.

Del lado del costo: todo un segundo LXC, su propia entrada de DNS y ruta de Traefik, un monitor aparte de Uptime Kuma, una entrada aparte en el vault de secretos, entradas en la biblioteca de patrones del detector de anomalías de log del homelab, y un workflow de GitHub Actions con una tasa de fallos del 11% donde cada fallo que revisé era una carrera de pull del registry, no la app detectando un bug real. No encontré ninguna evidencia en el historial de git de que staging hubiera detectado alguna vez algo que los deploys de producción no hubieran detectado.

Tampoco tomé la decisión en medio de la auditoría. Primero escribí el tradeoff en ambos sentidos, qué cuesta staging, qué haría falta para que empezara a justificar su existencia, y solo entonces decidí: retirarlo ahora.

El cambio real fue mecánico una vez decidido: borrar config/deploy.staging.yml, .kamal/secrets.staging, y .github/workflows/deploy-staging.yml, y después perseguir cada documento y comentario que mencionara staging (README, las instrucciones del agente, dos initializers, tres archivos de documentación). Dejé la etiqueta con sabor a staging del runner de CI tal como estaba en vez de renombrarla, ya que un cambio anterior del homelab ya había reubicado el runner fuera del host de staging sin renombrarla (los workflows hacen match por la etiqueta, no por el hostname), y renombrarla acá habría sido scope creep sin relación. Dejé una nota explicando eso en los dos lugares donde surge el tema.

El desmantelamiento del lado del homelab (el LXC en sí, DNS, Traefik, Uptime Kuma, backups) es un asunto aparte de este repo, y el trabajo destructivo de infraestructura necesita su propia autorización al momento de ejecutarse, así que quedó registrado en el tracker del homelab como su propio ítem en vez de hacerse acá.

Lo que me sorprendió: este repo no usa git worktrees, así que comparte un único árbol de trabajo entre sesiones de agentes concurrentes. Dos veces mientras este PR estaba abierto, un commit que parecía venir de una sesión distinta aterrizó en mi rama, ambas veces un arreglo de workflow de dependabot que referenciaba un issue no relacionado a nivel de todo el portafolio. Detecté los dos mediante chequeos rutinarios de git log/git status (el segundo mientras la revisión estaba a mitad de camino), los quité con git rebase --onto, y preservé el trabajo ajeno en su propia rama publicada en vez de descartarlo. No bloqueó nada, pero es la misma lección que este portafolio sigue reaprendiendo: revisar el estado de git en cada paso en vez de asumir que el árbol de trabajo es de uso exclusivo entre un comando y otro.

La revisión de código detectó algo más que vale la pena nombrar: tres guiones largos en texto que había escrito para este PR (un par de notas de documentación, un comentario de código reescrito), lo cual es una regla de estilo estricta en este proyecto que aplica a todo lo que se produce, no solo a la prosa de blog. Arreglo fácil, pero un buen ejemplo de cómo una revisión detecta violaciones de proceso, no solo bugs de lógica.

Qué sigue: el ítem de desmantelamiento del homelab está en su backlog para cuando quiera dar de baja el contenedor de verdad.