Cómo configurar el control de código fuente con múltiples productos, todos ellos dependientes de una única biblioteca de classs

Soy el CTO y el único desarrollador de mi empresa. Me estoy preparando para contratar a nuestro primer desarrollador y posiblemente un segundo dentro de los próximos 6-12 meses. Me avergüenza decir que nunca he usado el control de código fuente como parte de mi flujo de trabajo. Creo que ser un equipo de desarrollo de 1 miembro me ha permitido ser un poco flojo. No es que no quisiera, solo tengo un bloque mental sobre cómo empezar a usarlo.

Tenemos 5 aplicaciones web que construyo y mantengo. Usamos ASP.NET, y cada aplicación web hace reference a una .NET Class Library (DLL) que ha sido copyda en la carpeta "bin" para cada aplicación. He estado desarrollando con una sola "solución" de Visual Studio que incluye la biblioteca de classs y todas las aplicaciones web. Un poco hinchado, estoy seguro, pero este método me ha facilitado la tarea de minimizar los errores al permitirme realizar operaciones globales de búsqueda y reemploop en todas mis aplicaciones (y la biblioteca de classs) al mismo time.

Me doy count de que la implementación del control de código fuente es un gran cambio en mi flujo de trabajo por sí solo, pero también me ha abrumado un poco introducir a otro desarrollador en mi process. Estoy buscando ayuda sobre cómo desarrollar un flujo de trabajo que permita a mi pequeño equipo moverse rápidamente sin processs engorrosos. Me gustaría evitar discusiones sobre qué sistema SCC elegir (vamos a usar Mercurial). Estoy más interesado en discutir la estructura y los aspectos del flujo de trabajo de esto.

Aquí están las preguntas con las que necesito ayuda:

  1. ¿Debería dividir cada aplicación en un "proyecto" separado o mantenerlas juntas para que podamos seguir beneficiándonos de las operaciones globales de búsqueda y reemploop cuando sea necesario? Me preocupa dividirlos por la situación de la biblioteca de la class (ver # 2).

  2. Si divido las aplicaciones en proyectos separados, no estoy seguro de cómo proceder con la biblioteca de classs de la que cada proyecto necesita una copy. Por ejemplo, supongamos que los cambios en una de las aplicaciones (llámalo "proyecto 1") requieren un cambio en la biblioteca de la class … si la biblioteca de la class está en un proyecto separado (llámalo "proyecto 2"), me parece "desorderado" que el proyecto 1 dependa de los últimos cambios en el proyecto 2 para que funcione correctamente. O bien, simplemente realiza los cambios en el proyecto 2 (la biblioteca de classs), los registra y luego copy el dll recién comstackdo en el proyecto 1 (pero no debe grabarse la nueva copy del dll que se está copyndo en el proyecto 1). el SCC de alguna manera). Me estoy confundiendo incluso mientras escribo esto …

Gracias de antemano por tu ayuda.

Primero, felicidades por decidir finalmente usar el control de fuente. Sé que cambiar tus hábitos puede ser frustrante, pero a la larga estoy seguro de que verás los beneficios.

  1. No hay nada de malo con una solución que tiene múltiples proyectos. Generalmente mantengo los míos alnetworkingedor de 10, pero eso es simplemente para mejorar los times de carga. Si mantenerlos juntos funciona mejor para usted, déjelo así. El uso del control de fuente no tendrá ningún efecto sobre esto.
  2. En cuanto a la biblioteca de la class, creo que lo que debe hacer es cambiar la forma en que realiza los cambios en el proyecto de la biblioteca en lugar de cómo utiliza los proyectos que hacen reference a ella. Implemente testings unitarias en el proyecto de la biblioteca para imponer la compatibilidad con versiones anteriores, para que sepa que eliminar la última versión de la biblioteca no romperá su aplicación. Es probable que descubra que esto no será cierto algunas veces, pero a medida que desarrolle más testings unitarias para manejar casos extremos, esto ocurrirá cada vez less.

Puede tener múltiples proyectos en una sola solución de Visual Studio. Lo que he hecho en el pasado es tener el proyecto ASP.NET y el proyecto de biblioteca de class en la misma solución. Puede hacer que su proyecto ASP.NET haga reference al proyecto de biblioteca de class (Agregar reference y luego vaya a la pestaña Proyectos para mostrar otros proyectos en la misma solución). De esta forma, cada vez que cambie la biblioteca de classs, la aplicación ASP.NET se comstackrá utilizando la última versión de la biblioteca de classs. Puede configurar múltiples soluciones, una para cada aplicación ASP.NET con cada solución, incluido el proyecto de biblioteca de class.

También podría configurar una solución grande con todos sus proyectos ASP.NET, así como con su biblioteca de classs, pero puede ser un poco difícil trabajar con ella, especialmente con múltiples desarrolladores que trabajan en las diferentes páginas ASP.NET.