continuous integration - GitHub, Gerrit, Hudson(Jenkins) flujo de trabajo

continuous-integration triggers

Question

Estoy empezando a usar GitHub, Gerrit y Hudson (Jenkins) juntos. Y necesito algunos pensamientos sobre el flujo de trabajo.

Nos gustaría usar GitHub como nuestro principal repositorio remoto. Nos gustaría usar Gerrit principalmente para revisiones de código, pero también para generar desencadenantes en Hudson.

En este momento, sin embargo, estoy teniendo algunos problemas para pensar en el flujo de trabajo para esto y me gustaría escuchar lo que otros han hecho ellos mismos. ¿Pensamientos?

Answer 1

Estamos utilizando github , gerrit y jenkins (sucesor de hudson ). Lo atamos junto con redmine para el seguimiento de errores.

Antes de gerrit, usábamos github como el repositorio principal de desarrollo y los desarrolladores tenían acceso de confirmación. Ahora que tenemos gerrit en ejecución, github solo se usa como nuestro repositorio de publicaciones y solo el usuario de gerrit tiene acceso para enviar a github.

flujo de trabajo:

1. desarrollador revisa la fuente de github.
2. desarrollador hace cambios.
3. El desarrollador empuja a gerrit.
4. gerrit envía un aviso de cambio a jenkins para la prueba de integración.
   • jenkins extrae cambios directamente desde el servidor gitit git.
   • en el pase, jenkins agrega +1 a la revisión de gerrit, pasa la revisión a otros desarrolladores.
   • En caso de falla, Jenkins agrega -1 a la revisión de Gerrit.
   • Estado de pasar / fallar empujado a redmine
5. otros desarrolladores revisan cambio, aprueban (+2)
6. gerrit confirma los cambios en el repositorio github.
   • Github Hook notifica a Redmine de actualizaciones.
   • Redmine extrae los cambios de github, analiza los mensajes de confirmación para obtener información del ticket.
7. el desarrollador recupera los cambios de github ... de nuevo a 2. [EDIT]: cambiamos a jalar directamente desde gerrit. Github permanece como un espejo para tirar de las fuentes de producción.

Piezas perdidas:

1. pieza para atar la revisión gerrit a / de seguimiento de errores .

Answer 2

No he usado directamente Gerrit, pero me gusta la idea de un repo intermedio y especializado entre:

• los repos de tu desarrollador
• El repositorio remoto de GitHub central

Por lo tanto, debe determinar qué desea publicar en el repositorio remoto de GitHub:

• Código que se revisará (lo que significa que una aplicación web de Gerrit local extraerá el código de GitHub para examinar)
• Código que ha sido revisado (lo que significa que primero publicas tus confirmaciones en Gerrit, y después de la revisión de código, las envías a GitHub)

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

En ambos casos, se necesita un repositorio local intermedio para que Gerrit lo examine.