Git workflow para desarrollo mobile

Entonces, comenzamos a usar el flujo de trabajo de gitflow con nuestro lado del server así como con el desarrollo mobile. Funciona muy bien con el código del lado del server, ya que hay cobertura de testing y con la automation de compilation, las twigs de características se fusionan en la twig de desarrollo tan pronto como se testingn bien. A diferencia del desarrollo mobile, dado que los cambios se publican tan pronto como lo desee (no hay time para implementarlos aparte de la compilation y las testings), puede probar rápidamente si hay algún error en el código que presionó y realizar cambios rápidamente. Por lo tanto, este flujo de trabajo funciona realmente genial para el desarrollo del lado del server. Sin embargo, estamos enfrentando problemas con el desarrollo mobile con este flujo de trabajo.

Con el flujo de trabajo de gitflow, tenemos tres twigs persistentes, a saber, desarrollo, assembly y master. El código de la twig principal va a nuestra aplicación Play Store, tenemos otra aplicación beta beta de Google Play Store para la puesta en escena que solo está disponible para los miembros de nuestro equipo y utilizamos crashlytics beta para distribuir el último código de twig de desarrollo solo a los desarrolladores de nuestro equipo. Cada vez que alguien comienza a trabajar en una nueva function, esa persona crea una twig de características bifurcada de maestra (anteriormente solíamos bifurcarla del desarrollo) y una vez que la característica está list, crea una request de extracción en desarrollo. Todos los días, revisamos las requestes de extracción y las que están bien se fusionan en el desarrollo.

Ahora hay dos problemas principales que enfrentamos con este flujo de trabajo. Una es que supongamos que fusionamos alguna característica en el desarrollo y luego descubrimos que hay muchos errores en ella. Ahora no puede avanzar más, todo el ciclo de desarrollo está estancado porque ese código ya está fusionado con el desarrollo. Esta es la razón por la que comenzamos a bifurcar twigs de características desde el maestro en lugar del desarrollo, ya que al less las twigs de características individuales tendrán un código completamente funcional. Una forma es que cada característica se puede distribuir por separado a los miembros del equipo para probar y solo luego se fusionará con el desarrollo, pero es muy engorrosa. Entonces, ¿se puede resolver este problema con un flujo de trabajo diferente?

Otro problema es con conflictos en el código. Dado que el código base con cada twig de características es de la twig principal y debe fusionarse con el desarrollo, hoy en día existen muchos conflictos. Antes, cuando solíamos pasar del desarrollo, solíamos fusionar regularmente la twig de desarrollo con twigs de características en las que la gente está trabajando, por lo que no había conflictos, pero ya no podemos hacer eso. Entonces, ahora, para solucionar conflictos, creamos otra twig temporal desde la twig de características con la que fusionamos el código de desarrollador, arreglamos conflictos y lo ponemos como petición de extracción, que de nuevo es un poco engorroso.

Todo esto parece un problema con el flujo de trabajo de gitflow que no se adapta bien al desarrollo mobile. ¿Existe un mejor flujo de trabajo para el desarrollo mobile que las personas hayan adoptado o incluso algunas prácticas que se pueden seguir para resolver estos problemas?

SpitFlow

Hay opiniones opuestas sobre esto debido a las conversaciones que tuve con los ingenieros de testing. Su experiencia puede ser diferente.

Considere cuándo los desarrolladores apropiados podrían bifurcar toda la base de código y trabajar en sus características en sus propias horquillas.

Cuando estén listos, se fusionarán en sus propias twigs de desarrollo, lo que desencadenará una nueva compilation en el cuadro de IC específico para que los usuarios desarrollen la twig. Sí, una compilation separada por usuario por twig de desarrollo. Las comstackciones de funciones nocturnas estarán en manos de probadores (de características) sin atascarse con la revisión del código.

Pros

  • Todavía puede seguir gitflow a la T sin introducir otra twig 'alpha' o 'BUT' (twig bajo testing) Gitflow y testing / deployment

  • Está limpio y aislado (el código no interferiría con la twig de desarrollo estable)

  • La function puede entrar en las manos de los evaluadores sin tener que pasar por el comité de personas que revisan el código.
  • La retroalimentación del probador podría eliminar las características de errores (sin molestar a otros desarrolladores)
  • Una function / repository bifurcado podría ser una oportunidad para que los desarrolladores brillen ya que la construcción podría llegar a las manos de los interesados ​​que pueden adorar una característica que puede no haber sido sancionada por el comité del equipo de desarrollo / producto.
  • Omita la burocracia para crear nuevas y divertidas funciones sin 'aprobación'.

Contras

  • ¿Podría introducir conflictos con los propietarios del producto que lo aprobaron?
  • Cuando el código es 'aprobado' por los evaluadores de características, todavía necesita una PR para volver a la revisión del código de origen / desarrollo + y luego volver a realizar más testings de QA.
  • Ancho de banda adicional devops necesario para configurar scripts para escupir nuevas comstackciones.
  • Los desarrolladores deben mantener sus twigs de desarrollo sincronizadas / actualizadas con el origen / encabezado de desarrollo.
  • Posibilidad de mayores conflictos de fusión cuando trabajas solo por más time.
  • Fomentar la competencia (no siempre es algo malo).
  • ¿Otros?

Si los inconvenientes superan a los profesionales, entonces esto no es para ti. Considere que podría tratarse de un ticket temporal para una function específica y luego puede 'volver' a gitflow.

Sugerencia 2

Haga que los desarrolladores creen la function en el teléfono de probadores sin saltar tantos aros de gitflow.