Comment organisez-vous vos dossiers de projets? [fermé]

bonne après-midi

Je voudrais savoir comment vous organisez vos dossiers de projet?

J'ai eu une fois un patron qui m'a proposé d'organiser par les clients.

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

Un de mes amis m'a dit d'organiser tem by Technology

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

Et tu? Avez-vous une façon intelligente d'organiser vos dossiers de projet?

Voici ce que nous utilisons:

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

Nous utilisons cette structure pour plusieurs projets avec de nombreux clients différents depuis des années et cela fonctionne très bien.

C'est très similaire à votre suggestion initiale, mais nous utilisons le contrôle de version pour gérer le contrôle de version. Les référentiels de serveurs sont nommés "Client X - Projet Y", plutôt que toute autre chose. Cela nous permet d'avoir des sous-traitants externes travaillant sur certains projets mais pas en mesure d'accéder à d'autres car nous pouvons définir des autorisations à la racine du contrôle de version.

Tout le monde extrait leurs copies de travail où bon leur semble sur leur machine de développement (Windows) et utilise la commande SUBST pour mapper une lettre de lecteur à cet emplacement. De cette façon, nous pouvons avoir des chemins relatifs codés en dur dans les fichiers de construction, etc., qui fonctionnent dans la configuration de tout le monde. Ainsi, par exemple, nous pouvons avoir des liens vers des bibliothèques partagées, si nous le souhaitons. Nous utilisons généralement des liens / alias de contrôle de version pour y parvenir.

Un grand avantage de cette structure est que vous pouvez isoler le code des clients les uns des autres. Ceci est utile si vous devez (a) leur envoyer des mises à jour régulières de la source à des fins d'intégration, (b) avoir des entrepreneurs externes travaillant sur des parties sélectionnées du code.

Votre deuxième suggestion ne fonctionnera pas si bien avec un projet complexe qui utilise plus d'une technologie.

Je suis assez plat:

/Projets

Quelques variations pour y arriver en fonction de la boîte, mais derrière cela, il y a juste beaucoup de dossiers individuels pour les projets. La vraie affaire vit de toute façon dans le contrôle des sources, donc ce n'est que la maison locale temporaire.

J'ai une structure qui ressemble à celle-ci:

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

Archivescontient d'anciens projets sur lesquels je ne travaille plus. Workcontient des projets liés au travail. Currentest tout le développement actuel. Ensuite, dans mon répertoire personnel, je fais un lien symbolique Projectsvers ~/Developer/Projects/Current. ~/Projectscomprend également des liens symboliques vers certains projets de travail.

J'ai aussi une structure plate.

/Projets

D'accord avec Wyatt Barnett, la vraie affaire vit de toute façon dans le contrôle des sources.

Je veux juste ajouter qu'il ne devrait pas y avoir quoi que ce soit de spécial sur la structure des dossiers, car de nombreux IDE fournissent de toute façon des raccourcis vers des projets / fichiers récents. Et sur combien de projets quelqu'un travaille-t-il de toute façon? Vraiment, seulement par définition, les plus récents.

De plus, je n'ajoute que les projets récents dans le dossier de niveau supérieur de toute façon. J'archive toutes les choses anciennes et terminées dans:

/ Projets / Old_stuff

ou quelque chose comme ça. J'archive ce sur quoi je ne travaillerai généralement plus.

Dans le passé, j'ai utilisé des référentiels Subversion pour stocker mes documents source et j'ai suivi la convention "project-minor" pour l'organisation des référentiels, que j'ai trouvée très bien fonctionner pour les grandes et les petites organisations.

Nous structurerions nos branches de référentiel; balises et tronc comme suit:

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

Dans l'arborescence source proprement dite, nous utiliserions (quelque chose comme) la structure suivante:

  (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

L'idée était (et est toujours) d'utiliser la structure du référentiel pour aider à structurer la communication entre l'équipe d'ingénierie; la partie client de l'entreprise et divers autres intervenants et experts du domaine.

À savoir: les documents sources qui se trouvent dans l'un des répertoires "projet" ne sont utilisés (et gagnent de l'argent) qu'une seule fois. Les documents qui se trouvent dans l'un des répertoires "productLines" gagnent de l'argent autant de fois qu'un produit de cette ligne particulière est vendu. Les documents qui se trouvent dans l'un des répertoires des «bibliothèques» gagnent de l'argent autant de fois que n'importe lequel des produits qui les utilisent est vendu.

Il rend explicite la notion d'amortissement des coûts et aide à renforcer la prise en charge de la réutilisation des documents source dans toute l'entreprise.

Dans un monde idéal, le client faisant face à une partie de l'entreprise utiliserait également cette structure pour stocker les présentations et autres supports de vente, afin que les développeurs puissent voir quelles attentes des clients ont été créées, juste à côté du répertoire de produits pertinent, et les collègues qui font face au client peuvent suivre le développement progrès sur les fonctionnalités et les produits qu'ils vendent.

Cela signifie également qu'il existe une structure commune sur laquelle nos outils d'automatisation de construction peuvent fonctionner. (Nos scripts de construction parcourent l'arborescence source à la recherche de dossiers "build" dans lesquels ils trouvent des fichiers de configuration spécifiant comment chaque composant doit être construit; un processus similaire se produit pour la génération et le test de la documentation). Encore une fois, dans un monde idéal, le site Web de l'organisation et les autres supports marketing pourraient être créés de la même manière.

Comme une dernière note; le système d'intégration continue sait qu'il doit déclencher une construction; analyse statique; test de fumée et test unitaire exécutés chaque fois que le tronc est modifié, chaque fois qu'une branche de "tag" est modifiée et chaque fois qu'une branche de branche "AUTOMATISÉE" est modifiée. De cette façon, les développeurs individuels peuvent utiliser le système CI avec leurs branches personnelles, une capacité importante, à mon humble avis.

Je pense que vous voulez dire "dossier de documentation". J'organise mes documents pour le secteur tout d'abord, ensuite pour le client / l'application, à la fin pour le "développement et la maintenance".

Exemple: Projets

• Financier

  • application Web

    • App Alpha

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

    • App Beta

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

  • Logiciel de bureau
• Énergie et services publics
• BLA BLA