Todos contra master: Trunk-Based Development

Más de una vez me he encontrado con gente sorprendida cuando le comento de esta práctica, por ello quiero compartir algunas reflexiones y explicaciones.

La idea es bastante simple, todo el equipo trabaja sobre un mismo branch todo el tiempo. Siendo un poco más laxos con la definición es posible trabajar sobre distintos branches en la medida que dichos branches no vivan más de 1 o 2 días.

La práctica de Trunk-Based Development va muy en línea con la practica de integración continua la cual, como su nombre lo indica, propone integrar el producto en forma continua mínimamente 1 vez al día. Desde la perspectiva de integración continua uno podría trabajar en distintos branches pero al fin del día uno debería integrar todos esos branches. Esto no es opinable ni discutible, es una definición. Puede gustar o no, pero es así como la práctica fue definida hace ya ~20 años. El punto es, no podemos decir que hacemos integración continua si estamos escribiendo código en distintos branches por varios días. En todo caso podemos decir que hacemos integración frecuente o esporádica, pero no continua, lo cual no tiene nada de malo.

Ahora bien, cuando uno piensa en hacer Trunk-Based Development surgen una serie de preguntas sobre cómo manejar diversas situaciones. No voy a entrar en detalle sobre esas diversas cuestiones, simplemente les voy a recomendar este excelente libro de Paul Hammant: https://trunkbaseddevelopment.com/book/.

Adicionalmente a los consejos de Hammant voy a compartir un conjunto de prácticas/premisas que yo suelo utilizar en conjunto con Trunk-Based Development.

  1. En primer lugar hablamos de un equipo chico, no más de 6 o 7 personas commiteando.
  2. Al mismo tiempo ese equipo chico trabaja en un pieza chica, un bounded context o un microservicio. Eventualmente puede trabajar en varios bounded context pero cada uno en un repositorio separado.
  3. Todo el código se escribe en pairing o mobbing, lo cual reduce la cantidad de cantidad de commits.
  4. Todo el código se escribe haciendo TDD, lo cual colateralmente genera una alta cobertura que funciona como una red de seguridad cuando están entrando varios commits sobre el mismo branch.
  5. Las funcionalidades están cortadas en “pequeñas fetas”, esto permite trabajar en pequeños incrementos que pueden completarse rápidamente (1, 2 o 3 días máximo).
  6. Ante cada commit, se integra el código, se buildea y se corren pruebas unitarias, se despliega a un ambiente compartido y se corren pruebras de aceptación. Si todo esto va bien, estamos en condiciones de ir a producción.

Se que algunos de estos puntos pueden resultar polémicos, incluso más polémicos que Trunk-based Development, pero esto es lo que a mi me suele funcionar. No digo que estoy vaya a funcionar en todos los contextos, pero creo que para descubrirlo hay que probarlo.

4 thoughts on “Todos contra master: Trunk-Based Development

  1. Hola Nico.
    Tengo una duda con respecto a cómo se integra esta práctica con el tema de versionado del artefacto a ser desplegado. Ahora estoy trabajando en un equipo en donde usamos feature-branch y generamos una nueva version del artefacto (usando semantic version) cada vez que mezclamos un feature branch a master.
    Me gustaría saber cómo integras el versionado del artefacto en esta práctica? Es cada commit a master una nueva versión?

  2. Muy bueno Nico. Súper claro. Es una práctica que aplicamos y nos da muy buenos resultados. Bajamos mucho el tiempo que pasábamos antes resolviendo conflictos de codigo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.