¿Cómo organizas las carpetas de tus proyectos? [cerrado]

Buenas tardes

Me gustaría saber cómo organizan sus carpetas de proyectos.

Una vez tuve un jefe que me sugirió organizar por clientes.

Projects
|
|----Customer 1
     |---- A Cool Solution 1
           |---- source
                 |---- version1.0
                 |---- version1.1
           |---- docs
                 |---- analysis
                 |---- meetings
                 |---- manuals
|----Customer 2
|----Customer 3

Un amigo mío me dijo que organizara tem por Tecnología

Projects
|
|----.NET
     |---- C#
          |---- Customer 1     
                |---- A Cool Solution 1
                      |---- source
                            |---- version1.0
                            |---- version1.1
                      |---- docs
                            |---- analysis
                            |---- meetings
                            |---- manuals
|----Ruby
|----PHP

¿Y tú? ¿Tiene una manera inteligente de organizar sus carpetas de proyectos?

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 sin poder acceder a otros, ya que podemos establecer permisos en la raíz del control de versiones.

Todos revisan sus copias de trabajo a donde quieran en su máquina de desarrollo (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 los 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 versiones para lograr esto.

Una gran ventaja 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 para fines de integración, (b) tener contratistas externos que trabajen en partes seleccionadas del código.

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

Soy bastante chato:

/ Proyectos

Algunas variaciones llegan allí dependiendo de la caja, 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

Archivescontiene proyectos antiguos en los que ya no estoy trabajando. Workcontiene proyectos relacionados con el trabajo. CurrentEs todo desarrollo actual. Luego, en mi directorio de inicio, hago un enlace simbólico Projectsa ~/Developer/Projects/Current. ~/ProjectsTambién incluye enlaces simbólicos a algunos proyectos de trabajo.

También tengo una estructura plana.

/ Proyectos

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 sobre 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, las recientes.

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

/ Proyectos / Old_stuff

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

En el pasado, utilicé repositorios de Subversion para almacenar mis documentos de origen, y seguí 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 y 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 fuente, usaríamos (algo así) 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) usar 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 y expertos en dominios.

A saber: los documentos fuente que se encuentran en uno de los directorios del "proyecto" se usan (y ganan dinero) solo una vez. Los documentos que se encuentran en uno de los directorios "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 "bibliotecas" ganan dinero tantas veces como se vende cualquiera de los productos que los usan.

Hace explícita la noción de amortización de costos y ayuda a crear soporte para la reutilización de documentos fuente en toda la empresa.

En un mundo ideal, el cliente que enfrenta parte de la empresa también usaría esta estructura para almacenar presentaciones y otras garantías de ventas, para que los desarrolladores puedan ver qué expectativas se han creado, junto con el directorio de productos relevante, y los colegas que enfrentan al cliente pueden seguir el desarrollo progreso en 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" dentro de las cuales encuentran archivos de configuración que especifican cómo se debe compilar cada componente; ocurre un proceso similar para la generación y prueba de documentación). Una vez más, en un mundo ideal, el sitio web de la organización y otras garantías de marketing podrían construirse de la misma manera.

Como una nota final; el sistema de integración continua sabe que necesita activar una compilación; análisis estático; la prueba de humo y la prueba de la unidad se ejecutan cada vez que se modifica la troncal, cada vez que se modifica cualquier rama "etiqueta", y cada vez que se modifica cualquier rama "AUTOMATIZADA". De esta manera, los desarrolladores individuales pueden usar el sistema CI con sus ramas personales, una capacidad importante, en mi humilde opinión.

Creo que significa "carpeta de documentación". Primero organizo mis documentos para el sector, luego para el cliente / aplicación, al final para "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 y servicios públicos
• BLA BLA