Diseño de gran proyecto: agregar nueva función en múltiples subproyectos

13

Quiero saber cómo gestionar un gran proyecto con muchos componentes con sistema de gestión de control de versiones.

En mi proyecto actual hay 4 partes principales.

  1. Web
  2. Servidor
  3. Consola de administración
  4. Plataforma.

La parte web y del servidor usa 2 bibliotecas que escribí. En total hay 5 repositorios git y 1 repositorio mercurial. El script de compilación del proyecto está en el repositorio de la plataforma. Automatiza todo el proceso de construcción.

El problema es que cuando agrego una nueva característica que afecta a múltiples componentes, tengo que crear una rama para cada uno de los repositorios afectados. Implementar la característica. Fusionarlo de nuevo. Mi instinto es "algo está mal".

Entonces, ¿debería crear un único repositorio y poner todos los componentes allí? Creo que la ramificación será más fácil en ese caso. O simplemente hago lo que estoy haciendo ahora. En ese caso, ¿cómo resuelvo este problema de crear una rama en cada repositorio?

version-control branching configuration-management merging Shiplu Mokaddim
fuente
¿Puede reorganizar su funcionalidad para colocar la mayor cantidad posible en bibliotecas compartidas (gemas de Ruby, huevos de Python, beans Java, etc.) y luego ensamblar las partes con la idea de "componer" cada elemento de las bibliotecas?
Narfanator
Piense en cuándo agregamos un nuevo soporte de protocolo en el componente Servidor. También debemos agregar controles de interacción adecuados (botones, campos, etc.) para esto también en la web.
Ese es
1
Eso suena como si fuera análogo al patrón de "puente"; podrías inspirarte en eso.
Narfanator
un repositorio para gobernarlos a todos
Steven A. Lowe

Respuestas:

8

En la situación que describe, no obtiene ningún beneficio de tener múltiples repositorios, pero sí tiene un costo: no puede volver a una versión anterior de un repositorio, y tiene la confianza de que su sistema continuará funcionando. Esto se debe a que su código está estrechamente acoplado en los repositorios. Como la confianza en la capacidad de retroceder es uno de los principales beneficios del control de fuente, esta no es la situación en la que desea estar.

La solución es definir la estructura de su repositorio en función del acoplamiento del código que contiene: si el componente A del proyecto comparte solo interfaces estables con el componente B del proyecto, entonces se pueden colocar en repositorios separados. De lo contrario, deberían ubicarse en el mismo repositorio. Un diseño de repositorio más granular reflejará una arquitectura de sistema mejor factorizada.

Aidan Cully
fuente
2

Si cada uno de sus repositorios son proyectos o bibliotecas independientes, entonces diría que no hay nada intrínsecamente malo en la necesidad de crear ramas de características en cada repositorio al agregar nuevas características que atraviesan los proyectos. Al ser autónomos, cada uno se puede versionar de forma independiente y puede desaprobar las API antiguas.

Pero en su caso particular, parece que sus repositorios podrían no estar agrupando su código de manera efectiva. Si los cambios en el código en un repositorio requieren cambios en otros (dejando de lado la desaprobación), entonces su acoplamiento es demasiado estricto o los repositorios deberían reorganizarse.

Si todos los repositorios son realmente parte del mismo proyecto (no pueden estar solos), entonces tal vez solo debería tener 1 repositorio. (O tal vez 2: el proyecto principal y uno para la funcionalidad genérica / estandarizada).

Alano
fuente