¿Cómo organiza las carpetas de sus proyectos? [cerrado]

Esto es lo que hemos estado usando:

Projects
|
|----Customer A
     |---- Project 1
     |     |---- BuildControl       (CI/nAnt/Make/MSBuild files and config, etc)
     |     |---- Documentation      (In XML format so we can 'build' them)
     |     |---- Source
     |     |     |---- Component X
     |     |     |---- Component X.tests
     |     |     |---- Component Y 
     |     |     |---- Component Y.tests
     |     |---- Testing
     |     Project 1.sln      (Has folders as per project on-disk structure)
     |---- Project 2
     |---- Shared/Common components
|----Customer B
|----Customer C
|----<Our Company>
     |---- Internal Project A
     |---- Internal Library B

Hemos estado utilizando esta estructura para múltiples proyectos con muchos clientes diferentes durante años y funciona muy bien.

Es muy similar a su sugerencia inicial, pero usamos el control de versiones para administrar el control de versiones. Los repositorios del servidor se denominan "Cliente X - Proyecto Y", en lugar de cualquier otra cosa. Esto nos permite tener contratistas externos trabajando en algunos proyectos pero no podemos acceder a otros, ya que podemos establecer permisos en la raíz de control de versión.

Todos verifican sus copias de trabajo a donde quieran en su máquina dev (Windows) y usan el comando SUBST para asignar una letra de unidad a esa ubicación. De esa manera podemos tener rutas relativas codificadas en archivos de compilación, etc., que funcionan en la configuración de todos. Entonces, por ejemplo, podemos tener enlaces a bibliotecas compartidas, si así lo deseamos. Usualmente usamos enlaces / alias de control de versión para lograr esto.

Un gran beneficio de esta estructura es que puede aislar el código de los clientes entre sí. Esto es útil si necesita (a) enviarles actualizaciones periódicas de la fuente con fines de integración, (b) tener contratistas externos trabajando en partes seleccionadas del código.

Su segunda sugerencia no funcionará tan bien con un proyecto complejo que usa más de una tecnología.

Soy bastante plano:

/ Proyectos

Alguna variación llega hasta allí dependiendo del cuadro, pero detrás de eso solo hay muchas carpetas individuales para proyectos. El trato real vive en el control de la fuente de todos modos, por lo que este es solo el hogar local temporal.

Tengo una estructura que se parece a la siguiente:

~/
|-- Developer/
|   |-- Projects/
|   |   |-- Archives/
|   |   |-- Current/
|   |   |-- Work/
|-- Projects -> ~/Developer/Projects/Current

Archives contiene proyectos antiguos en los que ya no estoy trabajando. Work contiene proyectos relacionados con el trabajo. Current es todo el desarrollo actual. Luego, en mi directorio de inicio, enlace simbólico Projects a ~/Developer/Projects/Current . ~/Projects también incluye enlaces simbólicos a algunos proyectos de trabajo.

También tengo una estructura plana.

/Projects

De acuerdo con Wyatt Barnett, el trato real vive en el control de la fuente de todos modos.

Solo quiero agregar que, de todos modos, no debería haber nada especial en la estructura de carpetas, ya que muchos IDE proporcionan accesos directos a proyectos / archivos recientes de todos modos. ¿Y en cuántos proyectos trabaja alguien de todos modos? En verdad, solo por definición, los recientes.

Además, solo agrego proyectos recientes a la carpeta de nivel superior de todos modos. Archivo todas las cosas antiguas y completas en:

/ Projects / Old_stuff

o algo así. Archivé lo que generalmente no volveré a trabajar.

En el pasado, he usado los repositorios de Subversion para almacenar mis documentos de origen, y he seguido la convención de "proyecto menor" para la organización de repositorios, que he encontrado que funciona muy bien para organizaciones grandes y pequeñas.

Estructuraríamos nuestras ramas de repositorio; etiquetas & tronco de la siguiente manera:

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

Dentro del propio árbol de origen, usaríamos (algo como) la siguiente estructura:

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

La idea era (y sigue siendo) utilizar la estructura del repositorio para ayudar a estructurar la comunicación entre el equipo de ingeniería; la parte del negocio orientada al cliente y otras partes interesadas & expertos de dominio.

Para saberlo: los documentos de origen que se encuentran en uno de los directorios de "proyectos" se utilizan (y ganan dinero) solo una vez. Los documentos que se encuentran en uno de los directorios de "productLines" ganan dinero tantas veces como se vende un producto de esa línea en particular. Los documentos que se encuentran en uno de los directorios de las "bibliotecas" ganan dinero tantas veces como se venden los productos que los usan.

Hace que la noción de amortización de los costos sea explícita y ayuda a desarrollar el soporte para la reutilización de documentos de origen en toda la empresa.

En un mundo ideal, el cliente frente a una parte de la empresa también usaría esta estructura para almacenar presentaciones y aplicaciones; otra garantía de ventas, para que los desarrolladores puedan ver las expectativas de los clientes que se han creado, junto con el directorio del producto correspondiente, y los colegas que se enfrentan al cliente pueden hacer un seguimiento del progreso del desarrollo de las características y productos que están vendiendo.

También significa que existe una estructura común sobre la cual pueden operar nuestras herramientas de automatización de compilación. (Nuestros scripts de compilación recorren el árbol de origen en busca de carpetas de "compilación" en las que encuentran archivos de configuración que especifican cómo se debe construir cada componente; ocurre un proceso similar para la generación y prueba de documentación). Nuevamente, en un mundo ideal, el sitio web de la organización y otros materiales de marketing podrían construirse de la misma manera.

Como una nota final; el sistema de integración continua sabe que necesita desencadenar una compilación; análisis estático; prueba de humo & la prueba de la unidad se ejecuta cada vez que se modifica el troncal, cada vez que se modifica una rama "etiqueta", y cada vez que se modifica una rama "AUTOMATIZADA". De esta manera, los desarrolladores individuales pueden usar el sistema de CI con sus sucursales personales, una capacidad importante, IMHO.

Creo que significa "carpeta de documentación". Primero organizo mis documentos para el sector, luego para el cliente / la aplicación, al final para el "desarrollo y mantenimiento".

Ejemplo: Proyectos

• Financiero

  • aplicación web

    • App Alpha

       - source
       - functional docs
       - etc etc (testing, meeting with customer)
      

    • App Beta

       - functional docs
       - etc etc (testing, meeting with customer)
      

  • software de escritorio
• Energía & utilidades
• BLA BLA