project management - pmi - Recomendación de estructura de carpeta de proyectos
pmi español (2)
Me estoy preparando para implementar un sistema de control de fuente (subversión) pero tengo algunas dudas sobre cómo estructurar mis carpetas.
Utilizo Delphi para todo mi desarrollo y compilo los proyectos desde el IDE.
La estructura de mi carpeta de proyectos actual es la siguiente:
-E:/Work/1. Shared --Forms (shared forms across all projects) --Units (shared units/classes across all projects including 3rd party like JCL) -E:/Work/2. Company Name --Admin (stuff related with admin work like a license keys generator, Windows CGI to handle order processing automatically, all developed in Delphi) --Projects ----ProjectA -----5.x (version 5.x) ------BIN (where all the binaries for this project go) ------Build Manager (where the FinalBuilder project lives) -------Install (NSIS file that create the setup.exe) -------Protection (Project files to protect the compiled exe) -------Update (inf files related with the auto-update) ------Docs (where the readme.txt, license.txt and history.txt that are included in the setup file are) -------Defects (docs for any testing done by me or others) -------HTMLHelp (html help for the project) ------R&D (where screenshots, design ideas and other R&D stuff goes to) ------Releases (when building a release with FinalBuilder the setup file created by nsis is placed here) ------Resources (Images and other resources used by this project) ------Source (if a sub-project exists it will compile to BIN since they are all related) -------SubprojectA -------SubprojectB -------SubprojectC --Sites --- companywebsite.com (the only one at the moment but if we decide to have individual web sites for products they would all be placed on the Sites folder)
El signo "-" marca los directorios.
¿Alguien se preocupa por comentar sobre la estructura actual o tiene alguna sugerencia para mejorarla?
¡Gracias!
¿por qué el 5.x? (en el proyecto A)
No creo que sea útil introducir las versiones en el árbol, para eso sirve la subversión, etc.
Habiendo instalado literalmente cientos de proyectos a lo largo de los años, y habiéndome especializado en la administración de configuración de software y la ingeniería de lanzamiento, recomendaría que primero se concentre en cómo desea construir / lanzar su (s) proyecto (s).
Si solo usa un IDE para compilar (compilar y empaquetar) su (s) proyecto (s), entonces también puede seguir las convenciones típicas para ese IDE, más cualquier "mejor práctica" que pueda encontrar.
Sin embargo, recomiendo encarecidamente que no compile solo con un IDE, o incluso que lo haga. En su lugar, cree una secuencia de comandos automatizada de compilación / versión utilizando una o más de las maravillosas herramientas de código abierto disponibles. Dado que parece que tiene como objetivo Windows, le recomiendo comenzar con un análisis de Ant, Ivy y la xUnit adecuada (jUnit para Java, nUnit para .NET, etc.) para probar.
Una vez que comiences por ese camino, encontrarás muchos consejos sobre la estructura del proyecto, el diseño de tus scripts de compilación, pruebas, etc. En lugar de abrumarte con consejos detallados ahora, simplemente te dejaré con esa sugerencia. Encontrarás respuestas fácilmente. a su pregunta allí, así como a encontrar muchas más preguntas que vale la pena investigar.
¡Disfrutar!
Según los comentarios, parece que se necesita algún detalle.
Una recomendación particular que haría es que separes tu base de código en subproyectos individuales que producen cada uno un entregable único. La aplicación principal (.EXE) debe ser uno, los archivos binarios de apoyo serán proyectos separados, el instalador será un proyecto separado, etc.
Cada proyecto produce un entregable principal único: un .EXE, un .DLL, un .HLP, etc. El entregable se "publica" en un único directorio de salida compartido y local.
Cree un árbol de directorios donde los subproyectos sean pares (sin profundidad ni jerarquía, porque no ayuda), y NO permita que los proyectos "lleguen" al subárbol de cada uno; cada proyecto debe ser completamente independiente, con dependencias ÚNICAMENTE en los principales entregables de los otros subproyectos, referenciados en el directorio de salida compartido.
NO cree una jerarquía de scripts de compilación que se invoquen entre sí, lo hice y descubrí que no agrega valor, pero aumenta exponencialmente el esfuerzo de mantenimiento. En su lugar, cree una secuencia de comandos de integración continua que invoca su secuencia de comandos de compilación independiente, pero primero realiza una comprobación limpia en un directorio temporal.
NO confíe ningún producto o dependencia al control de código fuente, ni a su resultado de compilación, ni a las bibliotecas que usa, etc. Utilice Ivy contra un repositorio binario similar a Maven que implemente por separado del control de origen y publique sus propios entregables. para compartir dentro de su organización.
Ah, y no uses Maven, es demasiado complicado, ofusca el proceso de compilación y, por lo tanto, no es rentable personalizarlo.
Me estoy moviendo hacia SCons, BuildBot, Ant, Ivy, nAnt, etc. según mi plataforma de destino.
He estado componiendo un libro blanco sobre este tema, que veo que puede tener una audiencia.
EDIT: vea mi respuesta detallada a ¿Cómo se organiza el repositorio de control de versiones?