¿Tener una sucursal de producción o usar master?

Trabajo en un equipo pequeño con otros desarrolladores remotos en una Railsaplicación. Estamos comenzando a modificar nuestro gitflujo de trabajo. Hemos pensado en una estructura de ramificación como la siguiente:

(dev) -> (qa) -> (stag) -> (master)

Pero algunos de los desarrolladores pensaron que podría ser menos confuso para los nuevos desarrolladores que podrían empujar automáticamente a la producción en master. En su lugar, pensaron que todos trabajaran en master y crearan una rama separada para la producción.

(master) -> (qa) -> (stag) -> (prod)

Me enseñaron que desea mantener el maestro desplegable y no usarlo como desarrollo, y desde lugares anteriores donde he trabajado maestro siempre debe ser desplegable para la producción.

¿Cuáles serían algunas de las desventajas de usar una estructura de ramificación donde master se usa activamente para el desarrollo y una rama de producción separada es lo que usa para las implementaciones?

No hay ventajas ni desventajas en este enfoque. La razón por la que digo esto es simple: para Git, no hay diferencia si se desarrolla desde master o se libera desde master. Ni siquiera necesita liberar ramas; podría etiquetar una confirmación arbitraria y liberarla, en su lugar.

El verdadero problema aquí es uno de proceso y procedimiento. Los desarrolladores más importantes que están preocupados de que hacerlo de una manera confundirá a los desarrolladores más nuevos deben estar preparados para invertir el tiempo para explicar cuál es el modelo de lanzamiento y por qué es así.

Mientras todos entiendan que el master es para el desarrollo, y alguna otra rama arbitraria es para los lanzamientos, y el trabajo para mantener esto está hecho , entonces no debería haber ningún problema con este enfoque.

Puedo ver tu dilema. Lo tuve también, hasta que desaprendí lo que siempre asumí sobre el maestro.

Me enseñaron que desea mantener el maestro desplegable y no usarlo como desarrollo, y desde lugares anteriores donde he trabajado maestro siempre debe ser desplegable para la producción.

De la documentación / libro de Git: ramificación de Git

La rama "maestra" en Git no es una rama especial. Es exactamente como cualquier otra rama. La única razón por la que casi todos los repositorios tienen uno es porque el comando git init lo crea por defecto y la mayoría de las personas no se molestan en cambiarlo.

Entonces, si tiene un flujo de trabajo preferido, y es difícil trabajar con él porque los diferentes desarrolladores del equipo tienen ideas diferentes master. Incluso podría considerar cambiar el nombre masterpara decir prody usar un flujo de trabajo como el siguiente:

(dev) -> (qa) -> (stag) -> (prod)

Así es como cambia el nombre de la rama maestra .

NO estoy diciendo que debe cambiar el masternombre de la sucursal. Pero si tiene un flujo de trabajo preferido y le ayuda a cambiar el masternombre de la sucursal, hágalo por todos los medios :-)

Prefiero verificaciones sobre convenciones en este caso. Cada equipo contiene miembros que son mejores para iniciar nuevas funciones y otras personas que son mejores para estabilizar las cosas para un lanzamiento.

Si le falta este último, las revisiones de código ayudarán (a menudo, las personas más disciplinadas querrán revisiones de código de todos modos).

Es por eso que configuramos nuestro repositorio de Git (estamos usando Gitlab) para que solo ciertas personas puedan fusionar las solicitudes de extracción y cada desarrollador obtenga su propia bifurcación privada del repositorio principal.

Eso resuelve dos problemas:

1. Los nuevos desarrolladores no pueden cambiar la rama incorrecta (ya que no pueden empujar su trabajo directamente al repositorio principal). Podrían presionar masteren su propio repositorio, pero eso se solucionará cuando llegue la solicitud de extracción.

2. Las convenciones de código se extienden rápidamente por el equipo, ya que cada confirmación es verificada por al menos otra persona que aporta su opinión y conocimiento.

Todo depende del proceso general de desarrollo de software. La gestión de la configuración y cómo se crea una nueva versión no se puede definir sin conocer el proceso general.

Existe la facción "ágil" que optaría por un "área de primer compromiso siempre trabajando". Ejecutarían instalaciones automatizadas de construcción y prueba constantemente en esa área e intentarían tener un sistema de trabajo "en todo momento".

Verían el (maestro) -> (lanzamiento) con quizás una organización de 1,2 pasos intermedios como beneficioso.

Luego está la facción más "clásica", que tiene un proceso impulsado por la planificación y los pasos de integración planificados hacia los hitos, donde un lanzamiento de "unidad de trabajo" es una actividad planificada con requisitos tales como "solo lanzamiento cuando se prueba (unidad) y se supone que encaja con el próximo hito planeado ". Allí, la planificación comprende el control de versiones de "unidades de trabajo" y, por lo general, hacen todo lo posible para definir cómo se supone que será la próxima versión planificada del producto en términos de características y correcciones. En aras de la planificación, quieren saber que lo que un desarrollador lanza es "adecuado" y un acto consciente de cometer una unidad de trabajo.

Ese enfoque clásico no significa necesariamente que haya tiempos más largos en los que no haya disponible una compilación completa del producto.

Entonces, el flujo de trabajo "clásico" sería: (dev) -> (unit) -> (integración) -> (prueba / qa) -> (producción).

El rol del integrador es "aceptar / comprar" unidades lanzadas o rechazarlas si no se ajustan a las necesidades del próximo lanzamiento.

Es, en una nota al margen, también posible mezclar esos 2 enfoques básicos de manera oportuna.

Según mi experiencia (que era principalmente en el área del uso del enfoque "clásico"), el enfoque "clásico" funcionó decentemente bien en proyectos de aproximadamente 4-50 personas en un equipo.