Рекомендации по структуре папок проектов

Question

Я готовлюсь к внедрению системы контроля версий (subversion), но у меня возникают некоторые сомнения относительно того, как структурировать мои папки.

Я использую Delphi для всех своих разработок и компилирую проекты из среды IDE.

Структура моих текущих проектов выглядит следующим образом:

-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)

Знак "-" обозначает каталоги.

Кто-нибудь хочет прокомментировать текущую структуру или есть предложения по ее улучшению?

Спасибо!

Answer 1

Установив буквально сотни проектов за эти годы и специализируясь на управлении конфигурацией программного обеспечения и разработке релизов, я бы рекомендовал вам сначала сосредоточиться на том, как вы хотите создать / выпустить свой (ые) проект (ы).

Если вы используете только IDE для сборки (компиляции и пакетирования) вашего проекта (-ов), то вы можете просто следовать соглашениям, типичным для этой IDE, плюс любые "лучшие практики", которые вы можете найти.

Однако я настоятельно рекомендую вам не строить только с IDE или даже вообще. Вместо этого создайте сценарий автоматической сборки / выпуска, используя один или несколько из множества замечательных инструментов с открытым исходным кодом. Поскольку вы, похоже, ориентируетесь на Windows, я рекомендую начать с проверки Ant, Ivy и соответствующего xUnit (jUnit для Java, nUnit для .NET и т. Д.) Для тестирования.

Как только вы начнете идти по этому пути, вы найдете множество советов относительно структуры проекта, разработки сценариев сборки, тестирования и т. Д. Вместо того, чтобы перегружать вас подробными рекомендациями сейчас, я просто оставлю вас с этим предложением - вы получите с готовностью найди там ответы на свой вопрос, а также найди гораздо больше вопросов, заслуживающих изучения.

Наслаждайтесь!

Судя по комментариям, кажется, что нужны некоторые детали.

Особая рекомендация, которую я хотел бы дать, заключается в том, чтобы вы разделили свою кодовую базу на отдельные подпроекты, каждый из которых создает один результат. Основное приложение (.EXE) должно быть одним, любые вспомогательные двоичные файлы будут отдельными проектами, установщик - отдельным проектом и т. Д.

Каждый проект создает один основной результат: .EXE, .DLL, .HLP и т. Д. Этот результат «публикуется» в одном общем локальном выходном каталоге.

Создайте дерево каталогов, в котором подпроекты являются одноранговыми (без глубины или иерархии, потому что это не помогает), и НЕ позволяйте проектам «доходить» до поддерева друг друга - каждый проект должен быть полностью независимым, с зависимостями ТОЛЬКО от первичные результаты других подпроектов, на которые есть ссылки в общем выходном каталоге.

НЕ создавайте иерархию сценариев сборки, которые вызывают друг друга, я это сделал и обнаружил, что это не добавляет ценности, но экспоненциально увеличивает усилия по обслуживанию. Вместо этого создайте сценарий непрерывной интеграции, который вызывает ваш автономный сценарий сборки, но сначала выполняет чистую проверку во временный каталог.

НЕ передавайте какие-либо результаты или зависимости в управление исходным кодом - ни вывод вашей сборки, ни библиотеки, которые вы используете, и т. Д. Используйте Ivy против бинарного репозитория, подобного Maven, который вы развертываете отдельно от управления источниками, и публикуйте свой собственный. результаты для обмена в вашей организации.

Да, и не используйте Maven - он слишком сложен, запутывает процесс сборки и, следовательно, не экономичен в настройке.

Я двигаюсь в сторону SCons, BuildBot, Ant, Ivy, nAnt и т. Д. В зависимости от моей целевой платформы.

Я составляю документ по этой теме, который, как я вижу, может иметь аудиторию.

РЕДАКТИРОВАТЬ: Пожалуйста, смотрите мой подробный ответ на Как вы организовываете свой репозиторий контроля версий?

Answer 2

почему 5.х? (по проекту А)

Я не думаю, что полезно вводить версии в дереве - для этого и нужны subversion и т. Д.