¿Crisol comparado con Gerrit?

Estamos utilizando Atlassian's Crucible en este momento para revisar los códigos (en realidad no estamos usando la pieza FishEye) y está empezando a quedar inutilizable, principalmente debido a performance issues en la indexación de un repos grande y múltiples repositorios.¿Crisol comparado con Gerrit?

Nuestro código está alojado en Github y se anima a los desarrolladores a bifurcar el repositorio y hacer todo su trabajo en sus propias horquillas. Para que esto funcione con Crucible, necesitamos indexar todas las horquillas de los desarrolladores. Hemos comenzado a hacer esto, pero lleva un tiempo increíblemente largo (horas por compromiso). Ver el enlace de arriba.

¿Cómo se compara Gerrit? ¿Indexa los repos?

Sé que la gente comentará que el Github tiene solicitudes de revisión de códigos (las usamos), pero la solicitud de extracción se realiza realmente al final del flujo de trabajo una vez que ha sido revisada. Tenemos un equipo de aproximadamente 20 personas en desarrollo, y no hay un sistema en Github para administrar qué revisiones/solicitudes de extracción deben ser completadas por cada desarrollador. Además, la integración de Crucible to JIRA es agradable y aprovechamos eso.

Estoy abierto a otras herramientas de revisión de código, no solo a Gerrit.

Fuente

2011-11-23 Valdis R

Solo quería señalar que no siempre tiene que esperar hasta el final para presentar una solicitud de extracción. GitHub escribió una publicación sobre cómo los usan, y crean la solicitud anticipadamente: https://github.com/blog/1124-how-we-use-pull-requests-to-build-github. Aun así, no soluciona los otros problemas que tienes. – jszakmeister

Al final, decidimos ir simplemente con el uso de Pull Requests; las solicitudes de extracción se abren y luego nuestro sistema de venta de entradas se actualiza con la URL de solicitud de extracción. No se fusiona hasta que QA ha verificado los cambios y luego se fusionan. –

Empecé a utilizar Gerrit en el trabajo (pequeño equipo de 6, interno, sin Github). No necesita "indexar" nada, pero Gerrit prefiere aferrarse al repositorio "maestro". Entonces, un nuevo desarrollador clonaría directamente de Gerrit.

Los cambios realizados por los desarrolladores se someten a un refspec especial en Gerrit, que crea un objeto de revisión. Otros desarrolladores pueden extraer específicamente las confirmaciones para esa revisión si es necesario, pero de manera predeterminada las confirmaciones no están disponibles en una sucursal normal hasta que se aprueba la revisión.

Hay una amplia variedad de opciones de permisos que uno puede configurar con Gerrit, lo que lleva un tiempo acostumbrarse. Puede configurar qué usuarios pueden hacer qué acciones por rama, si es necesario.

Tenemos un repositorio grande (base de código de más de 20 años) pero solo unos 2 años de historial de confirmaciones (migrado desde el VCS anterior). No hay problemas de rendimiento y debido a la forma en que funciona Gerrit, no espero nada a medida que el repositorio crece.

[No he utilizado Crucible.]

Fuente

2011-11-23 18:05:59

¿Su flujo de trabajo estándar incluye ramas de tema/característica? Nos gusta mantener el maestro (esencialmente) liberable, por lo que todos los errores y mejoras entran en diferentes ramas. –

Sí, todo el desarrollo se realiza en las ramas (y se revisa en la rama), luego otro paso es fusionar la rama en el maestro. El paso de fusión también pasa por Gerrit, por lo que la inclusión de la característica en el maestro puede aprobarse por separado del desarrollo de la función en sí. La versión actual de Gerrit no se encarga especialmente de la revisión de las asignaciones de fusión, pero consulte http://code.google.com/p/gerrit/issues/detail?id=665 para obtener más información. –

En realidad no tiene que tener horquillas separadas para emitir solicitudes de extracción, puede hacer que todo el mundo ceñirse a una sola cesión temporal y empujar ramas de características a GitHub, a continuación, haga clic on Pull Request "From" feature-1- 'to' master '"

Fuente

2011-11-23 22:39:09

Correcto, lo sé, pero es bueno tener las horquillas separadas para indicar la propiedad de las características, así como para garantizar que no terminemos con un grupo de sucursales huérfanas en el repositorio principal. –

Como dijo Greg, Gerrit supone que posee los repositorios y no hay un buen método (actualmente) para usarlo junto con github. Probablemente puedas conectarlo para que, una vez que el código sea revisado/verificado/fusionado en gerrit, se convierta en github y los desarrolladores puedan seguir obteniendo desde allí.

No creo que tenga ningún problema de rendimiento: Gerrit es utilizado por la mayoría de las tiendas de Android y otros lugares internamente en Google y otras grandes empresas. Cientos de desarrolladores presionando a miles de repositorios no son infrecuentes.

Si está alojando en github actualmente, tendrá que proporcionar su propio hardware, que debe ser un tanto robusto. Gerrit gustosamente utilizará toda la memoria que pueda darle ... Creo que algunos lugares usan 64 GB o más de RAM, pero $ DAYJOB se actualiza con alrededor de 16 GB para un par de cientos de desarrolladores.

Las ramas de tema funcionan bastante bien en Gerrit y están mejorando todo el tiempo.

Gerrit no resolverá realmente su problema de asignar desarrolladores para que hagan la revisión/verificación/fusión en sí misma. Los desarrolladores pueden agregar otros desarrolladores como revisores para un cambio/confirmación, pero no existe un concepto de flujo de trabajo/propietario oficial. Mi equipo usa a Jira para eso: una vez que la tarea esté terminada, asigna el problema de Jira a alguien para que lo revise, luego, entrégalo a alguien para que lo verifique, etc. También hay muchas otras opciones aquí.

Sospecho que Gerrit satisfaría sus necesidades. ¡Te recomiendo que lo pruebes!

Fuente

2011-11-24 03:00:24 Brad

Una alternativa podría ser ReviewBoard, que en su mayoría funciona bastante bien con git. En un trabajo anterior, escribí un script que utiliza ganchos post-recepción para crear revisiones automáticamente cada vez que algo se envía al repositorio central. ReviewBoard no es tan bonito como Crucible o Gerrit, pero lo cambiamos de Crucible por exactamente las razones que estás describiendo.

Los pequeños problemas con ReviewBoard y git principalmente implican algunas situaciones raras como tratar de revisar cada confirmación desde el comienzo del repositorio - encontré que, en general, en esos casos tenía que formatear la diferencia y cargarla en lugar de dejarla La escritura de ReviewBook.py de ReviewBoard lo maneja.

Tenga en cuenta que muy pocas herramientas de revisión de código realmente indexan el repositorio de la misma manera que Crucible. La mayoría de ellos confían en parches, ya sean autogenerados por alguna herramienta como postreview.py o mirando el compromiso y generando el diff internamente.

Fuente

2011-11-24 05:41:49 ebneter

Gerrit? ¿Bonita? * risa confundida * – SyntaxRules

Respuesta

Cuestiones relacionadas