it-swarm-fr.com

Comment organisez-vous vos dossiers de projets?

Bon après-midi

J'aimerais savoir comment organiser vos dossiers de projet?

J'ai eu une fois un patron qui me suggère d'organiser des 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 par la technologie

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

Et vous? Avez-vous un moyen intelligent d'organiser vos dossiers de projet?

15
Junior M

Voilà ce que nous avons utilisé:

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 avons utilisé cette structure pour plusieurs projets avec de nombreux clients depuis des années et il fonctionne très bien.

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

Vérifie tout le monde leurs copies de travail à chaque fois qu'ils veulent sur leur (Windows) machine dev et utilise la commande pour mapper une subst lettre de lecteur à cet endroit. De cette façon, nous pouvons avoir des chemins relatifs codées en dur dans les fichiers de construction, etc, que le travail dans la configuration de everyones. Ainsi, par exemple, nous pouvons avoir des liens vers les bibliothèques partagées, si nous le voulons. Nous utilisons généralement des liens de contrôle de version/alias pour y parvenir tho.

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

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

6
JBRWilkinson

Je suis assez plat:

/Projets

Une varément d'arrivée en fonction de la boîte, mais derrière cela, il n'ya que de nombreux dossiers individuels pour des projets. De vraie affaire vit dans le contrôle de la source de toute façon, il s'agit donc de la maison locale temporaire.

8
Wyatt Barnett

J'ai aussi une structure plane.

/ projets

D'accord avec Wyatt Barnett, une vraie affaire de la vie dans le contrôle de la source de toute façon.

Je veux juste ajouter qu'il ne devrait y avoir rien de spécial sur la structure de dossiers de toute façon, car de nombreux idées fournissent des raccourcis aux projets/fichiers récents de toute façon. Et combien de projets quelqu'un travaille-t-il quand même? Vraiment, seulement par définition, les récents.

En outre, je n'aijoute pas seulement des projets récents dans le dossier de haut niveau de toute façon. J'archive toutes les choses plus anciennes et terminées dans:

/ Projets/Old_stuff

ou quelque chose comme ça. J'archive ce que je ne travaillerai plus jamais.

3
spong

Dans le passé, j'ai utilisé des référentiels Subversion pour stocker mes documents source et suivi la convention "Projet-mineur" d'organisation du référentiel, que j'ai constatée très bien pour les grandes et les petites entreprises.

Nous structions nos branches de référentiel; Tags et coffre 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 actuel, 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 de la clientèle de l'entreprise et de divers autres parties prenantes et experts de domaine.

Pour savoir: Les documents source qui sont assis dans l'un des répertoires "Projet" sont utilisés (et gagnent de l'argent) une seule fois. Les documents qui sont assis dans l'une des annuaires "Liqueurs" gagnent de l'argent autant de fois qu'un produit de cette ligne particulière est vendu. Les documents qui siègent dans l'une des répertoires "bibliothèques" gagnent de l'argent autant de fois que l'un des produits qui les utilisent sont vendus.

Cela rend la notion d'amortissement des coûts explicites et contribue à renforcer la prise en charge de la réutilisation du document source à travers l'entreprise.

Dans un monde idéal, le client face à une partie de l'entreprise utiliserait également cette structure pour stocker des présentations et d'autres garanties de vente. Les développeurs peuvent donc voir les attentes des clients créées, à côté du répertoire de produits concerné, et les collègues du client peuvent suivre le développement. progrès sur les caractéristiques et les produits qu'ils vendent.

Cela signifie également qu'il existe une structure commune sur laquelle nos outils de construction d'automatisation peuvent fonctionner. (Nos scripts de construction marchent l'arborescence source à la recherche de dossiers "Construire" dans lesquels ils trouvent des fichiers de configuration spécifiant la manière dont chaque composant doit être construit; un processus similaire se produit pour la génération et les tests de documentation). Encore une fois, dans un monde idéal, le site Web de l'organisation et d'autres garanties de marketing pourraient être construits 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 de l'unité Exécuter chaque tronc de l'heure est modifié, chaque fois qu'une branche "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, IMHO.

3
William Payne

J'ai une structure qui ressemble à ce qui suit:

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

Archives contient de vieux projets que je ne travaille plus. Work contient des projets liés au travail. Current est tout le développement actuel. Ensuite, dans mon annuaire à domicile, je suis symbolique Projects à ~/Developer/Projects/Current. ~/Projects comprend également des liens symboliques à certains projets de travail.

3
mipadi

Je pense que vous voulez "dossier de documentation". J'organise d'abord mes documents pour le secteur, après pour client/demande, à la fin du "développement et de maintenance".

Exemple: projets

  • Financier

    • Application Web

      • App alpha

         - source
         - functional docs
         - etc etc (testing, meeting with customer)
        
      • App bêta

         - functional docs
         - etc etc (testing, meeting with customer)
        
    • Logiciel de bureau
  • Energie et services publics
  • Bla bla
0
alepuzio