Rekomendacja struktury folderów projektów [zamknięty]

Question

Rekomendacja struktury folderów projektów [zamknięty]

Zamknięte . To pytanie jest oparte na opinii . Obecnie nie przyjmuje odpowiedzi.

Chcesz poprawić to pytanie? Zaktualizuj pytanie, aby mogło być odpowiedź z faktami i cytatami przez edytując ten post .

Zamknięte 1 rok temu .

Przygotowuję się do wdrożenia systemu kontroli źródeł (subversion), ale mam pewne wątpliwości co do struktury moich folderów.

Używam Delphi do całego mojego rozwoju i kompilowanie projektów z poziomu IDE.

Moja obecna struktura folderów projektów jest następująca:

-E:\Work\1. Shared
--Forms (shared forms across all projects)
--Units (shared units/classes across all projects including 3rd party like JCL)

-E:\Work\2. Company Name
--Admin (stuff related with admin work like a license keys generator, Windows CGI to handle order processing automatically, all developed in Delphi)
--Projects
----ProjectA
-----5.x (version 5.x)
------BIN (where all the binaries for this project go)
------Build Manager (where the FinalBuilder project lives)
-------Install (NSIS file that create the setup.exe)
-------Protection (Project files to protect the compiled exe)
-------Update (inf files related with the auto-update)
------Docs (where the readme.txt, license.txt and history.txt that are included in the setup file are)
-------Defects (docs for any testing done by me or others)
-------HTMLHelp (html help for the project)
------R&D (where screenshots, design ideas and other R&D stuff goes to)
------Releases (when building a release with FinalBuilder the setup file created by nsis is placed here)
------Resources (Images and other resources used by this project)
------Source (if a sub-project exists it will compile to BIN since they are all related)
-------SubprojectA
-------SubprojectB
-------SubprojectC
--Sites
--- companywebsite.com (the only one at the moment but if we decide to have individual web sites for products they would all be placed on the Sites folder)

Znak " - " oznacza katalogi.

Ktoś chce skomentować obecną strukturę lub ma jakieś sugestie, aby ją poprawić?

Dzięki!

12

directory project-management

Author: smartins, 2008-11-17

Source

2 answers

Dlaczego 5.x? (w ramach projectA)

Wydaje mi się, że nie warto wprowadzać wersji w drzewie - do tego służy subversion itp.

2

Author: Tim,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-11-17 20:47:14

score 30 · Accepted Answer

Po skonfigurowaniu dosłownie setek projektów na przestrzeni lat i wyspecjalizowaniu się w zarządzaniu konfiguracją oprogramowania i inżynierii wydań, polecam, abyś najpierw skupił się na tym, jak chcesz zbudować/wydać swój projekt(y).

Jeśli używasz tylko IDE do budowania (kompilowania i pakowania) swoich projektów, możesz równie dobrze postępować zgodnie z konwencjami typowymi dla tego IDE, plus wszelkie "najlepsze praktyki", które możesz znaleźć.

Jednak zdecydowanie polecam nie budować tylko z IDE, lub nawet w ogóle. Zamiast tego utwórz zautomatyzowany skrypt kompilacji/wydania za pomocą jednego lub więcej z wielu wspaniałych dostępnych narzędzi open-source. Ponieważ wydaje ci się, że celujesz w okna, polecam zacząć od spojrzenia na Ant, Ivy i odpowiedni xUnit (jUnit dla Java, nUnit dla. NET, itp.) do testów.

Po uruchomieniu tej ścieżki, znajdziesz wiele porad dotyczących struktury projektu, projektowania skryptów budowania, testowania itp. Zamiast przytłaczać Cię dzięki szczegółowym Radom teraz po prostu zostawię cię z tą sugestią-chętnie znajdziesz tam odpowiedzi na swoje pytanie, a także znajdziesz dużo więcej pytań wartych zbadania.

Enjoy!

Na podstawie komentarzy wydaje się, że potrzebne są jakieś szczegóły.

Szczególną rekomendacją, którą chciałbym zrobić jest to, że oddzielenie kodu na poszczególne podprojekty, że każdy produkować jeden dostarczalny. Główne zastosowanie (.EXE) powinien być jeden, każdy wspierający pliki binarne byłyby oddzielnymi projektami, instalator byłby oddzielnym projektem itp.

Każdy projekt tworzy jeden podstawowy produkt: an .EXE,HLP itp. Jest to "opublikowane" do jednego, współdzielonego, lokalnego katalogu wyjściowego.

Stwórz drzewo katalogów, w którym podprojekty są rówieśnikami (nie ma głębi ani hierarchii, bo to nie pomaga), i nie pozwól projektom "dotrzeć" do siebie nawzajem-każdy projekt powinien być całkowicie niezależny, z zależności tylko od podstawowych rezultatów innych podprojektów, do których odwołuje się współdzielony katalog wyjściowy.

Nie twórz hierarchii skryptów budowania, które wywołują się nawzajem, zrobiłem i stwierdziłem, że nie dodaje wartości, ale wykładniczo zwiększa wysiłek utrzymania. Zamiast tego Utwórz skrypt ciągłej integracji, który wywoła samodzielny skrypt kompilacji, ale najpierw wykonaj czystą transakcję w katalogu tymczasowym.

Nie zgłaszaj żadnych rezultatów ani zależności do kontroli źródeł -- Nie wyjście kompilacji, nie biblioteki, które używasz, itp. Używaj Ivy wobec repozytorium binarnego podobnego do Mavena, które wdrażasz oddzielnie od kontroli źródeł i publikujesz do niego własne rezultaty w celu udostępnienia w organizacji.

Oh, I nie używaj Mavena-jest to zbyt skomplikowane, zaciemnia proces budowania i dlatego nie jest opłacalne dostosowywanie.

Idę w kierunku SCons, BuildBot, Ant, Ivy, nAnt itp. na podstawie mojego celu Peron.

Komponowałem biały dokument na ten temat, który widzę, że może mieć publiczność.

EDIT: proszę zobaczyć moją szczegółową odpowiedź na Jak zorganizować repozytorium kontroli wersji?