Repensar las revisiones de código con relaciones públicas apiladas Esta publicación explora los principios de desplazamiento a la izquierda y sugiere que los PR apilados serán cada vez más útiles. El proceso de revisión de código entre pares es una parte esencial del desarrollo de software. Ayuda a mantener la calidad del software y promueve el cumplimiento de los estándares, los requisitos del proyecto, las guías de estilo y facilita el aprendizaje y la transferencia de conocimientos. Eficacia de la revisión del código Si bien la efectividad es alta para revisar cambios de código suficientemente pequeños, cae exponencialmente con el aumento en el tamaño del cambio. Para mantener el nivel necesario de enfoque mental para que sea efectivo, las revisiones de código grandes son agotadoras. Por lo general, cuanto más dura la revisión, menos efectiva se vuelve la revisión general: Entonces, ¿por qué no podemos simplemente restringir el tamaño de las solicitudes de extracción (PR)? Si bien muchos cambios pueden comenzar pequeños, de repente un pequeño cambio de dos líneas puede convertirse en un refactor de 500 líneas que incluye múltiples conversaciones de ida y vuelta con los revisores. Algunos equipos de ingeniería también mantienen ramas de funciones de ejecución prolongada mientras continúan trabajando, lo que dificulta la revisión. Entonces, ¿cómo logramos el equilibrio correcto? Simple. Utilice relaciones públicas apiladas. ¿Qué son los PR apilados? Las solicitudes de extracción apiladas realizan cambios iterativos más pequeños y se apilan una encima de la otra en lugar de agrupar grandes cambios monolíticos en una sola solicitud de extracción. Cada RP de la pila se centra en un solo cambio lógico, lo que hace que el proceso de revisión sea más manejable y requiera menos tiempo. También escribimos una publicación el año pasado explicando cómo esta ayuda representa en lugar de desglosar las cosas por archivos o funciones. los cambios de código como una narrativa ¿Por qué relaciones públicas apiladas? Además de crear una cultura de revisiones de código más efectivas, existen algunos otros beneficios de las relaciones públicas apiladas: Comentarios sobre la revisión temprana del código Imagine que está implementando una característica grande. En lugar de crear la función completa y luego solicitar una revisión del código, considere crear el marco inicial y presentarlo rápidamente para recibir comentarios. Esto podría ahorrarle incontables horas al obtener comentarios tempranos sobre su diseño. Ciclo de retroalimentación de CI más rápido Los PR apilados respaldan la práctica porque los cambios se integran y prueban continuamente, lo que permite la detección temprana y la rectificación de problemas. de cambio a la izquierda ¡Los cambios se fusionan en partes y piezas detectando cualquier problema temprano en lugar de fusionar un cambio gigante con la esperanza de que no derribe la producción! El intercambio de conocimientos Las revisiones de código también son maravillosas para la posteridad. Sus cambios de código están narrando su proceso de pensamiento detrás de la implementación de una característica, por lo tanto, el desglose de los cambios crea una transferencia de conocimiento más efectiva. Es más fácil para los miembros del equipo comprender los cambios, lo que promueve un mejor intercambio de conocimientos para el futuro. permanecer desbloqueado Esperar a que se revise y apruebe el código puede ser un proceso frustrante. Con las relaciones públicas apiladas, los desarrolladores pueden trabajar en varias partes de una función sin esperar a que los revisores aprueben las relaciones públicas anteriores. ¿Cuál es el truco? Entonces, ¿por qué más desarrolladores no usan relaciones públicas apiladas para las revisiones de código? Aunque este flujo de trabajo de relaciones públicas apilado aborda las prácticas deseadas de mantener las revisiones de código manejables y los desarrolladores productivos, desafortunadamente, Git o GitHub no lo admiten muy bien de forma nativa. Como resultado, se han desarrollado en la comunidad de código abierto para permitir que los ingenieros incorporen esta técnica de apilamiento en las plataformas Git y GitHub existentes. Pero acumular relaciones públicas es solo una parte de la historia. varias herramientas Actualizando A medida que recibimos comentarios sobre la revisión del código y hacemos cambios en la parte de la pila, ahora tenemos que reorganizar y resolver conflictos en todas las ramas posteriores. Tomemos un ejemplo. Imagine que está trabajando en un cambio que requiere realizar un cambio de esquema, un cambio de backend y un cambio de frontend. Con eso, ahora puede enviar un cambio de esquema simple para su revisión primero, y mientras se revisa, puede comenzar a trabajar en el backend y el frontend. Usando PR apilados, estos 3 cambios pueden ser revisados por 3 revisiones diferentes. En este caso, puede tener una pila que se vea así donde , y representan las 3 ramas apiladas una encima de la otra. demo/schema demo/backend demo/frontend Hasta ahora, esto tiene sentido, pero ¿qué pasa si tienes algunos comentarios de revisión de código sobre el cambio de esquema que requiere crear una nueva confirmación? De repente, su historial de confirmación se ve así: Ahora, debe volver a establecer manualmente todas las ramas posteriores y resolver los conflictos en cada etapa. Imagínese si tiene 10 ramas apiladas en las que puede tener que resolver los conflictos 10 veces. fusión Pero eso no es todo, fusionar un PR en la pila puede ser una verdadera pesadilla. Tiene 3 opciones: , y para fusionar un PR. Tratemos de entender qué hay detrás de escena en cada uno. squash merge rebase En el caso de una confirmación , Git toma los cambios de todas las confirmaciones existentes del PR y las vuelve a escribir en una única confirmación. En este caso, no se mantiene ningún historial sobre el origen de esos cambios. squash Una confirmación es un tipo especial de confirmación de Git que se representa mediante una combinación de dos o más confirmaciones. Por lo tanto, funciona de manera muy similar a una confirmación , pero también captura información sobre sus padres. En un escenario típico, una confirmación de combinación tiene dos padres: la última confirmación en la rama base (donde se fusiona el PR) y la confirmación superior en la rama de características que se fusionó. merge squash Aunque este enfoque brinda más contexto al historial de confirmaciones, sin darse cuenta crea un que puede ser indeseable. historial de git no lineal Finalmente, en caso de una y fusión, Git reescribirá las confirmaciones en la rama base. Entonces, de manera similar a la opción de confirmación , perderá cualquier historial asociado con las confirmaciones originales. rebase squash Por lo general, si está utilizando la estrategia de confirmación mientras acumula PR, su vida será un poco más simple, pero la mayoría de los equipos desaconsejan el uso de esa estrategia para mantener limpio el historial de git. Eso significa que es probable que esté utilizando una combinación o . merge squash rebase Y eso crea un conflicto de fusión para todas las ramas apiladas no fusionadas posteriores. En el ejemplo anterior, digamos que fusionamos la primera rama en la línea principal. Creará una nueva confirmación que contiene los cambios de y . demo/schema D1 A1 A2 Dado que Git no sabe de dónde vino , y todavía se basa en , intentar reorganizar en la parte superior de la línea principal creará conflictos de fusión. D1 demo/backend A2 demo/backend Del mismo modo, cambiar después de cambiar también causará los mismos problemas. Entonces, si tuviera diez ramas apiladas y fusionara una de ellas, tendría que resolver estos conflictos nueve veces. demo/frontend demo/backend Todavía estamos rascando la superficie; hay , como reordenar confirmaciones, dividir, plegar y renombrar ramas, que pueden generar una gran sobrecarga para administrar cuando se trata de relaciones públicas apiladas. muchos otros casos de uso Es por eso que creamos una gestión de relaciones públicas apiladas como parte de Aviator. Por qué Aviator CLI es diferente Piense en Aviator como una capa de aumento que se asienta sobre su herramienta existente. Aviator se conecta con GitHub, Slack, Chrome y Git CLI para brindar una experiencia de desarrollador mejorada. Aviator CLI funciona a la perfección con todo lo demás. La CLI no es solo una capa sobre Git, sino que también comprende el contexto de las pilas en GitHub. Consideremos un ejemplo. Crear una pila Crear una pila es bastante sencillo. Excepto en este caso, usamos CLI para crear las ramas para garantizar que se realice un seguimiento de la pila. Por ejemplo, para crear su rama de esquema y el PR correspondiente, siga los pasos a continuación. av av stack branch demo/schema # make schema changes git commit -a -m "[demo] schema changes" av pr create Dado que Aviator también está conectado a su GitHub, le facilita visualizar la pila. O si desea visualizarlo desde la terminal, aún puede hacerlo con los comandos CLI: Actualización de la pila Usar la pila ahora se vuelve pan comido. Puede agregar nuevas confirmaciones a cualquier rama y simplemente ejecutar desde cualquier lugar de la pila para sincronizar todas las ramas. Aviator reorganiza automáticamente todas las ramas por usted, y si hay un conflicto de fusión real, solo tiene que resolverlo una vez. av stack sync Fusionando la pila Aquí es donde las herramientas Aviator se destacan fácilmente de cualquier herramienta existente. En Aviator, hemos creado uno de los MergeQueue más avanzados para gestionar la fusión automática de miles de cambios a escala. Aviator admite una integración perfecta con la CLI y los PR apilados. Entonces, para fusionar una pila parcial o completa de PR, puede asignarlos a Aviator MergeQueue usando CLI o publicando un comentario en GitHub: . av pr queue /aviator stack merge Aviator maneja automáticamente la validación, actualización y fusión automática de todas las pilas en cola en orden. Ahora, cuando los PR se fusionen, esta vez puede ejecutar para actualizar todos los PR y limpiar todos los PR combinados. av stack sync --trunk Shift-Left es el futuro Las relaciones públicas apiladas inicialmente pueden parecer más trabajo debido a la necesidad de dividir los cambios en partes más pequeñas. Sin embargo, el aumento en la eficiencia de la revisión de código, los bucles de retroalimentación más rápidos y las mejores oportunidades de aprendizaje seguramente compensarán esta sobrecarga. A medida que sigamos adoptando los principios del cambio a la izquierda, los RP apilados serán cada vez más útiles. Aviator CLI proporciona una excelente manera de administrar relaciones públicas apiladas con mucho menos tedio. La CLI es y completamente gratuita. Nos encantaría que lo probara y compartiera sus comentarios en nuestro . de código abierto foro de discusión En Aviator, estamos creando herramientas de productividad para desarrolladores desde los primeros principios para capacitar a los desarrolladores para que construyan más rápido y mejor.
