GitHub, Gerrit, Hudson (Jenkins) de flujo de trabajo

Question

Me estoy empezando a utilizar GitHub, Gerrit, y Hudson (Jenkins) juntos. Y necesito algunas reflexiones sobre el flujo de trabajo.

Nos gustaría usar GitHub como nuestro repositorio remoto principal. Nos gustaría utilizar Gerrit principalmente para revisiones de código, sino también para construir disparadores en Hudson.

Por el momento, sin embargo, estoy teniendo un poco de dificultad para pensar a través del flujo de trabajo para esto y me gustaría escuchar lo que otros han hecho a sí mismos. Pensamientos?

Answer 1

No he utilizado directamente Gerrit, pero me gusta la idea de intermedio y de recompra, especializadas en:

• repos de su desarrollador
• el centro de GitHub remoto repo

Así que hay que determinar lo que quiere publicar en el mando a distancia de recompra GitHub:

• código para ser revisado (es decir, una aplicación web local de Gerrit tiraría el código en GitHub para examinar)
• código que ha sido revisado (es decir, publicada primero que realiza poco a Gerrit, y después de la revisión de código, les mueves a GitHub)

El segundo flujo de trabajo está más cerca de lo que Google Proyectos Android sigue con Gerrit .

En ambos casos, se necesita un repo local de intermedio para Gerrit examinar.

Answer 2

Estamos utilizando github , gerrit y Jenkins (sucesor de Hudson ). Atamos junto con Redmine de seguimiento de errores.

Antes de Gerrit, estábamos usando GitHub como el depósito y los desarrolladores de desarrollo primario tenían acceso de envío. Ahora que ya tenemos en marcha Gerrit, github sólo se utiliza como nuestro repositorio y publicar sólo el usuario tiene acceso a Gerrit empuje a github.

flujo de trabajo:

1. controles de desarrolladores a cabo fuente de GitHub.
2. desarrollador hace cambios.
3. desarrollador empuja a Gerrit.
4. Gerrit envía aviso de cambio a Jenkins para la prueba de integración.
   • Jenkins tirones cambia directamente desde el servidor git Gerrit.
   • en el pase, Jenkins añade 1 a Gerrit opinión, pasa revisión a otros desarrolladores.
   • en caso de fallo, Jenkins añade -1 a revisión Gerrit
   • pasa / no pasa de estado empujado a Redmine
5. otro cambio desarrolladores de revisar, aprobar (2)
6. compromete gerrit cambia a github repositorio.
   • notifica gancho de GitHub RedMine de cambios.
   • Redmine tira cambia de GitHub, lo analiza los mensajes de confirmación para información de entradas.
7. fetchs desarrollador cambia de nuevo a github ... 2. [editar]: nos cambió a tirar directamente de Gerrit. Github permanece como un espejo para tirar de las fuentes de producción.

Falta de piezas:

1. Gerrit opinión a / de seguimiento de errores .