pinchito.es

La metodología TPP

Todo Para Producción v1

Crea rama, añade cambios, revisa, mezcla, crea tag, despliega.
Crea rama, añade cambios, revisa, mezcla, crea tag, despliega.

En esta sencilla metodología mantenemos sólo una rama activa, llámese master o main.

  • Sacamos una rama para hacer un arreglo (fix) o una nueva funcionalidad (feature).
  • Añadimos cambios (commits) a la rama.
  • Creamos una petición de mezcla (pull request o merge request).
  • Se van haciendo revisiones, añadiendo nuevos cambios y pasando los tests.
  • Cuando los cambios están revisados y los tests pasan, mezclamos los cambios (hacemos merge).
  • De nuevo se vuelven a pasar los tests en master.
  • Una vez que los tests pasan, desplegamos en producción.
  • A continuación etiquetamos la versión (tag).

¿De dónde viene TPP?

Durante mis muchos años como desarrollador me he encontrado con muchas “metodologías” de desarrollo. Una de las más perniciosas últimamente es git-flow, en la que se mantienen múltiples ramas para diferentes versiones. Más abajo la veremos más en detalle.

Me atrevo a proponer públicamente TPPv1: Todo Para Producción v1, o ToPaProd para amiguis y coleguis. Es una simplificación radical apta tanto para servicios online como para librerías.

TPP para librerías

En librerías (para npm, maven o similares) las etiquetas son particularmente importantes: identifican la versión concreta de la librería que se va a usar.

Seguiremos Semantic Versioning a rajatabla. Las versiones se etiquetarán como x.y.z, donde:

  • x: versión mayor (major). Rotura de compatibilidad ⇒ cambia x.
  • y: versión menor (minor). Cambio de funcionalidad ⇒ cambia y.
  • z: versión parche (patch). Arreglo de bugs ⇒ cambia z.

Cada versión debe ser inmutable: está prohibidísimo publicar dos versiones diferentes con la misma etiqueta.

En caso de fallo es trivial hacer una vuelta atrás a una versión anterior: sólo tenemos que apuntar a la última etiqueta válida.

TPP para sistemas online

Para sistemas online no necesitamos mantener múltiples versiones; basta con mantener una única versión viva que es la que mantenemos en master.

Una variante muy relevante en este caso consiste en mantener una rama adicional estable, donde mezclamos sólo el código que pasa las pruebas. Esta rama se puede llamar stable, prod o similar. Desplegaremos a producción siempre desde la rama estable.

Rama estable: tras mezclar en main, y sólo si pasan los tests, mezclamos en stable y desplegamos desde ahí.
Rama estable: tras mezclar en main, y sólo si pasan los tests, mezclamos en stable y desplegamos desde ahí.

En este caso las etiquetas o tags son menos importantes e incluso se pueden omitir. Para desplegar simplemente hacemos un git pull, y si es necesario lanzamos un build.

¡Los tests de master no pasan!

La rama master debe estar siempre desplegable. Si una vez mezclada una rama los tests fallan, lo trataremos como prioridad máxima, con casi la misma severidad que un fallo en producción. Es cierto que una versión que no pasa las pruebas ni se etiqueta ni se despliega, pero estaremos estorbando el trabajo de otros equipos que quieran mezclar a master.

Comparación con otras metodologías de desarrollo

El sentido de metodología se ha ido refinando; en este caso queremos decir “forma de organizar los cambios en el código”, lo que se corresponde con un workflow de desarrollo.

GitFlow

Esta metodología se liberó en 2010 y tuvo bastante éxito en múltiples ámbitos. Combina

  • ramas para cada funcionalidad o feature braches,
  • ramas para cada versión o release branches,
  • una rama master para versiones definitivas,
  • una rama develop para desarrollo,
  • y otra rama hotfixes para arreglos rápidos.
GitFlow: se mantienen múltiples ramas vivas.
GitFlow: se mantienen múltiples ramas vivas.

El esfuerzo para mantener tantísimas ramas sólo es posible para grandes organizaciones con un montón de recursos. El propio autor aclara al principio de la página:

Si tu equipo hace entrega continua de software, os sugeriría un workflow mucho más sencillo (como GitHub flow) en lugar de intentar meter git-flow con calzador en vuestro equipo.

GitHub Flow

Entonces, ¿es mejor GitHub Flow? En esta metodología propuesta por GitHub se trabaja de forma similar: se crea rama, se añaden cambios, se revisan y se mezclan.

GitHub Flow: cuando pasan los tests desplegamos el contenido de la rama, en lugar de main.
GitHub Flow: cuando pasan los tests desplegamos el contenido de la rama, en lugar de main.

Podemos ver en la guía gráfica la diferencia más radical con TPP: en GitHub Flow se hacen los despliegues desde la rama, antes de mezclar. Esto tiene el gran problema de que es posible que haya cambios en main que no se van a desplegar, ya que no están en la rama; hay que asegurarse de hacer un git pull origin main antes de desplegar y mezclar.

Me parece mucho más robusto desplegar desde main una vez mezclados los cambios.

Conclusiones

Si quieres desplegar código de forma sencilla, mantener sólo una versión, y optimizar los esfuerzos del equipo, ¡pásate a TPP!

Agradecimientos

Gracias a mis compañeros en diversas empresas: mediasmart.io, Devo, Influencity y últimamente LeanMind por ayudarme a probar diversas formas de desplegar código. Gracias a todos los alumnos del curso de escalabilidad por ayudarme a refinar la metodología.

Publicado el 2020-11-01, modificado el 2020-11-01. ¿Comentarios, sugerencias?

Back to the index.