Estrategias de fusión en git: Ship / Show / Ask
Ship, Show y Ask son distintas estrategias de fusión que combinan características de las Pull Requests con la capacidad de seguir enviando los cambios.
¿Cómo se hace la integración continua con Pull Requests?
Los Pull Requests han sido ampliamente adoptados por muchos equipos de software. A algunos les encantan, y otros añoran los días de la Integración Continua, cuando nunca se creaban ramas y el equipo ponía sus cambios juntos todo el tiempo.
En cierto modo, los Pull Requests son un cambio de juego. Las herramientas de alojamiento de código ofrecen una fantástica funcionalidad de revisión de código. Hay un montón de proveedores de SaaS que ofrecen servicios que pueden ejecutarse en tus pull requests, desde la ejecución de tus pruebas y la comprobación de la calidad del código hasta el despliegue de entornos de vista previa completos.
Pero la adopción de los Pull Requests como la principal forma de contribuir al código ha creado problemas. Hemos perdido parte de la mentalidad de «Listo para enviar» que teníamos cuando hicimos la integración continua. Las características en progreso se mantienen fuera del camino al retrasar la integración, y así caemos en las trampas de la integración de baja frecuencia que la Integración Continua trató de resolver.
A veces los Pull Requests se quedan estancados, o no estamos seguros de en qué trabajar mientras esperamos la revisión. A veces se hinchan cuando pensamos «bueno, puedo hacer esto mientras estoy aquí».
También nos cansamos de la cantidad de Pull Requests que tenemos que revisar, así que ya no hablamos del código. Dejamos de prestar atención y simplemente hacemos clic en «Aprobar» o decimos «Me parece bien».
Ship
Esto es lo más parecido a la integración continua de antaño. Quieres hacer un cambio, así que lo haces directamente en tu línea principal. Cuando haces esto, no estás esperando a que alguien lleve tu cambio a producción. No estás pidiendo una revisión del código. No hay problemas – sólo hacer el cambio, con todas las técnicas habituales de integración continua para que sea seguro.
Funciona muy bien cuando:
- Se añade una característica usando un patrón establecido.
- Se arregla un error sin importancia.
- Se ha actualizado la documentación.
- Se ha mejorado el código basándose en los comentarios.
Show
Aquí es donde tomamos la mentalidad de la Integración Continua y seguimos haciendo uso de todas las bondades que los Pull Requests nos pueden dar. Haces tu cambio en una rama, abres un Pull Request, y lo fusionas sin esperar a nadie. Querrás esperar a tus comprobaciones automatizadas (pruebas, cobertura de código, entornos de vista previa, etc.), pero no esperas a la opinión de nadie para proceder a poner en marcha tu cambio.
De este modo, habrás puesto en marcha tu cambio con rapidez y habrás creado un espacio para la retroalimentación y la conversación. Tu equipo debe ser notificado de tu pull request y entonces pueden revisar lo que has hecho. Pueden proporcionarle comentarios sobre su enfoque o código. Pueden hacerte preguntas. Pueden aprender de lo que has hecho.
Funciona muy bien cuando:
- Me gustaría la opinión de terceros sobre cómo podría mejorar este código.
- Mostrar un nuevo enfoque o patrón.
- Refactorizado para que ahora se vea así.
- ¡Qué error tan interesante! Mira cómo se ha arreglado.
Ask
Aquí hacemos una pausa. Hacemos nuestros cambios en una rama, abrimos un Pull Request, y esperamos la retroalimentación antes de fusionar. Tal vez no estamos seguros de haber tomado el enfoque correcto. Tal vez hay algún código con el que no estamos del todo contentos pero no estamos seguros de cómo mejorarlo. Tal vez hayamos hecho un experimento y queramos ver qué piensa la gente.
Las herramientas modernas de revisión de código ofrecen un gran espacio para este tipo de conversación e incluso puedes reunir a todo el equipo para ver un Pull Request y discutirlo.
Funciona muy bien cuando:
- Queremos preguntar si funcionará.
- Propuesta de un nuevo enfoque.
- Pides ayuda para mejoras.
- Se ha terminado por hoy y se fusionará mañana.
- Control de nuevos integrantes en el código.
Las reglas
- La revisión del código, o «Aprobación», no debe ser un requisito para que un Pull Request sea fusionado.
- La gente puede fusionar sus propios Pull Requests. De esta manera, tienen el control de si su cambio es un «Show» o un «Ask», y pueden decidir cuándo se pone en marcha.
- Tenemos que utilizar todas las grandes técnicas de integración continua y entrega continua que ayudan a mantener la línea principal liberable.
- Nuestras ramas no deberían vivir mucho tiempo, y deberíamos volver a basarlas en la línea principal con frecuencia.
La conversación
Aunque los Pull Requests pueden ser una forma útil de hablar sobre los cambios, tienen algunas trampas como la idea de que pueden sustituir a otras formas de mantener una conversación.
Un problema común con la bifurcación es que la gente decide un enfoque sin discutirlo. Para el momento en que se abre una Pull Request, se ha invertido tiempo en una solución que puede ser subóptima. Los revisores están influenciados por la solución seleccionada y les resulta más difícil sugerir enfoques alternativos. Cuanto más grandes sean los conjuntos de cambios y más largas sean las ramas, peor será este problema. Habla con tu equipo antes de empezar, así podrás obtener mejores ideas y evitar el retrabajo.
Recuerda que los Pull Requests no son la única forma de mostrar o preguntar. Súbete a una llamada o acércate al escritorio de alguien. Muestra tu trabajo pronto y a menudo. Pide ayuda y comentarios pronto y con frecuencia. Trabajen juntos en las tareas.
No abrir un Pull Request tampoco es una razón para evitar una conversación sobre el código. Es importante que tu equipo siga teniendo una buena cultura de retroalimentación y que habléis entre vosotros sobre lo que pensáis y aprendéis.
El equilibrio
Ahora hay tres opciones: ¿cuál debería elegir más a menudo? Pues depende. Cada equipo tendrá su propio equilibrio en un momento dado.
Cuando estás entregando características en un patrón establecido, estarás haciendo más «Envíos». Cuando tienes un alto grado de confianza en el equipo y la gente comparte los mismos estándares de calidad, también harás más «envíos».
Pero si todavía os estáis conociendo o estáis haciendo algo nuevo, entonces hay una mayor necesidad de conversación y por lo tanto haréis más «Show» y «Ask». Un ingeniero junior suele usar más las estrategías de «Show» y «Ask». En cambio, un ingeniero senior puede realizar muchos «Ship» pero ocasionalmente también «Show» para mostrar una nueva técnica o una refactorización que todos deberían probar.
Algunos equipos no tendrán mucha flexibilidad. Algunas industrias están muy reguladas y se requiere un proceso de aprobación o revisión para cada cambio.
¿Debe mi equipo adoptar este enfoque?
¡Ya lo ha hecho! Piensa en cómo funciona tu equipo y te darás cuenta de que estás haciendo un equilibrio entre el Ship/Show/Ask. La mayoría de los equipos entran en uno de los dos grupos: «Mayormente Ship» o «Mayormente Ask».
Si mayormente se utiliza la estrategia Ship
Si rara vez se bifurca y todos los commits van directamente a la línea principal, «Mayormente Ship», piensa si hacer algo de «Show» podría ayudarte.
Una gran parte de la razón por la que los modelos de Pull Request se han vuelto tan populares es que soportan equipos remotos y asíncronos. Mostrar explícitamente las partes interesantes de tu trabajo a los demás puede ayudarles a aprender y a sentirse incluidos en la conversación, especialmente cuando trabajan a distancia o en horarios diferentes.
Comprometerse siempre con la línea principal puede significar que los cambios problemáticos sólo se noten semanas después de haberlos hecho. Para entonces, es difícil mantener una conversación útil sobre ellos porque los detalles se han difuminado. Animar a los miembros del equipo a utilizar el enfoque «Show» significa que puedes tener más conversaciones sobre el código a medida que avanzas.
Si mayormente se utiliza la estrategia Ask
Si tu equipo está abriendo Pull Requests para la mayoría de los cambios, «Mayormente Ask». Los Pull Requests son una herramienta útil para la calidad y la retroalimentación pero tienen un problema de escala. Lo inevitable de esperar la aprobación es que lleva tiempo. Si hay demasiados cambios en la cola para la retroalimentación, o bien la calidad de la retroalimentación baja o el progreso se ralentiza. Intenta efectuar algo de «show» para obtener lo mejor de ambos mundos.
La razón por la que dependes mucho de «Ask» puede ser que tengas problemas de confianza. «Todos los cambios deben ser aprobados» o «Cada pull request necesita 2 revisores» son políticas comunes, pero muestran una falta de confianza en el equipo de desarrollo.
Esto es problemático, porque un paso de aprobación es sólo una venda – no va a arreglar sus problemas de confianza subyacentes. Haz un poco más de «Showing», para que puedas liberar algo de la presión en tu pipeline de desarrollo. A continuación, centre sus esfuerzos en actividades que generen confianza, como la formación, los debates en equipo o la programación conjunta. Cada vez que un desarrollador efectua «Show» en lugar de «Ask» es una oportunidad para que construya confianza con su equipo.
Otra razón por la que depende de muchos «Ask» podría ser que no tiene una forma segura de poner los cambios en la línea principal. En este caso, tendrá que aprender e implementar técnicas para mantener su línea principal liberable. Mientras tanto, más «Showing» puede ser una forma de reducir la barrera para llevar los cambios seguros a producción. La reducción de la barrera también actuará como un incentivo para los miembros del equipo: si puedes encontrar una manera de hacer que tu cambio sea seguro, puede salir a la luz antes.
Conclusión
¿Qué es Ship/Show/Ask? Fundamentalmente, son dos cosas:
Primero – un truco para ayudarte a obtener lo mejor de ambos mundos: fusionar tu propio pull request sin esperar a la retroalimentación, y luego prestar atención a la retroalimentación cuando llegue.
Segundo – una forma más inclusiva y dinámica de ver las estrategias de ramificación. Ship/Show/Ask nos recuerda que el enfoque de cada equipo se encuentra en un continuo en algún lugar entre «Siempre Ship» y «Siempre Ask». Nos anima a pensar en cada cambio de forma independiente y a preguntarnos: ¿debo enviar directamente, mostrar o preguntar?
Artículo original:
En relación:
Más apuntes
También puedes invitarme a algo para mojar...
