Mejores prácticas para control de fuente y corrección de errores

Question

Si necesitamos emitir un parche de error que no incluye el desarrollo actual que se ha confirmado, o cualquier cambio de su versión actual, qué se debe hacer para que el proceso sea más seguro y con menor ¿gastos generales?

Actualmente utilizamos Subversion para nuestro control de fuente en un equipo pequeño (3 desarrolladores) que se desarrolla principalmente en Visual Studio 2008. Anticipamos que el equipo puede agrupar a 8 desarrolladores durante el próximo año, y para cualquier versión anterior compatible con volverse más complicado Si bien la mayoría de los clientes están en la versión actual, algunos están más atrás.

Answer 1

El control de fuente puede manejar esto con bastante facilidad, y fue diseñado para esto.

Cuando llegue al período de estabilización de su lanzamiento, debe realizar una ramificación. Es importante que no inicie ningún trabajo en la próxima versión antes de que esto se haga.

Cualquier corrección de errores para esa versión debe hacerse en esa rama. Esto evita que un nuevo código de una próxima versión contamine la corrección de errores. Una vez que se ha corregido el error, puede fusionar ese cambio en el enlace troncal y en cualquier otro lanzamiento según sea necesario.

No olvide poner el número de error en el comentario, ya que esto hará que sea más fácil hacer un seguimiento de las confirmaciones.

Answer 2

Qué tal: una rama por versión principal, con correcciones de errores aplicadas a la (s) rama (s) según sea necesario, y también aplicadas (o fusionadas) de nuevo al tronco.

Answer 3

Donde trabajo, tenemos varios proyectos trabajando simultáneamente. Para evitar este problema, tenemos varias variantes del código fuente. Por ejemplo, la primera versión es la variante 1.0. Creamos una rama de esta versión, por ejemplo, Variant 2.0, para todos los desarrollos futuros. Si necesitamos hacer una corrección de errores, lo hacemos en la Variante principal, que actualmente es 1.0 y podemos lanzar eso. Cuando la Variante 2.0 está lista para pasar a producción, la fusionamos con lo que está en la rama principal (en este caso, 1.1) y se convierte en la nueva troncal principal. En un punto, teníamos 4 sucursales funcionando al mismo tiempo.

Combinar el código puede llevar mucho tiempo, y debe tener cuidado de no introducir nuevos errores durante la fusión, pero si tiene una herramienta de comparación de código decente disponible, entonces no debería ser tan malo. Hicimos una fusión hace un tiempo utilizando Beyond Compare en un directorio de origen de 10.000 archivos, y tomó una sola mañana.