Proceso recomendado para revisiones de código con mercurial

Por lo general, usamos Perforce y SmartBear's Code Collaborator en Big Corpy ahora también usaremos Mercurial para ciertos proyectos.

Code Collaborator admite Mercurial (estamos utilizando la versión 5) y estoy tratando de determinar cuándo el mejor momento (durante el proceso de confirmación / envío al servidor) es el mejor / eficiente momento para una revisión de código

Gracias

De hecho, pasamos por casi exactamente lo mismo en mi empresa recientemente. Esto es lo que hicimos:

• Mantenemos una copia definitiva central de todos nuestros repositorios en un servidor. Cuando los desarrolladores quieren "revisar" el código, van a este servidor y clonan desde los repositorios allí. Del mismo modo, cuando se completa el ciclo de desarrollo, el código también se inserta en el repositorio apropiado.

• Separamos estables repositorios de desarrollo repositorios. Requerimos que el código se revise antes de que se inserte en un repositorio estable. (Esto es importante porque también requerimos que nuestros repositorios estables contengan el código que se está ejecutando actualmente en producción, que solo se diferencia por promociones de código pendientes).

Para hacer cumplir la revisión del código, escribimos un pretxnchangegroupgancho (documentado en el Libro HG ). Aprovechamos el hecho de que cuando se ejecuta este enlace, puede ver el repositorio como si los cambios en el código fueran permanentes, pero también nos da la capacidad de evitar el empuje. Básicamente, el proceso es el siguiente:

1. El desarrollador inicia un empuje al repositorio estable (sí, este es realmente el primer paso)
2. El gancho se ejecuta y toma una lista de todos los conjuntos de cambios incluidos en la transacción (ejecutando el registro HG). Luego consulta una base de datos que creamos para ver si esos conjuntos de cambios se incluyeron en una revisión de código. (La tabla coincide con el hash de un conjunto de cambios con una ID de revisión de código).
   • Si esta es la primera vez que se ve alguno de estos conjuntos de cambios, entonces creamos una nueva Revisión de Código (usando la línea de comando del Colaborador de Código), y luego registramos estos conjuntos de cambios en la base de datos con la ID de esa revisión de código.
   • Si hemos visto algunos (pero no todos) de los conjuntos de cambios, ejecutamos el comando (Colaborador de código) para adjuntar los nuevos conjuntos de cambios a la revisión existente y registrar estos nuevos conjuntos de cambios en la base de datos.
   • Si se encontraron todos los cambios en la base de datos (es decir, todos se agregaron a la revisión del código), verificamos que el estado de la revisión del código sea Completo. Sin embargo, si hubo nuevos conjuntos de cambios (o la revisión del código no está completa), el enlace se cierra con un código de estado distinto de cero (lo que hace que Mercurial revierta la transacción) y emite un mensaje amistoso sobre Error estándar que explica al desarrollador que la revisión del código debe estar terminada.

En esencia, esto le proporciona al desarrollador un proceso bastante simplificado (todo lo que tienen que hacer es presionar hg) y automatiza completamente la creación de la revisión del código (y la carga de archivos modificados adicionales a la revisión), al tiempo que garantiza que todo el código sea revisado .

Nota: Este es un proceso bastante simple (y relativamente nuevo para nosotros), por lo que puede que no funcione para todos, y puede haber algunos errores de diseño que aún no hemos encontrado. Pero hasta ahora, ha funcionado bastante bien.

Depende de cómo tenga su estructura de repositorio y de lo que esté tratando de lograr. Preferimos hacer revisiones "precompromiso", que en el mundo de DVCS realmente significa "pre-push". Los DVCS son más agradables en este entorno (en comparación con los SCM tradicionales) porque tienen una funcionalidad incorporada para guardar sus cambios locales y recuperar su espacio de trabajo para que pueda trabajar en otra cosa.

Si desea realizar revisiones posteriores, el flujo de trabajo ideal depende en gran medida de la estructura de su repositorio. Por ejemplo, supongamos una estructura de repositorio que se parece a la discutida en este artículo sobre diseños de repositorio de Git . En este caso, es posible que desee revisar los cambios que se están fusionando develop. Las confirmaciones individuales en ramas de características pueden no tener sentido para la revisión. Obviamente, todo hotfixestambién debe ser revisado junto con las fusiones en master.

Si, por el contrario, tiene una rama de integración única en la que las personas se registran directamente, querrá revisar todos los envíos a esa rama. Probablemente sea un poco menos eficiente, pero aún podría funcionar. En este entorno, deberá asegurarse de revisar todos los cambios que se han enviado antes de cortar una versión. Eso puede ser más complicado.

En cuanto a b) lo único que sugeriría es enviar un correo electrónico al soporte de SmartBear ([email protected]) directamente. (Sí, trabajo para SmartBear) estaremos encantados de ayudarlo a resolver sus problemas de ruta, pero no hay suficiente información en esta pregunta para solucionar su problema. El proceso normal es simplemente ejecutar el instalador y todo funciona. Al parecer, algo salió mal en ese proceso.