24 votos

¿Cómo manejar la tensión entre la refactorización y la necesidad de la fusión?

Nuestra política, cuando la entrega de una nueva versión de crear una filial en nuestro VCS y manejarlo a nuestro equipo de control de calidad. Cuando éste se da la luz verde, se etiqueta y la liberación de nuestro producto. La rama se mantiene a recibir (sólo) las correcciones de errores, de modo que podemos crear boletines técnicos. Esas correcciones que posteriormente se fusionaron en el tronco.

Durante este tiempo, el tronco se considera que la principal labor de desarrollo, y está potencialmente sujeto a la refactorización de cambios.

El problema es que hay una tensión entre la necesidad de tener una estable tronco (de modo que la combinación de correcciones de errores éxito-por lo general no se puede si el código ha sido por ejemplo, extraído de otro método, o se mueve a otra clase) y la necesidad de refactorizar cuando la introducción de nuevas características.

La política en nuestro lugar, es no hacer ninguna de refactorización antes de que haya pasado suficiente tiempo y la rama es lo suficientemente estable. Cuando este es el caso, uno puede empezar a realizar la refactorización de cambios en el tronco, y los fallos se van a ser manualmente cometidos en tanto el tronco y la rama.

Pero esto significa que los desarrolladores deben esperar bastante tiempo antes de comprometerse en el tronco de las refactorización cambio, porque esto podría romper la posterior fusión de la rama al tronco. Y tener que manualmente puerto de los errores de la rama al tronco es doloroso. A mí me parece que esto dificulta el desarrollo...

¿Cómo manejar esta tensión?

Gracias.

15voto

Simon Puntos 14656

Este es un verdadero problema práctico. Se pone peor si usted tiene varias versiones que usted necesita para apoyar y se han diversificado para cada uno. Incluso, peor aún, si usted tiene un verdadero R&D de la rama.

Mi preferencia era para permitir que el tronco principal para proceder a su velocidad normal y no sostener, porque en un entorno donde la liberación de los tiempos eran importantes comercialmente yo nunca podría argumentar que el caso que nos debería permitir que el código para estabilizar ("¿qué, quieres decir que lo publicó en un estado inestable?").

La clave fue asegúrese de que la unidad de pruebas que fueron creados para las correcciones de errores se han pasado todo cuando el fallo se ha convertido en la rama principal. Si el nuevo código cambios son realmente acabo de volver de factoring, a continuación, las pruebas antiguas debería funcionar igual de bien. Si los cambios son de tal magnitud que ya no son válidos, entonces usted no puede apenas puerto de corregir en cualquier caso, y usted necesitará tener a alguien que pensar mucho acerca de la corrección en el nuevo código de secuencia.

Después de unos cuantos años, la gestión de este tipo de problema, llegué a la conclusión de que probablemente necesitará 4 código de los arroyos en un mínimo para proporcionar la adecuada cobertura y apoyo, y una colección de bastante rigurosos procesos para gestionar el código a través de ellos. Es un poco como el problema de ser capaz de dibujar cualquier mapa en 4 colores.

Nunca he encontrado ninguna realmente buena literatura sobre este tema. Inevitablemente estará vinculado a su estrategia de liberación y el Sla que se firma con sus clientes.

Addendum: también debo mencionar que fue necesario para escribir la rama de la fusión como hitos específicos en la programación de la versión de la rama principal. No subestimar la cantidad de trabajo que puede suponer en traer sus ramas juntos, si usted tiene una colección de duro trabajo a los desarrolladores a hacer su trabajo de implementar características.

5voto

Jonik Puntos 18905

Donde yo trabajo, creamos temporal, de corta duración (menos de un día, un par de semanas) ramas de trabajo para todos los no-trivial de cambio (característica agregar o corrección de errores). El tronco es estable y (idealmente) potencialmente desmontable con todo el tiempo; sólo hecho de elementos se combinan en ella. Todo lo que se ha comprometido desde el tronco en la que se combina el trabajo de las ramas de cada día; esto puede ser en gran parte automatizado (utilizamos Hudson, la Hormiga y la Subversión). (Este último punto porque es generalmente mejor para resolver los conflictos que más temprano que tarde, por supuesto).

El modelo actual utilizamos fue influenciado en gran medida por un excelente artículo (que me he conectado antes) de Henrik Kniberg: Control de versiones para Varios Equipos Ágiles.

(En nuestro caso, tenemos dos scrum equipos que trabajan en una base de código, pero he llegado a pensar que este modelo puede ser beneficioso incluso con uno de los equipos.)

Hay cierta sobrecarga sobre el extra de ramificación y la fusión, pero no demasiado, de verdad, una vez que te acostumbras a él y conseguir mejor con las herramientas (por ejemplo svn merge --reintegrate es práctico). Y no, yo no crear una temp rama de siempre, por ejemplo, para los más pequeños, de bajo riesgo refactorings (no relacionadas con los principales elementos que se encuentran en trabajo) que puede ser fácilmente completado con un commit al tronco.

También contamos con una versión anterior de la rama en la que crítica corrige los errores de vez en cuando. Hay que reconocer que puede ser manual (a veces tedioso) combinar el trabajo si alguna parte del código ha evolucionado en el tronco de manera significativa en comparación con la rama. (Es de esperar que se convierte en un problema menor, a medida que nos movemos hacia liberando continuamente incrementos de tronco (internamente), y dejar de marketing y gestión de producto de decidir si quieren hacer una liberación externa.)

No estoy seguro de si esto contesta a tu pregunta directamente, o si se puede aplicar en su entorno (el otro equipo de control de calidad y todo), pero al menos puedo decir que la tensión que usted describe no existe para nosotros, y somos libres para refactorizar siempre. Buena suerte!

1voto

Dan Puntos 2609

Creo que la tensión puede ser manejado por la adición de ingredientes siguientes a su proceso de desarrollo:

  1. Integración continua
  2. Automatizado de pruebas funcionales (supongo que ya se cuenta con una unidad de pruebas)
  3. Entrega automatizada

Con integración continua, en cada commit implica una generación donde todos los tests se ejecutan y se alarme si algo va mal. Empezar a trabajar más con la cabeza y son menos propensos a la bifurcación del código base.

Con automatizadas pruebas funcionales, que son capaces de probar la aplicación en el clic de un botón. En general, ya que estas pruebas se toman más tiempo, estos se ejecutan por la noche. Con esto, el clásico papel de control de versiones empieza a perder su importancia. Usted no hace su decisión sobre el momento de la liberación según la versión y la fecha de su vencimiento, es más de la decisión empresarial. Si se han aplicado en la unidad y las pruebas funcionales y su equipo es la presentación de prueba de código, de la cabeza siempre debe de estado que puede ser liberada. Los errores son descubiertos de forma continua y fija y de liberación de la entrega, pero esto no es más el proceso cíclico, es el continuo.

Usted probablemente tendrá dos tipos de detractores, ya que esto implica el cambio de algunas de larga raigambre prácticas. En primer lugar, el cambio de paradigma de una entrega continua parece contra-intuitivo para los gerentes. "No podemos arriesgar a enviar un gran error?". Si usted echa un vistazo a Linux o distribuciones de Windows, esto es exactamente lo que están haciendo: empujar versiones hacia los clientes. Y ya que usted cuenta con la suite de pruebas automatizadas, los peligros son aún menor.

Siguiente, equipo de control de calidad o departamento. (Algunos podrían argumentar que el problema es su existencia en sí mismo!) Generalmente se aversión hacia la automatización de pruebas. Significa el aprendizaje de nuevas y a veces complicado de la herramienta. Aquí, lo mejor es predicar con el hacer de ella. Nuestro equipo de desarrollo comenzó a trabajar en continuo integraciones y en el mismo momento de la escritura de la suite de pruebas funcionales con Selenium. Cuando el equipo de control de calidad de sierra de la herramienta en acción, era difícil oponerse a su aplicación.

Finalmente, el thurth es que el proceso que he descrito no es tan simple como addig 3 ingredinents a su proceso de desarrollo. Implica un profundo cambio en la forma de desarrollar software.

1voto

Xavier Nodet Puntos 2498

Tal vez Git (o de otros DVCS) son mejores en el manejo funde a una actualización de código gracias al hecho de que (realmente) administrar los cambios en vez de sólo la comparación de los archivos... Como Joel dice :

Con control de versiones distribuido, las uniones son de fácil y funciona bien. Así que usted puede realmente tener una rama estable y una rama de desarrollo, o crear larga vida a las sucursales para su equipo de control de calidad donde se ponen a prueba las cosas antes de la implementación, o usted puede crear corta ramas de probar nuevas ideas y ver cómo funcionan.

No he probado todavía, aunque...

0voto

Scott Langham Puntos 17447

Donde yo trabajo, seguimos con la refactorización en la rama principal. Si la combina obtener complicado, sólo tienen que ser tratados en una base ad-hoc, todos son capaz de hacer -, pero de vez en cuando tomar un poco de tiempo.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X