¿Tiene una rama de producción o usa maestro?

13

Trabajo en equipo pequeño con otros desarrolladores remotos en una aplicación Rails . Estamos empezando a modificar nuestro flujo de trabajo git . Hemos pensado en una estructura de bifurcación como la siguiente:

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

Sin embargo, algunos de los desarrolladores pensaron que podría ser menos confuso para los nuevos desarrolladores que podrían impulsar automáticamente la producción en master. En su lugar, pensaron en 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, el maestro siempre debe implementarse para la producción.

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

    
pregunta 09.04.2015 - 16:16

4 respuestas

16

Este enfoque no tiene ventajas ni desventajas. La razón por la que digo esto es simple: para Git, no hay ninguna diferencia si se desarrolla desde master o release de master. Ni siquiera necesitas liberar ramas; podría etiquetar un compromiso arbitrario y liberar eso, en su lugar.

El problema real aquí es uno de proceso y procedimiento. Mientras más desarrolladores avanzados se preocupen de que hacerlo de una manera confunda, los desarrolladores más nuevos deben estar preparados para invertir el tiempo para explicar qué es el modelo de lanzamiento y por qué es así.

Mientras todos entiendan que el maestro es para el desarrollo, y que otra rama arbitraria es para los lanzamientos, y el trabajo para mantener esto se hace , entonces no debería ' No hay ningún problema con este enfoque.

    
respondido por el Makoto 09.04.2015 - 17:08
9

Puedo ver tu dilema. También lo tuve, hasta que desaprendí lo que siempre supuse sobre el maestro.

  

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

De la documentación / libro de Git - ramificación 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 que el comando git init lo crea de forma predeterminada 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 acerca de master . Incluso podría considerar cambiar el nombre de master para que diga prod y usar un flujo de trabajo como el siguiente:

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

Aquí es cómo cambia el nombre de la rama maestra .

NO estoy diciendo que deba cambiar el nombre de la rama master . Pero si tienes un flujo de trabajo preferido y te ayuda a cambiar el nombre de la rama master , hazlo por todos los medios :-)

    
respondido por el Sumeet Pareek 09.04.2015 - 17:34
6

Prefiero los controles sobre las convenciones en este caso. Cada equipo contiene miembros que son mejores en el inicio de nuevas funciones y otras personas que son mejores en estabilizar las cosas para un lanzamiento.

Si no tienes lo último, entonces las revisiones de código te ayudarán (a menudo, las personas más disciplinadas querrán las revisiones de códigos de todos modos).

Es por eso que configuramos nuestro repositorio Git (estamos usando Gitlab) para que solo ciertas personas puedan combinar 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 insertar su trabajo directamente en el repositorio principal). Es posible que presionen a master en su propio repositorio, pero eso se solucionará cuando llegue la solicitud de extracción.

  2. Las convenciones de código se difunden rápidamente en todo el equipo, ya que al menos otra persona verifica cada confirmación que aporta su opinión y conocimiento.

respondido por el Aaron Digulla 09.04.2015 - 16:39
1

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

Hay una facción "ágil" que optaría por una "área de compromiso siempre funcionando". Ejecutarían instalaciones automatizadas de construcción y prueba constantemente en esa área e intentarían tener un sistema operativo "en todo momento".

Verían el (maestro) - > (lanzamiento) con tal vez una organización de 1,2 pasos intermedios como beneficiosa.

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 una versión de "unidad de trabajo" es una actividad planificada con requisitos como "solo versión cuando está ( unidad) probado y se supone que se ajusta al siguiente 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 el aspecto del próximo lanzamiento planificado del producto en términos de características y arreglos. Por el bien de la planificación, quieren saber que lo que un desarrollador lanza es "correcto" 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) - > (unidad) - > (integración) - > (prueba / qa) - > (producción).

El rol del integrador es "aceptar / comprar" unidades liberadas o rechazarlas si no se ajustan a las necesidades de la próxima versión.

En una nota lateral también es posible combinar esos 2 enfoques básicos de manera oportuna.

Desde mi experiencia (que fue principalmente en el área del uso del enfoque "clásico"), el enfoque "clásico" funcionó bastante bien en proyectos de aproximadamente 4-50 personas en un equipo.

    
respondido por el BitTickler 09.04.2015 - 16:46

Lea otras preguntas en las etiquetas