Un manual comunitario sobre cómo los equipos reales entregan software.
Cada guía nace de una base de código real, validada por los maintainers que la enviaron, y se revisa cuando la realidad la contradice. Explora por tema.
Trunk-based, release branches, GitFlow - cuándo cada una vale la pena y las señales de que se te quedó pequeña.
Plantillas que sí se revisan, límites de tamaño que se respetan y cómo dejar un comentario que no ponga a nadie a la defensiva.
Contract tests, higiene de snapshots, matar CI inestable - patrones que aguantan con 50 ingenieros y con 50.000.
Semver en la práctica, changelogs que tus usuarios sí leen y simulacros de rollback que no necesitan un héroe.
Onboarding de nuevos contribuidores, RFCs que se entregan, gobernanza que escala sin ahogar el ritmo.
Post-mortems, rediseños y las historias de "deberíamos haber hecho esto 6 meses antes" que vale la pena leer.
Cuándo hacer bump major, minor o patch — y por qué SemVer es la herramienta equivocada para servicios. Con un formato de changelog que la gente sí lee.
Un equipo en un monorepo debate sobre hacer un bump de versión major. El cambio de API en cuestión es en una librería interna — usada por exactamente dos servicios, ambos del mismo equipo, ambos desplegados simultáneamente. El "consumidor" del cambio breaking son ellos mismos, esta tarde. La mitad del equipo dice "es un cambio breaking, eso es major, esa es la regla". La otra mitad dice "controlamos ambos lados, ¿por qué gastar una versión…
Sin guardianes. El mismo flujo que documentamos es el que usamos para escribir la documentación.
Si un patrón solo funciona en un stack, lo decimos. La mayoría aquí son más viejos que tu build tool.
Cada guía está fechada, versionada y se revisa. Retiramos a propósito los patrones que no envejecieron bien.
¿Encontraste un patrón que funcionó? ¿No estás de acuerdo con una guía? Abre un pull request, cuenta tu historia o solo añade una frase - así como trabajamos es como crece la documentación.