online - ¿Estrategia exitosa de revisión de código con SVN y ReviewBoard?

crucible atlassian

Question

He logrado introducir ReviewBoard en el flujo de trabajo de codificación de mi empresa, mientras que "introducir" significa haberlo instalado y presentado. También tenemos un acuerdo general de que necesitamos revisiones del código, sin embargo, no estamos muy seguros de cómo nos gustaría hacerlo.

Nuestro control de revisión principal es SVN, por lo que estamos bastante limitados en ramificaciones y fusiones. Algunas estrategias que he pensado:

1. Revisión de pre-confirmación desde el tronco. Los profesionales incluyen tener un solo parche, sin tener código no revisado en el repositorio. Los controles tienen que mantener su pago limpio o hacer la ramificación de un hombre pobre con varios pagos
2. Revisión post-commit desde el tronco. Funciona bien con Review Board, sin embargo, no impide que las personas cometan código sucio y también les permite ignorar las solicitudes de revisión.
3. Revisión post-commit desde una rama de características. Las ventajas son obvias, ya que una característica se puede trabajar de forma independiente, sin embargo, existe un gran dolor en la creación de sucursales basadas en servidor y también un dolor mucho mayor de mantener sincronizadas las diferentes sucursales. Véase también el punto 2.

Me gustaría hacer esto lo menos doloroso posible, por lo que hay varias posibles adiciones automatizadas al flujo de trabajo, como tener un código de confirmación de robot que obtuvo al menos X "¡Envíelo!" Votar y hacer que la Junta de Revisión "siga" una rama característica con ganchos de compromiso. Sin embargo, no estoy seguro de qué flujo de trabajo de revisión de código podría ser el mejor para nuestro equipo de aproximadamente 8 codificadores. No podremos cambiar los sistemas de control de revisión, es decir, git-svn y SVK están fuera de discusión (aunque este último está muerto de todos modos).

¿Puedes recomendar algo de tu experiencia?

Answer 1

Base su sistema en confianza y responsabilidad y manténgalo ligero:

1. Use el buen juicio: ''Puede verificar cualquier cosa en cualquier momento. Solicite una revisión del código cuando la necesite. Agregue ''revisado por'' a los comentarios si se revisó para facilitar las revisiones rápidas.
2. La junta de revisión es responsable de monitorear los cambios a través de enlaces de confirmación Si ven algo que no les gusta, tómelo con el desarrollador. Diferentes miembros pueden revisar diferentes secciones.
3. Si un desarrollador sigue verificando la basura sin pedir una revisión, despídelo.
4. Si hay secciones del sistema que son inusualmente complicadas / centrales / fáciles de desordenar, ciérrelas y requiera aprobación para registrarse.
5. Todo el mundo puede controlar los registros de entrada. Revisar no es solo para la junta de revisión.

He visto este trabajo con 2 desarrolladores y con 100.

Answer 2

En desarrollos más grandes, las ramas características son inevitables. Con SVN, no es posible "actualizar" la rama de características desde el tronco como desde la copia de trabajo. Sin embargo, es posible que tenga frecuentes combinaciones y creaciones de nuevas sucursales.

Por cierto, RB también sabe manejar revisiones previas a la confirmación.

Answer 3

Estamos en una posición similar.

¿Tiene svn configurado para enviar un correo electrónico a todos sus desarrolladores con cada confirmación? Este es un buen primer paso para mantener a todos honestos. Enviamos un correo electrónico con el mensaje de registro, las primeras 200 líneas del svn diff, y un enlace a todo el diff en trac (que básicamente solo se usa para mostrar svn diffs).

Si un desarrollador piensa que un cambio necesita revisión después del hecho, usamos ReviewBoard para realizar la revisión.

Por otro lado, los desarrolladores también pueden solicitar una revisión antes de registrarse. Ya sea que hayan desarrollado los cambios en una rama de características o en una caja de arena troncal, no hace ninguna diferencia. Hemos considerado adaptar los scripts para cargar una solicitud de revisión desde la línea de comandos, pero el proceso es tan simple que aún no lo hemos hecho.

Mi recomendación general es introducir un sistema manual, automatizarlo y, posiblemente, imponerlo con scripts de confirmación previa, una vez que esté satisfecho con el proceso. Con un equipo pequeño, especialmente, es mejor errar del lado de la aplicación de la presión de los compañeros, ya que se desea minimizar la cantidad de procesos de destrucción de poca productividad.

Answer 4

Estoy de acuerdo con la primera opinión ： Revisión previa a la confirmación desde el tronco

Desde el uso de las herramientas de vista de código, asegúrese de que no haya código no revisado en el repositorio, y para mantener su pago limpio

Answer 5

Recientemente introdujimos ReviewBoard en nuestro proceso. Antes de agregar ReviewBoard teníamos las siguientes cosas en su lugar:

1. SVN con correo electrónico enviado automáticamente a todos los desarrolladores para cada registro.
2. ViewCV integrado con para permitir que se vean las diferencias post-commit con un navegador.
3. El script SCM-bug se integró con SVN para que los desarrolladores tengan que incluir una identificación grande con sus registros.
4. Buildbot se integró con SVN para ejecutar pruebas automáticamente después de cada registro.

Dado que ya cubrimos bastante bien las cosas posteriores a la confirmación con otras, utilizamos ReviewBoard como herramienta de confirmación previa y solo después de que pulsamos "característica completa" para un lanzamiento determinado.

Answer 6

Una combinación de su # 2 y # 3 (quizás con revisiones de troncales abreviadas si la rama de la característica ya ha sido revisada) puede funcionar bien. Considero que las revisiones previas son un proceso asfixiante; es mejor tener entusiasmo (¿lo mantienes encendido?) Para que la revisión infecte a todo el equipo.

Recomiendo leer el libro gratuito de SmartBear, Best Kept Secrets of Peer Code Review , que es un tratamiento bastante imparcial especialmente. Teniendo en cuenta que su autor vende un paquete de revisión de código comercial. (No trabajo para ellos, ni uso sus productos, FWIW).

Ese libro lo ayudará a analizar los posibles flujos de trabajo para su entorno y cómo presentarlos, explicando al equipo por qué podría querer buscar revisiones de xXC o menos, o realizar una visita guiada antes críticas, etc.