Crisol comparado con Gerrit?

Estamos utilizando Atlassian's Crucible en este momento para revisar los códigos (en realidad no estamos usando la parte de FishEye) y está empezando a quedar inutilizable, principalmente debido a problemas de performance al indexar un repos grande y varios repositorys.

Nuestro código está alojado en Github y se anima a los desarrolladores a realizar el repo 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 time 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, por ejemplo, Github tiene requestes de revisión de códigos (las usamos), pero la request 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 / requestes de extracción deben ser completadas por cada desarrollador. Además, la integración de Crucible to JIRA es agradable y aprovechamos eso.

También estoy abierto a otras herramientas de revisión de código, no solo a Gerrit.

Empecé a utilizar Gerrit en el trabajo (pequeño equipo de 6, interno, sin Github). No necesita "indexar" nada, pero Gerrit prefiere aferrarse al repository "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 object de revisión. Otros desarrolladores pueden extraer específicamente las confirmaciones para esa revisión si es necesario, pero de manera pnetworkingeterminada las confirmaciones no están disponibles en una sucursal normal hasta que se atesting la revisión.

Hay una gran variedad de opciones de permissions que uno puede configurar con Gerrit, lo que requiere cierto time para acostumbrarse. Puede configurar qué usuarios pueden hacer qué acciones por twig, si es necesario.

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

[No he usado Crisol.]

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 repository 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 involucran principalmente algunas situaciones raras como intentar revisar cada commit desde el comienzo del repository. Encontré que, en general, en esos casos tenía que formatear el diff y uploadlo en vez de dejarlo en Reviewview.py. script manejarlo.

Tenga en count que muy pocas herramientas de revisión de código actualmente indexan el repository de la misma forma 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.

Como dijo Greg, Gerrit supone que posee los repositorys 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 problemas de performance: la mayoría de las tiendas de Android y otros lugares utilizan internamente Gerrit en Google y en otras grandes empresas. Cientos de desarrolladores presionando a miles de repositorys 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 memory que pueda darle … Creo que algunos lugares usan 64 GB o más de RAM, pero $ DAYJOB se actualiza con alnetworkingedor de 16 GB para un par de cientos de desarrolladores.

Las twigs temáticas funcionan bastante bien en Gerrit y están mejorando todo el time.

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 tus necesidades. ¡Te recomiendo que lo pruebes!

En realidad, no es necesario tener bifurcaciones separadas para emitir requestes de extracción, puede hacer que todo el mundo se comprometa con una sola operación de repo y push para acceder a GitHub, luego click la function Pull Pull "From" feature-1 'to' master '"