Nuestra política al entregar una nueva versión es crear una rama en nuestro VCS y manejarla a nuestro equipo de control de calidad. Cuando este último da luz verde, etiquetamos y lanzamos nuestro producto. La rama se mantiene para recibir (solo) correcciones de errores para que podamos crear versiones técnicas. Esas correcciones de errores se fusionaron posteriormente en el tronco.¿Cómo maneja la tensión entre la refactorización y la necesidad de fusionarse?
Durante este tiempo, el tronco ve el trabajo de desarrollo principal y está potencialmente sujeto a cambios de refactorización.
El problema es que hay una tensión entre la necesidad de tener un tronco estable (para que la combinación de correcciones de errores tenga éxito - por lo general no puede si el código ha sido extraído a otro método o movido a otra clase) y la necesidad de refactorizarlo al introducir nuevas funciones.
La política en nuestro lugar es no hacer ninguna refactorización antes de que pase suficiente tiempo y la rama sea lo suficientemente estable. Cuando este es el caso, uno puede comenzar a hacer cambios de refactorización en el tronco, y las correcciones de errores se deben confirmar manualmente tanto en el tronco como en la rama.
Pero esto significa que los desarrolladores deben esperar bastante tiempo antes de comprometerse en el tronco cualquier cambio de refactorización, ya que esto podría romper la fusión posterior de la rama al tronco. Y tener que portar manualmente errores de la rama al tronco es doloroso. Me parece que esto dificulta el desarrollo ...
¿Cómo manejas esta tensión?
Gracias.
Eh, esto no es ni siquiera una respuesta, por no hablar de la respuesta ... – Benjol