Estrategia model de ramificación de Git

Estamos tratando de seguir el model de ramificación de gitflow , pero con un giro.

Tenemos cuatro entornos de serveres donde el producto se puede implementar, cada server cumple una function: desarrollo, testings internas, testings externas y producción.

  • DevServer , donde los desarrolladores testingn sus diferentes características, mientras se desarrollan. Los desarrolladores no pueden realizar testings locales en sus máquinas, tienen que hacer sus cambios en el DevServer para poder probar
  • TestServer , donde los verificadores de QA testingn múltiples características una vez que los desarrolladores terminan
  • ReleaseServer , donde las versiones se testingn de forma aislada antes de moverlas a producción
  • ProductionServer . El server de producción

Estamos tratando de hacer que la resolución de fusión / conflicto sea lo más fácil posible, por lo que creamos dos twigs adicionales que no forman parte del model de gitflow.

Ramas normales de gitflow

  • desarrollar
  • master (coincide con 'ProductionServer')
  • featureXXX
  • releaseXXX (las versiones semanales se implementan en 'ReleaseServer')

Pero también estas dos twigs que no son estándar y podrían necesitar cambiar …

  • dev-release (copy de DevServer)
  • testing-lanzamiento (copy de TestServer)

Entonces el process es el siguiente:

  • desarrollador crea su 'featureXXX' desde 'develop'
  • múltiples desarrolladores fusionan sus diferentes "características" en la twig "dev-release", y la twig "dev-release" se lanza al "DevServer" donde todos los desarrolladores pueden probar sus diferentes funciones. No todas estas características estarán en la misma versión siguiente
  • Una vez que los desarrolladores están contentos con su testing de desarrollo anterior, fusionan su 'featureXXX' en la twig 'test-release', y esto se implementa en 'TestServer'. No todas las funciones aquí serán parte de la próxima versión.
  • Una vez que se realiza la testing en 'TestServer' para featureXXX, el desarrollador puede cerrar su featureXXX en 'develop'.
  • El desarrollador luego crea un nuevo 'releaseXXX' o combina su 'featureXXX' en un 'releaseXXX' existente.
  • La twig 'releaseXXX' se implementa en 'ReleaseServer' y se testing.
  • Una vez que se ha cerrado la session de 'releaseXXX', 'releaseXXX' se fusiona en develop y master, y se implementa en 'ProductionServer'

¿Estamos estropeando todo el model de gitflow?

Aquí está nuestro process de creación: enter image description here

Solutions Collecting From Web of "Estrategia model de ramificación de Git"

Para responder a su pregunta, no, no está arruinando el model de gitflow, sino que lo ampliará para satisfacer sus necesidades.

Al acoplar entornos a una twig determinada, te estás dando mucha más flexibilidad cuando se trata de crear lanzamientos. es decir, digamos que tiene dos características no dependientes (Característica 1 y 2) en progreso, y ambas se han fusionado en su twig 'TestServer'. Si la Característica 1 no supera la testing, la Característica 2 aún puede avanzar más sin la Característica 1: esto se debe a que su fusión en 'Servidor de Prueba' es una combinación de una sola vía: nada sale, no hay historial. En cambio, su twig Feature 2 se fusiona en 'desarrollar' y finalmente 'maestro'.

Estamos en el process de adoptar / desarrollar una estrategia similar para usted. El requisito key para nosotros es dar cabida a la selección ineludible de características . Tenga en count que nuestra solución, aunque bastante compleja, ha sido diseñada para una aplicación empresarial, que sirve como plataforma para múltiples services propiedad de múltiples propietarios de negocios y utiliza múltiples frameworks internos.

Ambientes

  • QA: para que los desarrolladores se aseguren de que su característica sea comprobable.
  • Etapa: para los gerentes de proyecto / gerentes de testing a testing de humo antes de la testing UAT por los diferentes 'Propietarios de empresas'
  • UAT: para la testing completa y la firma de negocios por parte de los "Empresarios"
  • BETA: simplemente una testing de implementación / lanzamiento
  • VIVIR: ..

Estos entornos se agrupan en dos categorías, 'in-test' (QA, Stage y UAT) y 'production' (BETA y LIVE).

Sucursales

La priorización de características puede cambiar con frecuencia, desde problemas de testing hasta restricciones / requestes regulatorias. Para acomodar esto, se crean múltiples twigs para representar el entorno / categorías de la siguiente manera:

  • Master: representa la última versión de producción
  • Release-Candidate: una colección de características para la próxima versión de producción
  • UAT: representa el entorno UAT
  • Etapa: representa 'QA' y 'Etapa'
  • Feature-xxx: para el desarrollo de características

También utilizamos una twig HotFix de Master según sea necesario, y preparamos lanzamientos de producción en una twig 'Pre-Production' (corrigiendo incrementos de versiones perdidas, etc., cosas menores).

Un diagtwig de nuestras Sucursales en uso: Un diagrama de nuestras Sucursales en uso:

Branching and Merging / WorkFlow

  1. Siempre ramificamos nuevas características de Release-Candidate, ya que esta twig siempre contiene las características 'Comprometido para la producción'. Nada salta una vez que se ha hecho el compromiso de producción.

  2. Una vez que una característica está list para la testing, se fusiona (unidireccional) en 'Etapa'. Esto desencadena una compilation CI y se implementa en QA.

  3. Si el server de QA se ve estable, el desarrollador activa una implementación automática en Stage.

  4. Si se requieren cambios, conviértelos en function y repítelos. Si está bien para las testings de negocios, entonces combine de Feature a UAT. Esto se implementa en UAT.

  5. Si la function no supera las testings comerciales, realice cambios en la function y repita. Si la function se retrasa, no realice ninguna acción. Si la function está OK y firmada, entonces se fusiona con Release Candidate.

  6. Una vez que la colección (1 o más) de las características estén en Release-Candidate, desencadenar la implementación de la producción mediante la fusión de Release-Candidate a Master (a través de Pre-Production).

  7. Despliegue fallido, luego HotFix. Si está bien, implemente a Live.

Nuestro flujo de trabajo, usando TFS, se ve así:

Nuestro flujo de trabajo, usando TFS, se ve así:

Liberar flujo de trabajo

Y finalmente, cada implementación en un entorno / categoría se vería así:

Flujo de despliegue