# Rails sostenible (X): proceso sostenible, operaciones y liderazgo

*Décima y última entrega de la serie **[Rails sostenible](/search?tag=rails-sostenible)**, sobre **Sustainable Web Development with Ruby on Rails** de David Bryant Copeland. Tiempo de lectura estimado: 14 minutos.*

Llegamos al final del recorrido. Tras nueve entregas bajando hasta el detalle de cada capa de Rails, Copeland cierra subiendo de nuevo a la vista de pájaro: el **proceso**, las **operaciones**, las **decisiones de arquitectura macro** y, por encima de todo, el **liderazgo técnico**. Porque ninguna técnica de las que hemos visto sobrevive si nadie en el equipo defiende la sostenibilidad como valor.

## Usa la integración continua para desplegar

El proceso sostenible empieza por desplegar a menudo y sin drama. Copeland defiende la **integración continua como vía de despliegue**: si cada cambio pasa por la puerta de calidad —ese [`bin/ci` de la segunda entrega](/post/rails-sostenible-ii-arrancar-con-buen-pie)— y de ahí va a producción de forma automatizada, los despliegues se vuelven pequeños, frecuentes y aburridos. Lo contrario —acumular cambios durante semanas y desplegar un viernes con miedo— es la insostenibilidad operativa por excelencia. Despliegues pequeños, problemas pequeños.

## Actualiza dependencias con frecuencia

Una de las fuentes de carrying cost más traicioneras: las dependencias desactualizadas. La tentación es no tocarlas ("si funciona, no lo toques"), pero eso solo difiere el dolor y lo agranda. Copeland recomienda **actualizaciones frecuentes y pequeñas** —con herramientas tipo Dependabot— en vez del *big-bang upgrade* cada tres años, ese proyecto infernal de saltar cinco versiones mayores de golpe mientras todo arde.

> Una dependencia desactualizada es una deuda que acumula intereses en silencio: cuanto más tardes en pagarla, más cara y más arriesgada se vuelve.

## Generadores y plantillas antes que documentación

Aquí hay una idea que me encanta. La documentación de convenciones ("cómo creamos un servicio nuevo", "cómo estructuramos un controlador") **se desincroniza**: nadie la actualiza y miente al poco tiempo. Copeland propone **codificar las convenciones en generadores y plantillas** en lugar de en un wiki. Si tienes un generador que crea un servicio con la estructura correcta, la convención se aplica sola y no puede mentir, porque *es* código ejecutable.

Y va un paso más allá: **RubyGems y Railties pueden distribuir configuración**. Si gestionas varias aplicaciones Rails, puedes empaquetar la configuración común y las convenciones compartidas en una gema o un railtie, en vez de copiar y pegar. La convención viaja como dependencia versionada.

![Centro de datos con servidores en producción](fig-01.webp)

## Operaciones: por qué importa la observabilidad

El capítulo de operaciones arranca con una verdad incómoda: **un sistema que no puedes observar es un sistema que no puedes mantener**. La observabilidad —saber qué está haciendo tu app en producción y por qué— no es un lujo, es un requisito de sostenibilidad. Sin ella, cada incidente es una sesión de adivinación.

Copeland desgrana varias piezas:

- **Monitoriza resultados de negocio, no solo CPU.** Que el servidor esté al 12% de CPU no te dice nada si los pedidos han dejado de completarse. Las métricas que importan son las del negocio: registros, ventas, errores de pago. Una caída de pedidos a cero es una alarma; una de CPU, una curiosidad.
- **El logging es poderoso.** Aquí cierra el círculo con [el lograge de la segunda entrega](/post/rails-sostenible-ii-arrancar-con-buen-pie): logs estructurados, en una línea por petición, son la herramienta de diagnóstico más barata y potente que tienes.
- **Gestiona las excepciones no controladas.** Necesitas un sistema de seguimiento de errores (Sentry, Honeybadger o similar) que capture, agrupe y notifique las excepciones. Un error que nadie ve es un error que nadie arregla.
- **Mide el rendimiento.** No optimices a ciegas: mide dónde se va el tiempo (APM) y actúa sobre datos.

### Los despliegues a producción son para profesionales… aunque ese seas tú

Una frase con doble filo de Copeland: producción merece respeto profesional **aunque el equipo seas tú solo**. No significa montar un Kubernetes para un proyecto de fin de semana; significa tratar el despliegue, los backups, los secretos y la monitorización con seriedad proporcional a lo que la app importa. Ser una sola persona no es excusa para operar con descuido; es razón de más para automatizar y dejarlo todo documentado-en-código.

### Gestiona secretos, claves y contraseñas

Cierra el capítulo con la higiene de **secretos**: credenciales fuera del repositorio, gestionadas por el entorno o por un gestor de secretos, rotables, nunca hardcodeadas ni en logs. Enlaza directo con el `ENV.fetch` y el dotenv de la segunda entrega: los secretos entran por el entorno, jamás por el código.

## Monolitos, microservicios y bases de datos compartidas

En los apéndices, Copeland se moja en el debate arquitectónico de la década, y su postura es deliciosamente a contracorriente:

- **El monolito tiene mala fama inmerecida.** Un monolito bien organizado —con su seam, su lógica de negocio separada, sus capas limpias, todo lo que hemos visto en esta serie— es **más sostenible** que un enjambre de microservicios para la inmensa mayoría de equipos. El monolito modular es la opción por defecto sensata.
- **Los microservicios no son la panacea.** Resuelven problemas reales (escalado independiente, equipos autónomos a gran escala) a cambio de un carrying cost brutal: latencia de red, consistencia distribuida, observabilidad multiplicada, despliegues coordinados. Adoptarlos por moda, sin tener esos problemas, es comprarse todos los costes sin ninguno de los beneficios.
- **Compartir una base de datos es viable.** Otra herejía pragmática: en muchos contextos, compartir base de datos entre servicios —tratado con cuidado— es perfectamente razonable, frente al dogma de "cada servicio su base de datos".

Todo esto es coherencia pura con el carrying cost que abrió [la primera entrega](/post/rails-sostenible-i-sostenibilidad-y-arquitectura): la pregunta nunca es "¿qué es más moderno?", sino "¿qué nos costará menos mantener vivo durante años?".

![Logo de Ruby on Rails](fig-02.webp)

## El liderazgo técnico es crítico

Y el libro termina donde menos te esperas en un manual técnico: en las **personas**. Copeland sostiene que todas estas técnicas —el seam, las constraints, los servicios stateless, el `bin/ci`— no se sostienen solas. Necesitan que alguien las defienda en el día a día, sobre todo cuando hay presión por entregar y la tentación de tomar el atajo insostenible aprieta.

Su tesis sobre liderazgo tiene tres patas:

- **El liderazgo va de valores compartidos.** Un equipo sostenible es uno donde la sostenibilidad es un valor común, no la cruzada solitaria de una persona. El trabajo del líder técnico es difundir ese valor hasta que se vuelva cultura.
- **Los líderes pueden rendir cuentas.** El liderazgo conlleva responsabilidad: tomar decisiones y responder por ellas.
- **La responsabilidad puede ser implícita.** No hace falta un título de "líder" para liderar. Cualquiera que defienda los valores correctos y arrastre con su ejemplo está ejerciendo liderazgo técnico, tenga el cargo que tenga.

Es un cierre que reencuadra todo el libro: la sostenibilidad no es, en el fondo, una propiedad del código. Es una propiedad del **equipo** que lo cuida. El código sostenible es el residuo que deja un equipo que comparte los valores correctos.

## Mi versión

Después de diez entregas, lo que más me llevo no es una técnica concreta —aunque las constraints en base de datos y el seam de negocio me han cambiado la forma de programar—, sino el **vocabulario** para argumentar. "Carrying cost", "opportunity cost", "esto es una clase frontera, debería delegar", "esto es negocio, va al seam". Tener las palabras te permite defender las decisiones sostenibles en una reunión sin sonar a perfeccionista o a vago.

Lo del liderazgo me resuena especialmente. He estado en equipos donde yo era el pesado de las foreign keys y el `bin/ci`, y es agotador remar solo. La diferencia entre que esas prácticas cuajen o se evaporen nunca fue técnica: fue si conseguía que el resto del equipo las hiciera *suyas*. Copeland tiene razón en que ese es el trabajo de verdad, y el más difícil.

¿Estoy de acuerdo con todo el libro? Casi. Soy algo menos beligerante con los presenters y con `to_json` de lo que él es, y creo que hay contextos donde los microservicios sí compensan antes de lo que sugiere. Pero el marco general —optimizar para el coste de mantenimiento a largo plazo, darle casa a la lógica de negocio, abrazar las convenciones de Rails y minimizar todo lo que haya que mantener despierto— me parece de lo más sólido y atemporal que se ha escrito sobre Rails.

## Fin de la serie

Y hasta aquí el recorrido por **Sustainable Web Development with Ruby on Rails**. Diez entregas para un libro que, irónicamente, predica hacer menos: menos JavaScript, menos dependencias, menos magia, menos lógica en los modelos. Menos cosas que mantener vivas. Si tuviera que resumirlo en una frase sería esta: **el código más sostenible es el que no tienes que escribir, y el segundo más sostenible es el aburrido, predecible y bien colocado.**

Si quieres releer la serie completa, tienes todas las entregas bajo el tag **[Rails sostenible](/search?tag=rails-sostenible)**. Y si te ha picado el gusanillo, el libro de Copeland merece muchísimo la pena: esto ha sido un mapa, pero el territorio tiene mucho más detalle, matiz y código real del que cabe en diez posts. Gracias por acompañarme hasta el final.