Flujo de trabajo de revisión de código donde el autor de la solicitud de extracción debe fusionarse

13

Varios equipos de mi empresa practican un flujo de trabajo de revisión de código que nunca antes había visto. Estoy tratando de entender el pensamiento detrás de esto, con la idea de que hay valor en hacer que toda la compañía sea consistente. (Contribuyo a múltiples bases de código y me he visto afectado por las diferencias en el pasado).

  1. El autor del código envía una solicitud de extracción
  2. El revisor examina el código
    • Si el revisor lo aprueba, deja un comentario como "Se ve bien, siéntete libre de fusionar"
    • Si el revisor tiene inquietudes, deja un comentario como "Por favor, corrija los problemas menores X e Y, luego fusione" (Para cambios mayores, vuelva al paso 2)
  3. El autor del código realiza cambios si es necesario, y luego fusiona su propia solicitud de extracción

Tengo las siguientes preocupaciones:

  • En el caso de aprobación en el paso 3, este flujo de trabajo crea un viaje de ida y vuelta aparentemente innecesario al autor de la solicitud de extracción. El revisor, que ya está mirando el código, podría fusionarlo inmediatamente.

  • En el caso de que se soliciten cambios en el paso 3, la agencia para fusionar la solicitud de extracción ahora depende exclusivamente del autor del RP. Nadie más que el autor verá los cambios antes de fusionarse.

¿Cuáles son algunas otras ventajas o desventajas de este flujo de trabajo? ¿Este flujo de trabajo es común en otros equipos de ingeniería?

    
pregunta aednichols 24.10.2016 - 18:55

4 respuestas

19

En el primer caso, generalmente es una cortesía. En la mayoría de las organizaciones, las fusiones inician una serie de pruebas automatizadas que deben tratarse con prontitud si fallan. Especialmente si hubo un retraso significativo entre el momento en que se envió una solicitud de extracción y cuando se revisó, es educado permitir que se fusione en el calendario del autor, de modo que tengan tiempo para lidiar con cualquier consecuencia inesperada. La forma más sencilla de hacerlo es dejar que se fusionen ellos mismos.

Además, a veces el autor se da cuenta de los motivos posteriores para que una solicitud de extracción aún no se haya fusionado. Quizás la RP de otro desarrollador sea una prioridad más alta y cause conflictos. Tal vez ella pensó en un caso de uso descubierto. Tal vez un comentario de revisión provocó una lluvia de ideas que necesita más investigación antes de que el problema esté completamente satisfecho. El autor sabe más sobre el código, y tiene sentido darle la última palabra sobre cuándo se fusionará.

En el segundo punto, eso es solo una cuestión de confianza. Si no puede confiar en que las personas resuelvan problemas menores sin una doble verificación, no deberían trabajar para usted. Si el problema es lo suficientemente grande como para necesitar otra revisión después de la corrección, confíe en que los revisores la soliciten.

Dicho esto, de vez en cuando fusiono las solicitudes de extracción de otros autores, pero generalmente son cambios muy simples o de fuentes externas, donde personalmente asumo la responsabilidad de controlar cualquier falla de automatización de pruebas.

    
respondido por el Karl Bielefeldt 24.10.2016 - 20:05
3

Tener el autor inicial fusionar su propia solicitud de extracción es mi flujo de trabajo preferido en equipos pequeños. Además de las ventajas técnicas ya mencionadas (en términos de resolución de conflictos de fusión, por ejemplo), creo que agrega valor a nivel cultural: crea un sentido de propiedad.

Especifiqué al autor initial para el caso (raro) en que otro desarrollador agregaría confirmaciones a la solicitud de extracción abierta (tirando de la rama de la característica de trabajo en curso y presionándola de nuevo). Esto no sucede con frecuencia, y resultaría de una conversación en persona o por encima de Slack: ¡estas confirmaciones adicionales (por otra persona) no deberían no aterrizar allí por sorpresa! En este contexto, por autor de initial , me refiero a la persona que envió la solicitud de extracción.

    
respondido por el mkcor 13.02.2018 - 22:31
2

En mi organización somos bastante nuevos en las solicitudes de extracción y su pregunta es una que me he planteado.

Una observación que me gustaría agregar: en algunas herramientas (usamos TFS) puede haber un elemento de trabajo asociado con la solicitud de extracción.

Si ese es el caso, se convierte en una molestia en mantener un registro de cuándo el revisor realizó la fusión. En ese escenario, el desarrollador tiene que volver a visitar el PR, abrir el error o cambiar la solicitud y marcarlo como "resuelto". Si lo marcamos como "resuelto" demasiado pronto, los evaluadores creen que la solución ya es parte de la compilación actual.

TFS 2017 mejoró su implementación de la solicitud de extracción. Ahora el desarrollador puede solicitar que la Solicitud de extracción se fusione automáticamente si se cumplen todas las condiciones (sin conflicto de combinación, aprobación de los revisores y sin compilaciones rotas). YMMV.

    
respondido por el 9Rune5 20.12.2016 - 16:39
1

De esta manera, el autor tiene la oportunidad de cambiar de opinión acerca de su sucursal, tal vez haya descubierto algo que debería hacerse de otra manera, y volver a revisar los cargos adicionales.

    
respondido por el gnasher729 24.10.2016 - 22:05

Lea otras preguntas en las etiquetas