Estructura del código fuente para múltiples proyectos

Fondo:

3-5 progtwigdores trabajando con TFS. Admitimos aplicaciones henetworkingadas y también creamos nuevas aplicaciones. Estoy implementando elementos de entrega continua y quiero tener una buena estructura para empezar. En la actualidad, existe muy poca interdependencia entre las aplicaciones, pero en el futuro habrá algunos componentes compartidos.

Planeo implementar una estrategia de bifurcación de "enlace único" (en otras palabras, SIN DENOMINACIÓN) excepto en el muy raro caso en que se requiera una larga twig de funciones, que trabajaré para garantizar que nunca suceda.

Pregunta:

Dado esto, ¿qué estructura de código fuente es mejor y por qué? ¿Hay algún impacto material en elegir uno sobre el otro (espacios de trabajo, etc.)?

SINGLE PRINCIPAL SUCURSAL

$/MAIN/src/ApplicationA/ApplicationA.sln $/MAIN/src/ApplicationA/Project1.csproj $/MAIN/src/ApplicationA/Project2.csproj $/MAIN/src/ApplicationB/... $/MAIN/src/ShanetworkingModule/... 

vs. PRINCIPAL SUCURSAL POR APLICACIÓN

 $/ApplicationA/MAIN/src/ApplicationA.sln $/ApplicationA/MAIN/src/Project1.csproj $/ApplicationA/MAIN/src/Project2.csproj $/ApplicationB/MAIN/src/... $/ShanetworkingModule/MAIN/src/... 

En mi experiencia, descubrí que es mejor usar twigs separadas para cosas que tienen ciclos de desarrollo separados.

Si va a lanzarlos siempre juntos como un package único y se desarrollan como un solo producto, una sola twig principal es más apropiada.

Si cada aplicación se puede lanzar en diferentes momentos, la twig principal por aplicación parece ser más apropiada.

Me gusta desarrollar todo el código en una sola twig principal. Luego use una configuration para esencialmente deshabilitar el module para producción y habilitarlo para la testing hasta que esté listo para su lanzamiento. El beneficio adicional es que los modules (dlls) ya están empaquetados para el lanzamiento, ya que se publica temprano y con frecuencia.