git flujo de trabajo con una complicación

Trabajo en un equipo pequeño que desarrolla un producto que trata con una gran cantidad de datos costosos. Debido al costo asociado con estos datos, no es posible probar el código localmente. En cambio, tenemos un server de producción que nuestros clientes ven, y un server intermedio que utilizamos para probar. Del mismo modo, tenemos una twig que coincide con la producción (estamos usando "master") y una twig que combina la puesta en escena (llamada "puesta en escena").

He realizado una buena búsqueda sobre el tema de los flujos de trabajo de git, pero todos parecen suponer que el equipo se agita en alguna twig de desarrollo (tal vez directamente, o tal vez utilizando twigs de características que se fusionan). Y cuando todo en esa twig es bueno, se fusiona en la twig de producción (tal vez a través de una twig de "lanzamiento" primero) y el process se repite. Esta es la forma en que funciona el popular exitoso model de ramificación de Git .

El problema es que nuestra twig de "etapas" (que es lo más cercano que tenemos a la twig de "desarrollo" en el Modelo de ramificación de Git exitoso antes mencionado) regularmente tiene un código que se encuentra en varias etapas de compleción. Debido a que no podemos probar nuestro código localmente, el código incompleto o roto a menudo termina en la twig de etapas, por lo que puede probarse contra la ridícula cantidad de datos que nuestra aplicación maneja en el server de transición. No podemos esperar a que todo en la twig de etapas esté completamente listo, probado y funcionando antes de lanzar cosas a la producción.

Entonces, ¿cuál es la mejor manera de manejar esto? Hasta ahora, he experimentado con:

  1. Las twigs de function se basan en la twig de "etapas" que se puede fusionar en la puesta en escena y luego se puede seleccionar para dominar cuando esté list.
  2. Feature branches que se combinan en etapas para probar y se fusionan en master cuando están listos. No estoy seguro de si es mejor basar estas twigs en una puesta en escena o maestra …

De cualquier manera, he estado consiguiendo conflictos de fusión donde realmente no hay conflictos porque la historia se está volviendo loca. Eso es un poco molesto ¡Debe haber una mejor manera de hacer esto!

En cualquier caso, corres el riesgo de comprometerte en la puesta en escena interactuando entre sí de una manera que no sucederá en la producción porque no estás moviendo todos los commits en la puesta en escena para dominar juntos, pero has estado probándolos en puesta en escena juntos.

Creo que git lo hace difícil porque no es una buena idea: – / ¿Qué pasa con el uso de la function de volteo para que cierta funcionalidad solo esté activa en el entorno de transición, pero el código puede enviarse a producción en cualquier momento? Esto requerirá un cambio en la forma en que su equipo piensa en hacer el desarrollo. En lugar de cambiar el código existente, a veces deberá agregar una ruta paralela a través de la aplicación que utiliza nuevas funciones que eventualmente replaceán las funciones existentes al por mayor.