git workflow con revisión

Estoy en process de implementar un process de revisión para mi pequeño equipo (3 miembros).

Estamos usando git, y el model que queremos usar es integrador con repository bendito. Cada desarrollador tiene un repository público, y el integrador retira los compromisos para includelo en el repository bendecido.

Veo varias alternativas para include revisiones en este nuevo process:


1. Los desarrolladores se quedan en su caja de arena

  • El Desarrollador A desarrolla una nueva característica en una twig llamada feature publicada en su pub, luego solicita una revisión al revisor B.
  • El revisor B características feature a sus remotes/A/feature locales remotes/A/feature , y revisar los cambios, da retroalimentación a A, A hacer los cambios.
  • Repita hasta que B acepte el estado de la twig de feature .
  • B marca el último compromiso (label revisada, no estoy seguro de cómo funciona eso todavía).
  • B publica la twig revisada en su pub y le pide al integrador I que integre los cambios en el repository bendecido.
  • todos pueden sacar los cambios del bendito repository.

pros:

  • El integrador puede rechazar commit / branches no revisados.
  • la confirmación marcada muestra quién revisó la nueva feature .

contras:

  • un process bastante engorroso. ¿O tal vez no?
  • los comentarios de la revisión en sí mismos no se almacenan en ningún lugar para reference futura (más de lo que puede ser por correo, tal vez).

2. Los desarrolladores agregan su nueva function en una twig del repository bendecido

El bendito repos no es tan bendecido nunca más, pero su twig master es.

  • A desarrolla una nueva característica en una twig y empuja la twig hacia el bendecido.
  • A pide una revisión de B.
  • B revisa la feature twig de los bendecidos, da su opinión.
  • A y B trabajan hacia adelante y hacia atrás hasta que se acepta la twig feature de los bendecidos.
  • B marca el último compromiso ( Reviewed-by ).
  • Integrador Puedo fusionar la twig de feature con el master .

pros:

  • un poco más simple

contras:

  • todos tienen acceso de escritura a los benditos, lo que significa que todos podrían causar esgulps allí.
  • los muchos detalles de los cambios de ida y vuelta durante la revisión pueden no tener su lugar en los bendecidos?

3. Herramienta de revisión de terceros

Después de navegar durante un time, encontré una tabla de revisión , que parece agradable (si podemos completar la installation en nuestro server).

pros:

  • toda la revisión está disponible para futuras references

contras:

  • configurar la herramienta en el lado del server
  • el desarrollador A debe poder tener la twig de feature revisar en su pub. ¿Cómo puede el revisor B marcar el compromiso en el pub de A como revisado ya que es de solo lectura? Lo ideal es que el rápido en que se revisó una confirmación se muestre desde git, sin necesidad de iniciar la revisión.
  • Si la característica revisada en el pub de A no está marcada con B, ¿cómo puede saber el integrador si fue revisada? Al abrir la herramienta de terceros, ¿pero no es engorroso?

Como quiero que A tenga sus cambios en su pub, creo que quiero hacer revisiones posteriores a la confirmación. La pregunta es qué debería pasar una vez que la revisión haya pasado, el integrador debería poder elegir la característica para el bendecido y ver si fue revisada, preferiblemente sin encender la herramienta.


Estoy buscando comentarios sobre estas alternativas y otras sugerencias sobre el path a seguir. Ya puedo decir que no me gusta la opción 2.

En realidad, la opción 2, si se configura con un acceso ssh administrado por gitolite , puede ser perfectamente viable:

Puede proteger la twig principal de cualquier compromiso.

Algunos comentarios:

  • option1: "publica la twig revisada en su pub": supongo que lo rastrea con una sucursal local
  • opción2: "Integrador puedo fusionar la twig de funciones con el maestro": de hecho, puede volver a establecer la bifurcación de entidades en la parte superior del maestro, para mantener el historial de la twig de entidades completa y facilitar la debugging si el código falla.
  • opción3: implica algunas tareas de administración (para la configuration y el mantenimiento de la herramienta externa), pero es la única solución que le permitirá conservar las revisiones.

Estamos utilizando github como un repository central para que los desarrolladores lo presionen cuando algo esté listo para ser compartido. e trabaje en una sucursal por function / ticket / tarea para que se identifiquen mediante la identificación JIRA. Esto mantiene el scope bien trazable.

Github tiene bastante buen soporte para revisiones de código que funciona muy bien en la práctica. El revisor puede adjuntar notas a las líneas en los deltas o el código y éstas se envían por correo al interesado. El estado de la característica se rastrea a través del estado Jira.

En nuestro caso, hay un server de CI que monitorea este server.

He estado pensando en extraer de este server las características completadas y revisadas a un repository UAT "bendecido" para comenzar la transferencia a la producción de forma controlada.

Esto nos ahorra la molestia de mantener un server de revisión, tenemos un logging persistente de comentarios de revisión, rastreabilidad del scope del trabajo a deltas de códigos, está continuamente integrado.

La desventaja es que el código está alojado externamente, lo que cuesta algo de dinero para mantenerlo privado, y existe la administración de usuarios adicionales con keys privadas para dar acceso a los desarrolladores. Superar el firewall se solucionó con sacacorchos.

Consideramos que las ventajas superan en gran medida las desventajas y están infectando a otros equipos de nuestra organización.