Рекомендация папок проектов - программирование

Я готов к внедрению системы управления версиями (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)

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

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

Спасибо!

Ответ 1

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

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

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

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

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

Основываясь на комментариях, кажется, что необходимы некоторые детали.

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

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

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

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

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

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

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

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

EDIT: см. мой подробный ответ на Как организовать репозиторий управления версиями?

Ответ 1

Ответ 2