La tendencia de la rama "desarrollar" desaparece

Viene de la mentalidad CI donde hay integración varias veces al día.

Hay ventajas y desventajas de ambos.

En nuestro equipo, también hemos abandonado la rama de desarrollo, ya que sentimos que no ofrecía ningún beneficio adicional, sino algunos inconvenientes. Hemos configurado nuestro software CI (Teamcity) para compensar los inconvenientes:

1. Habilitar la implementación de un compromiso específico. En otras palabras: no desplegamos una sucursal. Desplegamos un commit.
2. Podemos implementar el maestro o las sucursales comenzando con un hotfix / prefix.

La razón por la que esto funciona es porque todas las solicitudes de extracción contienen un código potencialmente liberable, pero esto no significa que implementemos todas las confirmaciones en el maestro.

La razón principal por la que abandonamos la rama de desarrollo es porque tendía a ser demasiado grande y demasiado largo para ver lo que realmente contenía. Si hemos implementado algo un poco prematuramente, simplemente bifurcamos una rama de hotfix y lo implementamos directamente.

Una rama de desarrollo es más importante si su proceso de liberación es complejo y necesita tener candidatos de liberación serios.

Por ejemplo, imagine que está escribiendo un software que es firmware en automóviles. Esto es ... no trivial de solucionar y es probable que cualquier lanzamiento tenga un conjunto completo de pruebas de integración / no-CI ejecutadas en hardware real.

En ese caso, puede tener más sentido aislar un "candidato de lanzamiento" en una rama no maestra (como "desarrollar"). Eso permite que su equipo que ejecute esas pruebas tenga una rama para combinar características en.

Webapps u otro software fácilmente actualizado no tienen esta restricción.

Sin embargo, tenga en cuenta que:

• Muchos (¿la mayoría?) proyectos en github no tienen este tipo de restricción
• Un "maestro" principal cumple el mismo propósito
• Un flujo de trabajo de "make a PR vs master" es mucho más universal que "make a PR en una rama que no conoces inmediatamente en este repositorio"

Hay dos filosofías que he visto en proyectos, y creo que la elección es solo una cuestión de gustos:

1. Designe 'maestro' como el lanzamiento de producción y desarrolle en una rama 'desarrollar'.

2. Desarrolle en 'maestro' y tenga una rama con un nombre diferente para las versiones de producción estables. Esto tiene aún más sentido si su proyecto tiene varias sucursales de lanzamiento a la vez (por ejemplo, la actual preferida es la versión 1.8, pero también mantiene la versión 1.7).

Ambos son enfoques comunes y tienen sus pros y sus contras.

Los lanzamientos a producción se pueden etiquetar, por lo que la situación liberada siempre se puede reproducir sin dedicar una rama completa para este propósito.

Si se encuentra un error crítico en producción en un momento en el que el maestro no se puede liberar, entonces es bastante fácil revisar la etiqueta y comenzar desde allí una nueva rama "hotfixes-for-release-1.2.0". Pero eso debería ser bastante raro.

La mayoría de las veces en nuestras aplicaciones web, el maestro ha cambiado desde la última versión, pero no de manera muy significativa, por lo que simplemente podemos hacer una nueva versión del maestro que tenga la solución. Ayuda hacer lanzamientos muy frecuentes de todos modos.

  

Si los desarrolladores están trabajando en las ramas de características y luego las combinan en el maestro cuando están listas, eso significa que hay un período de tiempo en el que las características / correcciones se fusionan en master y la rama master es en realidad más nueva que la producción.

     

...

     

Imagínese si las personas se fusionan directamente con el maestro, y se informa de un error en la producción que se vuelve difícil de solucionar porque el código base de la rama maestra ha cambiado significativamente.

Eso no es Github Flow.

Este es el proceso de implementación / fusión de Github Flow, según su enlace:

  

Implementar

     

Una vez que se haya revisado su solicitud de extracción y la sucursal pase su   En las pruebas, puede implementar sus cambios para verificarlos en producción. Si   su rama causa problemas, puede revertirla desplegando el   maestro existente en producción.

     

Fusionar

     

Ahora que sus cambios se han verificado en producción, es hora de   fusione su código en la rama maestra.

(énfasis mío)

En otras palabras, master nunca estará por delante de la producción. De manera similar, master siempre estará en un estado estable y liberable (aparte de los errores no descubiertos), ya que todo se revisa, prueba y despliega a la producción antes para fusionarse a master .

El problema que veo es que Git / Hub flow deploy / merge asume que una característica se está desarrollando / probando / fusionando / implementando a la vez, y a menudo, en mi experiencia, este no es el caso. Si fusionamos una función a la vez, hay una mayor posibilidad de problemas de regresión: solo se encuentra después de que las características se fusionen para dominar y posiblemente en producción.

Debe haber una forma de probar varias funciones, combinar varias funciones e implementarlas. He estado usando una 'rama de paquete' (una rama creada desde el maestro con ramas de características preparadas para la prueba combinada en ella) que se implementa en qa / uat. Las correcciones durante uat ocurren solo en la rama de la característica, y se vuelven a fusionar en la rama del paquete. Después de que se apruebe una subsección de la rama del paquete, solo las funciones aprobadas dentro del paquete se pueden solicitar y controlar, y el ciclo es continuo.

Uso esto con Gitflow, pero estoy pensando en usarlo para GitHub flow. El QA / UAT muchas características en un tema de tiempo parece de importancia. Otro problema con el flujo de GitHub es que asume que todos los desarrolladores sr, y no siempre es el caso.

Preferiría usar el flujo de GitHub debido a su simplificación. Con una característica similar a un paquete, creo que estaría mejor preparado. Es posible que el paquete sea similar a la liberación; sin embargo, todavía estoy pensando en esto también.

Otro problema es que el proceso de solicitud de extracción ocurre al final antes de fusionarse con el maestro; sin embargo, a veces usted desea revisar el código antes de la prueba de qa de negocios, por lo tanto, mucho antes de la fusión