¿Cuál es la mejor manera de manejar versiones de productos y ramificaciones de proyectos a largo plazo?

En un sentido general, para proyectos a largo plazo que pueden tener múltiples lanzamientos durante el ciclo de vida de los productos y requieren soporte de productos anteriores, ¿cuál es la mejor manera de manejar versiones de productos y ramificaciones de la base de código?

En un sentido más específico, suponga que existe un control de versión distribuido adecuado (es decir, git) y que los equipos son de tamaño pequeño a grande y que el desarrollador puede estar trabajando en múltiples proyectos a la vez. El problema principal que se enfrenta es que existe una obligación contractual de admitir versiones antiguas tal como existían en ese momento, lo que significa que el nuevo desarrollo no puede parchear el código antiguo (los productos de Microsoft Office podrían ser un ejemplo de esto, solo obtiene parches para el año de la característica que posee).

Como resultado, la versión actual del producto es un poco complicada ya que cada producto principal tiene múltiples dependencias, cada una con sus propias versiones que pueden cambiar entre lanzamientos anuales. Del mismo modo, si bien cada producto tiene su propio repositorio, la mayor parte del trabajo no se realiza en el tronco de la fuente principal, sino en una rama para el lanzamiento de productos de ese año con una nueva rama cuando se lanza el producto para que pueda ser compatible. Esto a su vez significa que obtener la base de código de un producto no es una cuestión simple como uno podría pensar al usar el control de versiones.

La cantidad (y qué tipo de) estructura que necesita depende en gran medida de lo que desea poder hacer. Averigua qué no puedes vivir sin, qué quieres tener y qué no te importa.

Un buen ejemplo de conjunto de decisiones podría ser:

Cosas sin las que no podemos vivir:

• poder reconstruir cualquier versión anterior en cualquier momento
• poder mantener múltiples versiones principales compatibles del producto en cualquier momento

Cosas que nos gustaría tener:

• ser capaz de realizar un desarrollo continuo de características principales (para la próxima versión principal) sin preocuparse por las fusiones de sucursales
• ser capaz de realizar actualizaciones de mantenimiento a versiones anteriores

Cosas que podemos vivir sin:

• respaldo automático de cambios de trabajo actual a versiones pasadas
• nunca interrumpa el desarrollo de funciones importantes, incluso durante unos días o una semana a la vez

Si lo anterior fuera su objetivo, podría adoptar un proceso como este:

1. Realice todo el trabajo de desarrollo en el tronco de su VCS ("maestro" en git)
2. Cuando esté cerca de una versión principal, detenga el desarrollo de funciones importantes y concéntrese en la estabilidad del sistema durante una semana más o menos.
3. Cuando el tronco parece estable, cree una rama para esta versión principal
4. El desarrollo de funciones principales ahora puede continuar en el tronco, mientras que solo se permiten correcciones de errores y preparación de versiones en la rama
5. Sin embargo, todas las correcciones de errores que se deben realizar en la rama se deben probar primero en el tronco; esto asegura que también estarán presentes en todas las versiones futuras
6. Cree una etiqueta (VCS) en la rama cuando esté listo para liberar; Esta etiqueta se puede utilizar para recrear el lanzamiento en cualquier momento, incluso después de un trabajo adicional en la misma rama
7. Ahora se pueden preparar más versiones de mantenimiento para esta versión principal (versiones menores) en la sucursal; cada uno será etiquetado antes del lanzamiento
8. Mientras tanto, el desarrollo de funciones principales orientado hacia la próxima versión principal puede continuar en el tronco
9. Cuando se acerque a esa versión, repita los pasos anteriores, creando una nueva rama de versiones para esa versión . Esto le permite tener múltiples versiones principales, cada una en su propia sucursal, en estado admitido al mismo tiempo, con la capacidad de lanzar versiones menores separadas para cada una.

Este proceso no responderá todas sus preguntas; en particular, necesitará un proceso para decidir qué arreglos se pueden hacer en una rama de lanzamiento y para garantizar que los errores no se corrijan primero en una rama de lanzamiento (tales arreglos siempre debe probarse en el tronco siempre que sea posible). Pero le dará un marco en el cual tomar tales decisiones.

"Largo plazo" es un indicador de que necesita control de versiones, pero no implica ninguna estrategia específica de control de versiones y ramificación. La pregunta más interesante es cuántas líneas de productos o líneas de versiones principales desea admitir (lo que depende del contrato con sus clientes). Al menos necesitará una sucursal por cada línea de producto / línea de versión principal para la que tenga un contrato de mantenimiento.

Por otro lado, depende del tamaño de tu equipo. Si tiene un gran equipo de desarrollo, con diferentes personas trabajando en diferentes características en paralelo, obviamente necesitará más ramas de características que si tiene un equipo de una o dos personas. Si está trabajando con un equipo más grande, debería considerar el uso del control de versiones distribuido, lo que hace que trabajar en paralelo en diferentes ramas (y reintegrarlas más tarde en el tronco) sea mucho más eficiente.

Git es una herramienta de control de versiones: gestiona versiones de archivos. Lo que buscas es una herramienta de administración de configuración. Hay muchos de estos disponibles, pero en su mayoría a altos precios de los gustos de IBM.

Las herramientas de control de versiones proporcionan ramificación y etiquetado, lo que permite una gestión de configuración grosera sin soporte adicional de herramientas, por lo tanto, los desarrolladores no entienden la diferencia. Sus necesidades probablemente se extiendan más allá de lo que GIT está diseñado para hacer.

No tengo conocimiento, pero estoy seguro de que existirá, una adición de herramienta CM para Git.

Esta pregunta parece ser muy similar a otra pregunta que respondí recientemente.

En resumen, esto parece más un problema de diseño y distribución de productos que un problema de control de versiones / ramificación. Por supuesto, es fácil para mí decir eso y más difícil para ti solucionarlo si ya estás metido en el problema.

Sin conocer con mayor detalle los detalles de su problema particular. Sin embargo, en general, si tuviera varias versiones de productos basadas en una base de código que tuviera una gran cantidad de código compartido entre productos, si fuera factible, buscaría refactorizar los productos de una manera que los hiciera más modulares y asegúrese de que los módulos en sí no requieran una ramificación adicional de código. También miraría mi modelo de implementación, para ver si había un mejor medio para apoyar a mis clientes y al mismo tiempo mantener gran parte de la base de código unificada. Cuando se requiere la personalización específica del cliente, puede ser necesaria una mayor granularidad de los módulos para reducir la cantidad de código duplicado en el sistema.

No es una tarea fácil, pero puede arreglarse por etapas si administra bien el trabajo y si puede programar el trabajo para que no necesite "actualizar" todo de una vez.