Dividir una solución .NET / Repo Git para múltiples aplicaciones

Actualmente tengo una solución única que contiene tanto la única aplicación desarrollada hasta el momento como proyectos para todas las bibliotecas locales. Toda esta solución también se guarda en un único repository Git. Ahora voy a desarrollar una segunda aplicación que hará uso de esas mismas bibliotecas. Esa aplicación tendrá diferentes ciclos de lanzamiento que la primera y diferentes versiones. La pregunta (o preguntas) que tengo es cómo dividir el código, tanto en términos de la configuration de la solución como en términos de Git.

Algunos otros detalles útiles antes de hablar sobre las respuestas:

  1. Las aplicaciones se implementan en una unidad de networking compartida, no en computadoras individuales, por lo que tengo control completo sobre cuándo se implementan y qué se implementa con ellas.
  2. Los files DLL de la biblioteca no son compartidos por las aplicaciones una vez construidas. Cada aplicación tiene en su carpeta una copy completa de todas las DLL, PDB y files de configuration.
  3. Actualmente, soy el único que hace lanzamientos, pero otros uno o dos pueden terminar lanzando, así que me gustaría tener eso en count.

He estado planteando un par de ideas en mi cabeza, pero ninguna de ellas parece satisfactoria. Consideré mantener todo en una sola solución / un repo de Git. También he pensado en dividir la solución en varios repositorys Git utilizando submodules, pero los submodules son engorrosos. También he pensado en hacer de cada aplicación su propia solución y todas las bibliotecas en otra. La pregunta entonces es si puedo tener múltiples soluciones abiertas en Visual Studio. Con frecuencia, las bibliotecas necesitan cambiar con las aplicaciones, por lo que separarlas demasiado en soluciones separadas o repositorys Git dificultará la synchronization de las bibliotecas y las aplicaciones. Otra preocupación que tengo es la ramificación. Si dividí la solución en varios repositorys Git, puedo tener twigs para cada aplicación, pero si conservo un repository Git, solo puedo tener un set de twigs para todo.

Puede que ni siquiera me esté haciendo las preguntas correctas, y también es posible que tenga un locking mental que me impida resolver una solución simple. De cualquier manera, me remito a la comunidad SO para darme algunas ideas. Espero que todo esté claro, pero si no, estaré encantado de aclararlo.

Si bien pueden ser engorrosos, creo que los submodules son el path a seguir en este caso. Voy a adivinar que la estructura de tu directory es algo así como:

mainapp \mainappdir \somefiles ... | | \library1 | \library2 

En ese caso, querría que library1 y library2 fueran submodules (eso es probablemente obvio). Realmente no son tan malos, solo es algo a lo que acostumbrarse en Git en mi humilde opinión.

Otra ruta a considerar sería vincular simbólicamente library1 y library2 en su sistema de files para el uso de ambas aplicaciones. En ese caso, cada biblioteca podría ser su propio repository pero no administrado con submodules (creo que tendría que agregarlos a su file .gitignore). Mediante el uso de enlaces simbólicos en cada aplicación, la gestión de repos / fuente solo estaría en los dos directorys de la biblioteca. Tirando / ramificando en un lugar tendría efectos en ambas aplicaciones, no requeriría administrar los files de la biblioteca de cada aplicación.

Yo dividiría todo en soluciones separadas, especialmente las bibliotecas que se usarán en múltiples aplicaciones. Como mencionó, las diferentes aplicaciones y bibliotecas tienen diferentes ciclos de publicación y podrían desarrollarse por separado. Depende de usted dividirlos en unidades lógicas y garantizar que las bibliotecas sean independientes de las aplicaciones en las que se utilizarán.

En cuanto a qué hacer en Git, tendría sentido tener repositorys separados para cada unidad de trabajo lógica (aplicación o biblioteca), o al less, twigs separadas dentro del mismo repository.

Buena suerte y no te desanimes. Esto será beneficioso para ti a largo ploop.