Si sigues mis recomendaciones a continuación (tengo desde hace años), usted será capaz de:
- poner a cada proyecto en cualquier lugar de control de origen, siempre y cuando se preserve la estructura del directorio raíz del proyecto de abajo
- generar cada proyecto en cualquier lugar en cualquier máquina, con un riesgo mínimo y un mínimo de preparación
- generar cada proyecto totalmente independiente, siempre y cuando usted tiene acceso a sus dependencias binarias ("biblioteca" local y directorios de "salida")
- construir y trabajar con cualquier combinación de proyectos, ya que son independientes
- construir y trabajar con múltiples copias/versiones de un mismo proyecto, ya que son independientes
- evitar llenar su fuente repositorio de control con los archivos o bibliotecas
recomiendo generados (aquí está la carne):
definir cada proyecto para producir un único resultado principal, como por ejemplo un .DLL, .EXE, o. JAR (predeterminado con Visual Studio).
Estructura cada proyecto como un árbol de directorios con una sola raíz.
Cree un script de compilación automatizado para cada proyecto en su directorio raíz que lo compilará desde cero, sin dependencias en un IDE (pero no impida que se construya en el IDE, si es factible).
Considere Nant para proyectos .NET en Windows, o algo similar en base a su sistema operativo, plataforma de destino, etc.
hacen referencia todos los scripts de generación de proyecto sus dependencias (3 ª parte) externos de una sola locales directorio "biblioteca" compartido, con cada uno de esos binarios TOTALMENTE identificado por versión: %DirLibraryRoot%\ComponentA-1.2.3.4.dll, %DirLibraryRoot%\ComponentB-5.6.7.8.dll.
Haga que cada script de construcción de proyecto publique el entregable principal en un solo directorio de "salida" compartido local: %DirOutputRoot%\ProjectA-9.10.11.12.dll, %DirOutputRoot%\ProjectB-13.14.15.16.exe.
Haga que cada script de compilación de proyecto haga referencia a sus dependencias a través de rutas absolutas configurables y totalmente versionadas (consulte más arriba) en los directorios "biblioteca" y "salida", Y NO EN DONDE MÁS.
NUNCA deje que un proyecto haga referencia directamente a otro proyecto o cualquiera de sus contenidos, solo permita referencias a los entregables primarios en el directorio de "salida" (vea arriba).
Haga que cada referencia de script de compilación de proyecto sea necesaria mediante una ruta absoluta configurable y completamente versionada: %DirToolRoot%\ToolA\1.2.3.4, %DirToolRoot%\ToolB\5.6.7.8.
Haga que cada fuente de referencia de script de compilación de proyecto tenga una ruta absoluta en relación con el directorio raíz del proyecto: ${project.base.dir}/src, ${project.base.dir}/tst (la sintaxis varía según la herramienta de compilación).
requieren siempre una escritura de la estructura del proyecto para hacer referencia CADA archivo o directorio a través de una ruta absoluta, configurable (con raíz en un directorio especificado por una variable configurable): ${project.base.dir}/some/dirs o ${env.Variable}/other/dir.
Nunca permita que un script de construcción del proyecto para hacer referencia a cualquier cosa con una ruta relativa como .\some\dirs\here o ..\some\more\dirs, utilice siempre rutas absolutas.
NUNCA permita que un script de compilación de proyecto haga referencia a ALGUNO usando una ruta absoluta que no tenga un directorio raíz configurable, como C:\some\dirs\here o \\server\share\more\stuff\there.
Para cada directorio raíz configurable al que hace referencia un script de compilación de proyecto, defina una variable de entorno que se utilizará para esas referencias.
Intente minimizar el número de variables de entorno que debe crear para configurar cada máquina.
En cada máquina, cree un script de shell que defina las variables de entorno necesarias, que son específicas de esa máquina (y posiblemente específicas de ese usuario, si corresponde).
NO ponga la secuencia de comandos de shell de configuración específica de la máquina en el control de fuente; en su lugar, para cada proyecto, envíe una copia del script en el directorio raíz del proyecto como una plantilla.
REQUIERE cada script de construcción del proyecto para verificar cada una de sus variables de entorno, y cancele con un mensaje significativo si no están definidas.
REQUIERE cada script de compilación de proyecto para verificar cada uno de sus ejecutables de herramienta de compilación dependientes, archivos de biblioteca externa y archivos entregables de proyecto dependientes, y cancele con un mensaje significativo si esos archivos no existen.
resistir la tentación de cometer cualquier archivo generado en el control de la fuente - no entregables del proyecto, sin fuente generado, sin documentos generados, etc.
Si utiliza un IDE, generar archivos de cualquier proyecto de control puede , y no los comprometan con el control de origen (esto incluye los archivos de proyecto de Visual Studio).
Establezca un servidor con una copia oficial de todas las bibliotecas y herramientas externas, para ser copiado/instalado en estaciones de trabajo de desarrollador y máquinas de construcción. Haga una copia de seguridad, junto con su repositorio de control de origen.
Establezca un servidor de integración continua (máquina de compilación) sin herramientas de desarrollo en absoluto.
Considere una herramienta para gestionar sus bibliotecas externas y entregables, como Ivy (utilizado con Ant).
NO use Maven - inicialmente lo hará feliz, y finalmente lo hará llorar.
Tenga en cuenta que nada de esto es específico de la subversión, y la mayoría de que es similar para proyectos dirigidos a cualquier sistema operativo, hardware, plataforma, lenguaje, etc. Hice uso de un poco de OS- y herramienta específica sintaxis, pero solo a modo de ilustración: confío en que lo traducirás a tu sistema operativo o herramienta de elección.
Nota adicional sobre las soluciones de Visual Studio: ¡no las ponga en control de fuente! Con este enfoque, no los necesita en absoluto o puede generarlos (al igual que los archivos de proyecto de Visual Studio). Sin embargo, considero que es mejor dejar los archivos de la solución a desarrolladores individuales para que los creen/usen como mejor les parezcan (pero no se verifiquen en el control de la fuente). Guardo un archivo Rob.sln en mi estación de trabajo desde el cual hago referencia a mi (s) proyecto (s) actual (es). Como mis proyectos son independientes, puedo agregar/eliminar proyectos a voluntad (eso significa que no hay referencias de dependencia basadas en proyectos).
No utilice Subversion externos (o similares en otras herramientas), son un antipatrón y, por lo tanto, innecesarios.
Cuando implemente la integración continua, o incluso cuando solo desee automatizar el proceso de lanzamiento, cree un script para él. Cree un único script de shell que: tome los parámetros del nombre del proyecto (como figura en el repositorio) y el nombre de la etiqueta, cree un directorio temporal dentro de un directorio raíz configurable, compruebe el origen del nombre del proyecto y el nombre de la etiqueta (construyendo el URL apropiada en el caso de Subversion) a ese directorio temporal, realiza una compilación limpia que ejecuta pruebas y empaqueta el entregable. Este script de shell debería funcionar en cualquier proyecto y se debe verificar en el control de código fuente como parte de su proyecto de "herramientas de compilación". Su servidor de integración continua puede usar este script como base para la creación de proyectos, o incluso podría proporcionarlo (pero aún puede querer el suyo).
@VonC: NO querrás trabajar en todo momento con "ant.jar" en lugar de "ant-abcdjar" después de quemarte cuando se rompa tu script de compilación porque sin saberlo lo ejecutaste con una versión incompatible de Ant .Esto es particularmente común entre Ant 1.6.5 y 1.7.0. Generalizando, SIEMPRE desea saber qué versión específica de CADA componente se está utilizando, incluida su plataforma (Java A.B.C.D.) y su herramienta de compilación (Ant E.F.G.H.). De lo contrario, eventualmente encontrará un error y su primer gran problema será rastrear qué versiones de sus diversos componentes están involucradas. Simplemente es mejor resolver ese problema por adelantado.
¿Seguro que quieres decir "thrash"? ¿O más bien "basura"? – ssc