Check-ins cerrados / compromisos probados previamente para Git?

Estoy buscando migrar de TFS (Team Foundation Server) a Git, pero no encuentro nada que coincida con el soporte de TFS para check-ins controlados (también llamados confirmados previamente o retrasados).

Atlassian Bamboo no tiene soporte para check-ins cerrados. TeamCity lo admite ("compromisos retrasados" usando su terminología), pero no para Git. Usar Jenkins solo o Jenkins + Gerrit tiene enormes inconvenientes y no se acerca a la funcionalidad de check-in controlado en TFS. (Inconvenientes explicados por el creador del propio Jenkins en este video: http://www.youtube.com/watch?v=LvCVw5gnAo0 )

Git es muy popular (por una buena razón), entonces, ¿cómo está la gente resolviendo este problema? ¿Cuál es actualmente la mejor solución?

Acabamos de comenzar a usar git y hemos implementado confirmaciones probadas utilizando flujos de trabajo (terminé de probar esto solo hoy).

básicamente, cada desarrollador tiene un repository personal con acceso de lectura / escritura. El server de compilation TeamCity en nuestro caso, construye utilizando estos repositorys personales, y luego, si es exitoso, envía los cambios al repository "verde". Los desarrolladores no tienen acceso de escritura a 'verde', solo los agentes de compilation de TeamCity pueden escribir sobre eso, pero los desarrolladores extraen actualizaciones comunes de 'verde'.

Así que dev tira de lo "verde", lo empuja a lo personal, las creaciones de TeamCity de lo personal, lo empuja a lo verde.

Esta publicación de blog muestra el model básico que estamos usando, con las horquillas GitHub para los repositorys personales (usar las horquillas significa que la cantidad de repositorys no se sale de control y termina costando más, y significa que los desarrolladores pueden administrar las comstackciones personales , ya que pueden bifurcar y luego crear los trabajos de creación de la ciudad del equipo para get su código empujado a 'verde'):

enter image description here

Este es más trabajo para configurar en TeamCity ya que cada desarrollador debe tener su propia configuration de compilation. Que en realidad tiene que ser 2 configuraciones, ya que TeamCity parece ejecutar todos los pasos de compilation (incluido el paso final de 'empujar a verde') incluso si fallan los pasos de compilation anteriores (como las testings :)), lo que significaba que teníamos que tener un file personal build para el desarrollador, luego otra configuration de compilation que dependía de eso, lo que simplemente daría el empujón asumiendo que la compilation funcionó.

Echa un vistazo a Verigreen : un sistema de check-in ligero y controlado por el lado del server. Verifica cada compromiso antes de que encuentre su path en las twigs que el sistema protege. Verigreen no permitirá que ningún compromiso fallido de CI rompa la integración, la versión o cualquier twig que deba protegerse. Además, es un proyecto gratuito y de código abierto.

Cómo funciona: Verigreen intercepta los loggings y ejecuta la verificación en una sucursal ad hoc, de modo que en caso de una falla de compromiso, solo el desarrollador relevante se vea afectado.

  • Un gancho pre-recepción intercepta y crea una twig ad-hoc del código.
  • La verificación se ejecuta a través de un trabajo de Jenkins. El contenido del trabajo de verificación es completamente configurable.
  • El código verificado se fusiona nuevamente en la twig protegida mientras que una confirmación fallida se bloquea con una notificación enviada al desarrollador.

enter image description here

Las decisiones se toman en base al siguiente flujo:

Verigreen - Flujo básico

Para get más información, consulte el sitio wiki o Verigreen.io

Creo que después del 23 de octubre de 2013, la respuesta puede ser: fusión automática en TeamCity .

git tiene una filosofía diferente: los compromisos son fáciles, cometer como lo desee. Si algo está mal, puede cambiarlo más tarde. Y las fusiones son fáciles. Por lo tanto, podría organizar un flujo de trabajo apropiado, por ejemplo, los desarrolladores podrían comprometerse en una (s) twig (s) separada (s). Cuando se testing una twig, podría fusionarse en una twig principal.

¿Por qué no utilizar TFS como repository central y utilizar GIT como una solución DVCS local?

Esto le permitiría build y comprometer localmente y luego enviar lo que desea al server TFS y hacer una compilation cerrada.

A veces es bueno tener lo mejor de ambos mundos …

Con VS Team Services (fka Visual Studio Online) y TFS 2015 o posterior, puede usar políticas de sucursal que requieren una compilation de paso para una request de extracción como un flujo de trabajo de check-in con Git.