Cómo estructurar un VCS con múltiples proyectos dependientes

Estoy seguro de que este es un problema común que otros han resuelto antes, así que estoy recurriendo a la sabiduría colectiva de otros desarrolladores / gerentes de proyectos por ahí para get ayuda.

Tengo varios proyectos:

  • Solicitud
  • Aplicación Web
  • ServerApp
  • Dev Utils
  • ORM

Todas las aplicaciones / utilidades dependen del ORM: cuando el ORM cambia, debe comstackrse y todas las aplicaciones deben comstackrse de nuevo y luego desplegarse. En este momento, mi estructura de VCS es una especie de revoltijo:

  • Nombre de la aplicación
    • El maletero
      • Solicitud
      • Aplicación Web
      • ServerApp
      • Dev Utils (alnetworkingedor de 4 carpetas en este momento, pero en crecimiento)
      • ORM
    • Relase
      • ProjectName (ya sea aplicación o aplicación web) version.number
    • Sucursales
      • ExperimentName_DevName

Idealmente, me gustaría tener una carpeta raíz por aplicación (Aplicación / Aplicación web / ORM, etc.), cada una con su propio Troncal / Sucursales / Versiones, etc. para separarlos lógica y físicamente. Mi razonamiento es que debido a que se realiza mucho trabajo en la aplicación, y se publica mucho más a menudo, cada twig de publicación tiene copys idénticas de los mismos progtwigs de utilidad, etc. También revisar el tronco para trabajar en él siempre significa que todos los demás proyectos vienen para el viaje.

Sin embargo, la separación significaría desmantelar ciertos proyectos de soluciones y hacer que la modificación de cualquier proyecto sea simultáneamente dolorosa, saltando entre 2-3 IDEs (especialmente al realizar cambios en el ORM).

Estoy pensando en esto porque muy pronto estoy armando una máquina de CI (prepárate para preguntas sobre eso en una semana más o less) y estoy tratando de encontrar la manera de tener las versiones creadas / implementadas automáticamente. Normalmente, solo se despliega la Aplicación, mediante copy de script en el server donde todas las estaciones de trabajo extraen desde el inicio, pero como dije antes, si el ORM cambia / publica, todas las otras aplicaciones deberían volver a comstackrse e implementarse.

(Hoy rompí nuestro website y 3 utilidades porque cambié el ORM y lo implementé con una versión actualizada de la Aplicación, pero me olvidé de rebuild / implementar las otras aplicaciones con el nuevo ORM – ¡vaya!)

Ponte en los zapatos de tu desarrollador. Esto no debería ser difícil porque parece que eres uno de ellos 🙂 Observa el layout de control de la versión no desde el punto de vista arquitectónico, sino desde el punto de vista de la usabilidad. Pregúntese: a diario, ¿cuáles son las cosas más comunes que nosotros, como desarrolladores, hacemos con nuestro código fuente? Piense específicamente con respecto a sus interacciones con su sistema VCS y los layouts del proyecto. Quieres que las cosas comunes con muerte cerebral sean fáciles. Está bien que los casos de uso less comunes sean más difíciles de conseguir, siempre y cuando tengas un logging de cómo hacerlo, de modo que cuando (¡no si!) La gente olvide, sabrán dónde search para recordarse a sí mismos cómo .

He visto muchos layouts de VCS que intentan ser arquitectónicamente "perfectos", pero terminan causando un sinfín de problemas y dolores de cabeza desde el punto de vista del uso cotidiano. No estoy diciendo que los dos no pueden coincidir y que se combinen bien, solo digo que piensen sobre esto desde el punto de vista de los usuarios, y que esa sea su guía.

Desde el punto de vista de CI, todavía tomaría este enfoque. Incluso si su configuration termina siendo más compleja de definir en su CI de elección, solo tiene que hacer la configuration allí una vez. Si el layout es fácil de usar durante el desarrollo, la mayor parte de la configuration de su IC también debería ser relativamente fácil. Luego, simplemente concéntrate en los últimos bits que tomarán más time.

Dividir su base de código en diferentes "proyectos" puede ser muy difícil. Hemos hecho esto en cada límite "desplegable" por separado. Incluye una capa de "plataforma" que es común / usada por los otros, como un proyecto separado. Pero esto tampoco es perfecto.

Lo único que no puedo enfatizar lo suficiente es que uno necesita tener algún tipo de regresión / testing continua que se ejecuta después de las comprobaciones y antes de que realmente implementes algo. Además, un process de "liberación" que incluso podría include algunas testings manuales puede ser útil y definitivamente ha evitado algunas situaciones de aparición de huevos. (Mejor lanzarlo un par de días tarde que roto).

(Perdón por no abordar su problema directamente)