La mejor manera de hacer un seguimiento y hacer cumplir las revisiones por pares antes de cometer

Question

Me preguntaba qué mecanismo han utilizado las personas para hacer cumplir y hacer un seguimiento de las revisiones por pares para comprometerse con SVN.

Para cada compromiso, deseo poder rastrear si las personas han tenido una revisión por pares (no estoy seguro de si hacer cumplir una regla en la que no pueden comprometer es una buena idea, mi instinto es que no debería se impondrá dado que existe una razón probablemente válida para cometer sin una revisión por pares), pero las confirmaciones no revisadas deben poder rastrearse para que antes de una publicación podamos ver todas estas confirmaciones.

Answer 1

Puede requerir que cada desarrollador agregue la etiqueta del desarrollador que realiza la revisión a la confirmación en un formato fijo como [REV: XYZ]. Esto le permite filtrar el historial. Como se mencionó aquí, puede usar los ganchos de precompilación de su herramienta de control de versiones del código fuente para aplicar esto si es necesario.

Entonces la regla de que no se puede comprometer ningún código sin una revisión por pares debe ser comunicada a todos los desarrolladores. También muestre las ventajas de revisar el código antes de comprometerse. En los primeros meses, alguien debería verificar el historial de confirmaciones de commits sin la etiqueta del revisor. Si encuentran algo, pregúnteles a los desarrolladores por qué si hicieron una revisión y con quién. Cuando no hubo revisión, recuérdeles la regla. Si algunos desarrolladores violan esta regla a sabiendas varias veces, puede haber repercusiones, pero la presión de los pares generalmente impide que esto suceda.

Normalmente, no hay excusa para no hacer una revisión cuando esta regla está en vigencia. Especialmente el "Pero tuve que arreglar este error rápidamente para entregar al cliente la versión fija" no puede ser una excusa, porque un desarrollador es más propenso a cometer errores en un apuro.

Answer 2

Personalmente puede comprometerse a menudo svn cerca de 50 veces al día, por lo que No me gustaría ver que;)

Sé complemento GreenHopper de Atlassian para jira se puede ejecutar como un gancho pre-committ para requerir una jira reference en el commit. Si usa greenhopper para planear tareas de desarrollo también, puede hacer cumplir que todas las confirmaciones deben estar conectadas a un problema jira.

E incluso si no está utilizando greeenhopper, probablemente pueda crear un enlace precompromiso que refuerce un comentario de compromiso que contenga algún número de referencia de seguimiento de problemas.

Esto probablemente debería permitirle reunir el conjunto de cambios recopilados asociados con un problema jira, que me parece una mejor idea.

Answer 3

Esta pregunta suena como un anuncio de un VCS distribuido como git o bzr: necesita desarrolladores para poder realizar cambios a menudo, pero en su propia rama, que luego se revisa antes de ser arrastrada al depósito central.

Answer 4

Los desarrolladores pueden crear una rama para cada cambio (no cada confirmación). Podrían comprometerse tantas veces como lo deseen en esta rama. Sin embargo, antes de que los cambios se fusionen en el enlace troncal, podría exigir una revisión por pares. Por lo tanto, su troncal solo contendrá código revisado por pares.

Puede hacerlo a través de permisos, por lo que solo personas selectas pueden comprometerse con el enlace troncal, y pueden verificar que el código esté correcto antes de hacerlo.

He estado usando el control de versiones por un tiempo y creo que el trabajo en el modelo de ramas (en lugar de trabajar en el maletero) es bueno. Los sistemas DVCS como git van un paso más allá y parecen funcionar bien para mucha gente.

Answer 5

Una forma de hacerlo es con una regla de commit de revisor en su equipo. Es decir, los desarrolladores no pueden comprometer su propio código, tienen que convencer a otra persona para que cometa su código en su nombre.

He trabajado en proyectos como este anteriormente, y funciona bastante bien. La desventaja es que con Subversion, esto significa que el nombre del revisor, no el del desarrollador, aparece en el registro. Con git, puede conservar el nombre del desarrollador y el revisor agrega una línea firmada por: línea.