Las mejores prácticas para el control de la fuente y la corrección de errores

Question

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

Actualmente estamos utilizando Subversion para nuestro control de código fuente en un equipo pequeño (3 desarrolladores) que se desarrolla principalmente en Visual Studio 2008. Prevemos que el equipo puede agrupar a 8 desarrolladores durante el próximo año, y que cualquier soporte de lanzamiento anterior se convierta en más complicado. Mientras que la mayoría de los clientes están en la versión actual, algunos están más atrasados.

Answer 1

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

Cuando alcances el período de estabilización de tu lanzamiento, deberás hacer una rama. Es importante que no comience ningún trabajo en la próxima versión antes de que se haga esto.

Cualquier corrección de errores para esa versión debe hacerse en esa rama. Esto evita que el nuevo código de una próxima versión contamine la corrección de errores. Una vez que se haya solucionado el error, puede combinar ese cambio en el tronco y cualquier otra versión según sea necesario.

No te olvides de poner el número de error en el comentario, ya que esto facilitará el seguimiento de las confirmaciones.

Answer 2

Qué tal: una rama por versión principal, con correcciones de errores aplicadas a las ramas 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 Variant 1.0. Creamos una rama a partir 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 Variant 2.0 está lista para comenzar la producción, la fusionamos con lo que esté en la rama principal (en este caso, 1.1) y se convierte en el nuevo troncal principal. En un momento dado, teníamos 4 sucursales ejecutándose al mismo tiempo.

La fusión del código puede llevar mucho tiempo, y debes tener cuidado de no introducir nuevos errores durante la fusión, pero si tienes disponible una herramienta de comparación de códigos decente, no debería ser tan malo. Hicimos una fusión hace un tiempo usando Beyond Compare en un directorio de origen de 10.000 archivos, y tardamos una sola mañana.