¿Qué sucede si la administración pospone una característica fusionada para desarrollar?

Un enfoque es la característica que lo marca. Puede vivir en el código base, pero puede deshabilitarse por configuración.

Otra opción es hacer una confirmación de reversión que revierta la combinación de características para que no se desarrolle más. Se puede hacer una nueva rama que revierta la reversión, y dejarla pendiente para fusionarse más tarde. Si está utilizando solicitudes de extracción de Github, puede hacerlo fácilmente con el botón "revertir combinación" en una solicitud de extracción combinada.

  

¿Cómo podríamos haber evitado este problema?

Desde una perspectiva de proceso, averigua:

• ¿Quién tomó la decisión para comenzar este trabajo?
• ¿Por qué cambió la decisión de lanzar esta característica?
  • ¿Se perdieron las expectativas?
  • ¿Falta de comunicación?
  • ¿Apoyo empresarial inadecuado?
  • ¿No hay participación del cliente?

Más que probablemente hubo caídas en la comunicación en el camino. Es importante tener esto porque cuando no funciona, su (s) proceso (s) de desarrollo se basarán en entendimientos falsos e incorrectos de los requisitos comerciales.

Olvide por un momento el problema con su administración, e imagine que ya tenía la "función de registro automático" en su última versión de producción, profundamente integrada en su base de código. Ahora obtiene el nuevo requisito de agregar un "interruptor de apagado" para el "registro automático". ¿Cómo manejaría esto en su flujo de trabajo de Git?

Supongo que declararía "deshabilitar el registro automático por configuración" simplemente como una característica adicional (es solo una forma de Alternador de características ), por lo que esto debería integrarse sin problemas en su flujo de trabajo. Puede estimar el esfuerzo, si lo desea, puede usar una rama de características para ello (o no, si no usa ramas de características para tales problemas). Y definitivamente puede usar el flujo de fusión "descrito por el usuario - > test - > master" que describió.

Y esa es realmente la forma en que puedes manejar esto en tu situación actual. Desde el punto de vista del flujo de trabajo de git, no debería importar si la solicitud de cambio proviene de la administración para la versión 1.0, o si la solicitud de cambio es un nuevo deseo del cliente para la versión 2.0.

Este es el problema exacto que tengo con gitflow y GitHub flow, y parece que con las aplicaciones web esto ocurre con frecuencia, o más bien como la norma. Parece que resolvería este problema de forma retroactiva (mencionada anteriormente) o proactivamente (ejemplo a continuación).

He creado 'ramas de paquete' además de las ramas de gitflow estándar. El paquete consta de todas las características que están listas para uat / qa. Se crea una lista de características de uat / qa. Estos se combinan en el paquete temporal, y ese paquete se implementa en uat / qa. Cualquier corrección de errores ocurre en la rama de la característica original, y se vuelve a agregar al paquete y se despliega. Esto separa la próxima versión y permite probar esas características en conjunto antes de que encuentren su camino hacia la rama de desarrollo. Las sucursales que están aprobadas obtienen una solicitud de extracción para desarrollarse, siguiendo el proceso de gitflow. Las funciones preparadas para la prueba se pueden agregar o quitar de la rama del paquete temporal y redistribuido.

• Esto mantiene al maestro siempre reflejando el estado listo para producción (se puede automatizar con gancho)
• Develop siempre refleja el último lanzamiento entregado (y probado) candidato para el próximo lanzamiento

Las desventajas incluyen administrar la lista de paquetes y agregar otro tipo de rama; sin embargo, además de la solución retro, que creo que es demasiado tarde, esta parece ser la solución más viable.

Con un complemento GUI, podría ser óptimo marcar las ramas de características por despliegue de paquete, con la automatización en mente.