Wie organisieren Sie Ihre Projektordner? [geschlossen]

guten Tag

Ich würde gerne wissen, wie ihr eure Projektordner organisiert.

Ich hatte einmal einen Chef, der mir vorschlug, mich nach Kunden zu organisieren.

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

Ein Freund von mir sagte mir, ich solle die Technik organisieren

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

Und du? Haben Sie eine clevere Möglichkeit, Ihre Projektordner zu organisieren?

Das haben wir benutzt:

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

Wir verwenden diese Struktur seit Jahren für mehrere Projekte mit vielen verschiedenen Kunden und sie funktioniert sehr gut.

Es ist Ihrem ursprünglichen Vorschlag sehr ähnlich, aber wir verwenden die Versionskontrolle, um die Versionierung zu verwalten. Die Server-Repositorys tragen nicht den Namen "Kunde X - Projekt Y". Auf diese Weise können externe Auftragnehmer an einigen Projekten arbeiten, jedoch nicht auf andere zugreifen, da wir Berechtigungen im Stammverzeichnis der Versionskontrolle festlegen können.

Jeder checkt seine Arbeitskopien auf seinem (Windows) -Entwicklungscomputer nach Belieben aus und ordnet diesem Speicherort mit dem Befehl SUBST einen Laufwerksbuchstaben zu. Auf diese Weise können wir fest codierte relative Pfade in Build-Dateien usw. haben, die für alle Setups geeignet sind. So können wir zum Beispiel Links zu gemeinsam genutzten Bibliotheken haben, wenn wir dies wünschen. Wir verwenden normalerweise Links / Aliase zur Versionskontrolle, um dies zu erreichen.

Ein großer Vorteil dieser Struktur ist, dass Sie den Kundencode voneinander isolieren können. Dies ist nützlich, wenn Sie (a) regelmäßige Aktualisierungen der Quelle für Integrationszwecke senden müssen, (b) externe Auftragnehmer an ausgewählten Teilen des Codes arbeiten müssen.

Ihr zweiter Vorschlag funktioniert bei einem komplexen Projekt, das mehr als eine Technologie verwendet, nicht so gut.

Ich bin ziemlich flach:

/ Projekte

Je nach Box gibt es einige Unterschiede, aber dahinter befinden sich nur viele einzelne Ordner für Projekte. Real Deal lebt sowieso in der Quellcodeverwaltung, daher ist dies nur das vorübergehende Zuhause vor Ort.

Ich habe eine Struktur, die wie folgt aussieht:

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

ArchivesEnthält alte Projekte, an denen ich nicht mehr arbeite. Workenthält arbeitsbezogene Projekte. Currentist alles aktuelle Entwicklung. Dann symlinke ich in meinem Home-Verzeichnis Projectszu ~/Developer/Projects/Current. ~/ProjectsEnthält auch Symlinks zu einigen Arbeitsprojekten.

Ich habe auch eine flache Struktur.

/ Projekte

Wenn Sie mit Wyatt Barnett einverstanden sind, liegt das echte Geschäft sowieso in der Quellcodeverwaltung.

Ich möchte nur hinzufügen, dass die Ordnerstruktur sowieso nichts Besonderes sein sollte, da viele IDEs ohnehin Verknüpfungen zu aktuellen Projekten / Dateien bereitstellen. Und an wie vielen Projekten arbeitet überhaupt jemand? Wirklich, nur per Definition, die jüngsten.

Außerdem füge ich ohnehin nur aktuelle Projekte in den Ordner der obersten Ebene ein. Ich archiviere alle älteren und abgeschlossenen Sachen in:

/ Projekte / Altes

oder etwas ähnliches. Ich archiviere, woran ich in der Regel nicht mehr arbeite.

In der Vergangenheit habe ich Subversion-Repositorys zum Speichern meiner Quelldokumente verwendet und mich an die "Project-Minor" -Konvention für die Organisation von Repositorys gehalten, die sowohl für große als auch für kleine Organisationen sehr gut funktioniert.

Wir würden unsere Endlagerzweige strukturieren. Tags & Trunk wie folgt:

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

Innerhalb des eigentlichen Quellbaums würden wir (so etwas wie) die folgende Struktur verwenden:

  (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

Die Idee war (und ist), die Struktur des Repositorys zu verwenden, um die Kommunikation zwischen dem Engineering-Team zu strukturieren. der kundenorientierte Teil des Geschäfts und verschiedene andere Stakeholder und Domain-Experten.

Übrigens: Quelldokumente, die sich in einem der "Projekt" -Verzeichnisse befinden, werden nur einmal verwendet (und verdienen Geld). Dokumente, die sich in einem der "productLines" -Verzeichnisse befinden, verdienen so viel Geld, wie ein Produkt aus dieser bestimmten Zeile verkauft wird. Dokumente, die sich in einem der "Bibliotheks" -Verzeichnisse befinden, verdienen so viel Geld, wie Produkte, die sie verwenden, verkauft werden.

Der Begriff der Amortisation von Kosten wird explizit erwähnt, und es wird eine Unterstützung für die Wiederverwendung von Quelldokumenten im gesamten Unternehmen geschaffen.

In einer idealen Welt würde ein Teil des Unternehmens, der Kunden gegenübersteht, diese Struktur auch zum Speichern von Präsentationen und anderen Verkaufssicherheiten verwenden, damit Entwickler direkt neben dem relevanten Produktverzeichnis sehen können, welche Kundenerwartungen entstanden sind, und Kollegen, die Kunden gegenüberstehen, die Entwicklung verfolgen können Fortschritte bei den Funktionen und Produkten, die sie verkaufen.

Dies bedeutet auch, dass es eine gemeinsame Struktur gibt, über die unsere Build-Automatisierungstools arbeiten können. (Unsere Build-Skripte durchsuchen den Quellbaum nach "Build" -Ordnern, in denen sie Konfigurationsdateien finden, die angeben, wie die einzelnen Komponenten erstellt werden sollen. Ein ähnlicher Prozess wird für die Dokumentationserstellung und das Testen ausgeführt.) Wiederum könnten in einer idealen Welt die Website des Unternehmens und andere Marketingmaterialien auf die gleiche Weise erstellt werden.

Als eine letzte Anmerkung; Das kontinuierliche Integrationssystem weiß, dass es einen Build auslösen muss. statische Analyse; Rauch- und Einheitentestlauf bei jeder Änderung des Trunks, bei jeder Änderung eines "Tag" -Zweigs und bei jeder Änderung eines "AUTOMATISIERT" -Zweigs. Auf diese Weise können einzelne Entwickler das CI-System mit ihren persönlichen Filialen nutzen, eine wichtige Funktion, IMHO.

Ich denke, dass Sie "Dokumentationsordner" bedeutet. Ich organisiere meine Dokumente erst für die Branche, dann für den Kunden / die Anwendung, zum Schluss für "Entwickeln und Pflegen".

Beispiel: Projekte

• Finanziell

  • Internetanwendung

    • App Alpha

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

    • App Beta

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

  • Desktop-Software
• Energie & Versorgung
• BLA BLA