
Ship / Show / Ask
Ship / Show / Ask es una estrategia de ramas que combina la idea de crear Pull Request con la habilidad de seguir publicando cambios r谩pidamente. Fue presentada por Rousan Wilsenach en el blog del m铆tico Martin Fowler.
Los cambios que creamos en el repositorio se categorizan en tres:
- Ship: Se fusiona en la rama principal sin revisi贸n
- Show: Abre una petici贸n de cambios para que sean revisados por CI pero se fusiona inmediatamente
- Ask: Abre una PR para discutir los cambios antes de fusionarlos
Ship
Ship significa que vamos a hacer un cambio directamente a la rama principal. No esperamos revisiones de c贸digo, ni integraci贸n. Vamos directos a producci贸n (aunque antes del despliegue s铆 se har谩n los tests o checks pertinentes para evitar errores)
Pensado para:
- He a帽adido una nueva funcionalidad con un patr贸n establecido.
- He arreglado de forma sencilla un bug por un error.
- Actualizaciones de documentaci贸n.
- Mejora de c贸digo por feedback del equipo o la comunidad.
- Se a帽aden nuevos tests para evitar errores.
Show
En este caso s铆 usamos Pull Request pero no esperamos revisiones manuales del c贸digo. Es decir, esperamos que los tests automatizados, pruebas de cobertura y validaci贸n de c贸digo sean exitosos pero no que otra persona revise el c贸digo.
Esto no quiere decir que no ocurran conversaciones sobre el c贸digo. La diferencia es que ocurrir谩n despu茅s de hacer la fusion de los cambios.
La idea es que el trabajo fluya hacia adelante, con el menor n煤mero de bloqueos, pero que sigan existiendo espacios d贸nde se pueda hablar y discutir sobre c贸mo mejorar las pr谩cticas de desarrollo y el c贸digo que se crea.
El equipo es notificado que se cre贸 una Pull Request, la revisan posteriormente y despu茅s se hacen las observaciones que sean necesarias. Lo interesante es que hace que esa PR queda f谩cilmente identificable y separada.
Las Pull Request muchas veces se usan como una forma de forzar la conversaci贸n dentro del equipo y compartir conocimiento. A veces, puede ser buena idea. Pero nunca deben ser una sustituci贸n a buenas din谩micas de trabajo en equipo y usar programaci贸n a pares o en grupo.
Pensado para:
- Hacer arreglos necesarios para bugs y dejar constancia para que se aprenda.
- Crear peque帽as mejoras de c贸digo o refactors.
- A帽adir nuevas funcionalidades siguiendo estructuras ya acordadas.
- Funcionalidades con pruebas autom谩ticas.
Ask
Esta categor铆a es similar a Show pero aqu铆 s铆 esperamos al feedback de nuestro equipo ante de fusionar la rama. Lo hacemos porque existe algo de incertidumbre: bien porque la soluci贸n es complicada, no sabemos implementarla, existen dudas…
La idea es que la rama dure el m铆nimo tiempo posible para no bloquear el trabajo de otros miembros del equipo
Una cosa importante a destacar que decidir usar la categor铆a de Ask no quiere decir que esperemos la aprobaci贸n de nuestros colegas. Estamos abriendo una v铆a de conversaci贸n y debate antes de fusionar la rama ya que existe alg煤n bloqueo o duda, pero es posible que no estemos buscando una revisi贸n general de los cambios (si es as铆, deber铆amos indicarlo).
Pensado para:
- Cuando es un trabajo muy grande y se necesita ayuda.
- Hay dudas sobre c贸mo hacerlo funcionar o la calidad del c贸digo.
- Existe incertidumbre sobre lo que estamos haciendo.
- Estamos esperando a que algo ocurra para poder fusionar la rama.
Las reglas de Ship / Show / Ask
Obviamente, poder llegar a seguir algunas de las categor铆as requiere algunas reglas.
- Tenemos un buen sistema de CI/CD, fiable y r谩pido, que hace que la rama principal siempre sea desplegable y que evite que lleguen errores no deseados a producci贸n.
- Confiamos en el equipo y existen buenas pr谩cticas de desarrollo. Pair programming, mob programming, seniority… y, sobretodo, existe responsabilidad. La persona se responsabiliza de decidir la categor铆a de su cambio. Un gran poder, poder hacer merge de tus propias Pull Request, conlleva una gran responsabilidad (no romper producci贸n).
- Las revisiones de c贸digo no son requerimientos para que las PRs sean fusionadas.
- Las ramas son lo m谩s peque帽as posibles, tienen un tiempo de vida corto y siempre salen directamente desde la rama principal.
- El equipo ha sabido lidiar con el ego individual, confia en el resto del equipo y considera que la rama principal puede no contener c贸digo perfecto siempre y cuando las pruebas autom谩ticas pasan.
脷ltimas palabras sobre Ship / Show / Ask
Creo que la idea detr谩s de esta estrategia, en realidad, es la de responsabilizar a cada persona con su trabajo, empoderar al equipo, darle autonom铆a y tratar a la gente que lo integra por igual.
Tambi茅n est谩 que el desarrollo sea m谩s r谩pido y la entrega sea m谩s continua, pero para poder lograrlo se va a necesitar mucha confianza. Algo que, seguramente, no todos los equipos est茅n preparados de inicio.
En cualquier caso creo que Ship / Show / Ask podr铆a ser una mezcla de estrategias que ya hemos visto anteriormente… simplemente deja la puerta abierta a que cada persona decida por s铆 misma cu谩l es la mejor categor铆a para cada cambio y le pone nombre.