Jak organizujesz foldery projektów? [Zamknięte]

Dzień dobry

Chciałbym wiedzieć, jak organizujecie foldery projektów?

Kiedyś miałem szefa, który sugeruje mi organizację przez klientów.

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

Mój przyjaciel powiedział mi, żebym zorganizował tem przez Technology

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

A ty? Czy masz sprytny sposób na uporządkowanie folderów projektu?

Z tego korzystamy:

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

Od lat używamy tej struktury do wielu projektów z wieloma różnymi klientami i działa ona bardzo dobrze.

Jest bardzo podobny do początkowej sugestii, ale używamy kontroli wersji do zarządzania wersjami. Repozytoria serwerów noszą nazwę „Klient X - Projekt Y”, a nie cokolwiek innego. To pozwala nam mieć zewnętrznych wykonawców pracujących nad niektórymi projektami, ale nie mogących uzyskać dostępu do innych, ponieważ możemy ustawić uprawnienia w katalogu głównym kontroli wersji.

Wszyscy sprawdzają swoje kopie robocze w dowolnym miejscu na swoim urządzeniu deweloperskim (Windows) i używają polecenia SUBST do mapowania litery dysku do tej lokalizacji. W ten sposób możemy mieć zakodowane ścieżki względne w plikach kompilacji itp., Które działają w konfiguracji każdego. Na przykład możemy mieć linki do bibliotek współdzielonych, jeśli sobie tego życzymy. Zwykle używamy linków / aliasów kontroli wersji, aby to osiągnąć.

Jedną wielką zaletą tej struktury jest to, że możesz izolować kod klienta od siebie. Jest to przydatne, jeśli musisz (a) przesyłać im regularne aktualizacje źródła w celu integracji, (b) mieć zewnętrznych wykonawców pracujących nad wybranymi częściami kodu.

Twoja druga sugestia nie zadziała tak dobrze w przypadku złożonego projektu, który wykorzystuje więcej niż jedną technologię.

Jestem całkiem płaska:

/Projektowanie

Niektóre warianty dostają się w zależności od pudełka, ale za tym jest tylko wiele indywidualnych folderów dla projektów. W każdym razie prawdziwa okazja żyje pod kontrolą źródła, więc jest to tylko tymczasowy lokalny dom.

Mam strukturę, która luźno wygląda następująco:

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

Archiveszawiera stare projekty, nad którymi już nie pracuję. Workzawiera projekty związane z pracą. Currentjest cały obecny rozwój. Następnie w moim katalogu domowym odsyłam Projectsdo ~/Developer/Projects/Current. ~/Projectszawiera także dowiązania symboliczne do niektórych projektów roboczych.

Mam również płaską strukturę.

/Projektowanie

Zgadzając się z Wyattem Barnettem, i tak prawdziwa okazja żyje pod kontrolą źródła.

Chcę tylko dodać, że w strukturze folderów i tak nie powinno być nic specjalnego, ponieważ wiele IDE zapewnia i tak skróty do najnowszych projektów / plików. A nad iloma projektami w ogóle ktoś pracuje? Doprawdy, tylko z definicji, te ostatnie.

Poza tym i tak dodaję tylko najnowsze projekty do folderu najwyższego poziomu. Archiwizuję wszystkie starsze i ukończone rzeczy w:

/ Projekty / Old_stuff

czy jakoś tak. Archiwizuję to, nad czym na ogół nie będę ponownie pracować.

W przeszłości korzystałem z repozytoriów Subversion do przechowywania dokumentów źródłowych i postępowałem zgodnie z konwencją „drobnych projektów” dotyczącą organizacji repozytoriów, która okazała się bardzo dobrze działać zarówno dla dużych, jak i małych organizacji.

Skonstruowalibyśmy nasze gałęzie repozytoriów; tagi i bagażnik w następujący sposób:

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

W obrębie samego drzewa źródłowego użylibyśmy (coś podobnego) następującej struktury:

  (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

Ideą było (i nadal jest) wykorzystanie struktury repozytorium, aby pomóc w strukturze komunikacji między zespołem inżynierów; część firmy zorientowana na klienta oraz inni interesariusze i eksperci w tej dziedzinie.

To znaczy: Dokumenty źródłowe znajdujące się w jednym z katalogów „projektu” są wykorzystywane (i zarabiają pieniądze) tylko raz. Dokumenty znajdujące się w jednym z katalogów „productLines” zarabiają tyle razy, ile razy produkt z danej linii zostaje sprzedany. Dokumenty znajdujące się w jednym z katalogów „bibliotek” zarabiają tyle razy, ile sprzedaje którykolwiek z ich produktów.

Wyjaśnia pojęcie amortyzacji kosztów i pomaga zbudować obsługę ponownego wykorzystania dokumentów źródłowych w całej firmie.

W idealnym świecie część firmy zorientowana na klienta wykorzystywałaby również tę strukturę do przechowywania prezentacji i innych zabezpieczeń sprzedaży, dzięki czemu programiści mogą zobaczyć, jakie oczekiwania klientów zostały stworzone, obok odpowiedniego katalogu produktów, a współpracujący z nimi klienci mogą śledzić rozwój postęp w zakresie funkcji i produktów, które sprzedają.

Oznacza to również, że istnieje wspólna struktura, nad którą mogą działać nasze narzędzia do automatyzacji kompilacji. (Nasze skrypty kompilacji chodzą po drzewie źródłowym w poszukiwaniu folderów „kompilacji”, w których znajdują pliki konfiguracyjne określające sposób budowania każdego komponentu; podobny proces ma miejsce w przypadku generowania i testowania dokumentacji). Ponownie, w idealnym świecie, strona internetowa organizacji i inne zabezpieczenia marketingowe mogą być zbudowane w ten sam sposób.

Jako ostatnia uwaga; system ciągłej integracji wie, że musi uruchomić kompilację; analiza statyczna; test dymu i test jednostkowy uruchamiane przy każdej modyfikacji pnia, za każdym razem, gdy modyfikowana jest dowolna gałąź „tag”, oraz za każdym razem, gdy modyfikowana jest dowolna gałąź „AUTOMATED”. W ten sposób indywidualni programiści mogą korzystać z systemu CI ze swoimi osobistymi oddziałami, co jest ważną funkcją, IMHO.

Myślę, że masz na myśli „folder dokumentacji”. Organizuję swoje dokumenty najpierw dla sektora, potem dla klienta / aplikacji, a na końcu „rozwoju i konserwacji”.

Przykład: projekty

• Budżetowy

  • Aplikacja internetowa

    • App Alpha

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

    • App Beta

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

  • Oprogramowanie komputerowe
• Energia i media
• BLA BLA