Настройка большой программной системы в Delphi

У нас есть программный пакет, которому около 16 лет. Он прошел почти каждую версию Delphi (помимо .NET). На протяжении многих лет все становится очень запутанным, когда речь идет о перекрестных ссылках и правильной настройке дополнительных пакетов (например, сторонних библиотек). Мне было интересно, есть ли какая-то стандартная практика, когда речь идет о создании крупных проектов (и групп проектов), подобных этому.

Итак, чтобы объяснить текущую настройку...

Это многозадачная система. Смысл, есть 12 исполняемых проектов (и несколько DLL и сервисные проекты). Мы также держим вещи в SourceSafe, и несколько разработчиков работают над одним и тем же кодом на разных компьютерах. Все эти проекты более загружены в центральную папку. Папка "Root" содержит основной проект EXE (вместе с примерно 20 папками, все содержащие единицы и формы), и это почти похоже на бесконечную иерархию папок и файлов. Только один проект содержит полмиллиона строк кода.

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

Две мои основные проблемы:

Как правильно настроить файлы DCU, чтобы они не смешивались с проектами? DCU НЕ следует размещать в SourceSafe (и любом подобном файле, если на то пошло), или иначе - любой файл, скомпилированный из проекта. Visual SourceSafe делает файлы доступными только для чтения, когда их не выгружают, а файлы DCU (и EXE файлы и т.д.) Не могут быть записаны в этом случае. Итак, как правильно отделить любой из таких файлов с удаленным местоположением, чтобы избежать какой-либо смеси с исходным кодом?
Как правильно настроить пакеты и библиотеки? У нас есть следующее:
- QuickReports 5.05
- Библиотека NativeJpg V302 -
- Другая анонимная библиотека отчетов
- Наш собственный пакет компонентов, который требует QuickReports, NativeJpg и другую анонимную библиотеку

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

Нам также необходимо сохранять полностью отдельные среды для разных версий Delphi на одном компьютере. Это означает копию проектов на каждом компьютере, копию пакетов и библиотек на каждом компьютере, копию проектов и пакетов и библиотек в SourceSafe и т.д. Каждый компьютер должен иметь идентичную настройку. Мы уже используем переменные среды, чтобы направлять наши проекты, где искать определенные файлы проектов (и библиотеки).

Еще одна новая проблема: XE2 представляет 64-битные возможности. Мы еще не планируем на 64-битную компиляцию, но мы, безусловно, будем в будущем. Как правильно отличить 32bit от 64bit во всех этих проектах?

То, что я действительно прошу, - это ссылка на хороший учебник о том, как оптимизировать такую среду и держать ее организованной лучше всего. Я не ожидаю, что кто-нибудь найдет время и ответит на все это в вопросе. Проектам исполнилось более 15 лет, в их распоряжении были более 200 разработчиков со всего мира, и у них много перекрестных ссылок между проектами. Например, один проект может использовать единицу из другого проекта и наоборот. Мне лично это не нравится, но я также не разрабатывал его для начала. Мне была поставлена задача организовать эту систему и тщательно документировать, как настроить Delphi на новом компьютере для новых разработчиков для работы над нашими проектами. Поскольку я смотрю на наши проекты (поскольку я не обязательно разработчик системы, но меня втягивают в разработку), я вижу много путаницы в том, как организован код.

Я предполагаю, что, возможно, у Embarcadero есть некоторые рекомендации и стандарты по настройке такой среды?

Ответ 1

Расположение файлов DCU

Что касается DCU, которые являются результатом процесса компиляции, вы должны указать директорию вывода DCU в каждом файле проекта. Значение по умолчанию для этой версии в последней версии Delphi будет в порядке: .\$(Platform)\$(Config). Это приводит к тому, что вложенные папки каталога проектов выглядят следующим образом: Win32\DEBUG или Win64\RELEASE.

Если вы настроите файлы проекта с помощью наборов опций, вы сможете контролировать этот параметр (и все остальные) из небольшого количества файлов параметров.

Местоположение стороннего кода

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

Как только у вас будет весь ваш код в VCS, вы можете поместить весь исходный код на новый компьютер с помощью одной операции проверки.

Организация ваших проектов

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

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

Теперь, мотивируя сценарий, как бы вы создали среду сборки для 2-летнего проекта? Если вы используете пути поиска, то они будут ссылаться на сегодняшние библиотеки. Вам придется изменить путь поиска или скопировать старые библиотеки поверх сегодняшних библиотек.

Вся эта головная боль тривиально перешагнута, не используя пути поиска и включив весь ваш источник в VCS.

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

Ответ 2

Я рассмотрю организацию папок. Это происходит из программного пакета, в котором есть 50 + exe и dll и много сторонних библиотек, поэтому, я думаю, я знаю, откуда вы...

Мы используем Perforce в качестве исходной системы управления, поэтому моя корневая папка рабочего пространства по умолчанию называется Perforce, но у меня также есть несколько других рабочих областей, и они находятся в Perforce2, Perforce3 и т.д.

Настройка общей папки (начиная с корневой папки рабочего пространства)

General
  Components
    Delphi
      Indy
        Indy9
        Indy10
      MadCollection
        v2.5.8.0
        v2.6.0.0
  Plugins
Releases
  Released
  ... a folder for each release we publish ... (and equal to a branch in Perforce)
Work
  Acceptance
  Sub1
  Sub2

Мой путь библиотеки среды в среде IDE пуст (даже не существуют стандартные пути BDE). Это гарантирует, что пути проекта объявят весь необходимый путь и что проекты не зависят от конкретной установки IDE машины.

У нас есть среда var (т.е. MRJ), настроенная в нашей среде IDE, которая указывает на "General\Components\Delphi", поэтому в вариантах проекта мы объявляем пути к нашим компонентам как $(MRJ)\MadCollection\2.6.0.0.

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

Организация папок в конкретной рабочей ветке (Принятие или один из ее дочерних элементов) следует этой схеме:

General          
  Includes
  MainComponent1
    Project1
    Project2
    Shared
  MainComponent2  
    Project3
    Project4
    Shared
  Shared
Windows          
  SoftwareSuite  
    Scripts
      Tools
  MainComponent1
    Project1
      Dcus
    Project2
      Dcus
  MainComponent2  
  Tools
    Tool1
      Dcus
    Tool2
      Dcus

В папке General хранятся все независимые от платформы источники/файлы, в папке Windows хранятся все файлы, зависящие от Windows. Каждый компонент может содержать несколько проектов и иметь общую папку для источников, совместно используемых этими проектами. Общая папка непосредственно в разделе "Общие" содержит источники, общие для всех проектов. Папка Windows настроена аналогичным образом.

Обратите внимание, что каждый проект имеет свою собственную папку dcus. Это настраивается в параметрах проекта. Поскольку путь можно ввести как .dcus, мы (по крайней мере, я) установили его как значение по умолчанию для любого нового проекта. Каждый проект, отправляющий свой dcus в уникальную папку, обеспечивает две вещи:

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

Ответ 3

Я рекомендую следующие практики:

Простой путь к библиотеке и убедитесь, что все в пути к библиотеке - это либо папка, которая поставляется с delphi, либо двоичная (библиотека) DCU-папка в папке d:\Components \.
Используйте тип управления версией MODERN. Я рекомендую Mercurial над другими. Source Safe - это дерьмо, перестань использовать его.
Резервное копирование вашей среды (экспорт ключей реестра и т.д.) и стандартное восстановление на другие компьютеры разработчика. Вы можете сохранить несколько .reg и .cmd(пакетных) файлов, чтобы автоматизировать настройку новой системы. вы можете поместить эти сценарии в свой репозиторий компонентов в свою систему контроля версий.

Ответ 4

Вне области, которая в основном обсуждалась ранее, я бы рекомендовал:

Модульное тестирование - с DUnit например
Непрерывная интеграция. Просто чтобы быть уверенным, что все эти проекты могут быть скомпилированы на другой машине, и тесты будут в порядке.

Таким образом, это в значительной степени связано с организацией проекта и стратегией VCS.

Ответ 5

Для аналогичной настройки компания, с которой я работал, нашла эту конфигурацию полезной:

все сторонние библиотеки (компоненты и т.д.) переходят в фиксированное местоположение (C:\Delphi\name-version)
Проекты Delphi можно проверять в любом месте (диск C: или D: и имя папки не имеет значения), так как все проекты и скрипты используют относительные пути
все проекты являются вспомогательными папками одной основной папки проекта, поэтому, проверяя это, вы принесете на рабочую станцию проекты Delphi и другие соответствующие ресурсы, а обновление управления версиями легко выполнить
мы используем build script (написанный в Apache Ant), который находится в основной папке, и выполняет итерацию по всем папкам для создания приложений Delphi и запуска и интеграции тесты на сервере базы данных разработки, чтобы проверить все изменения перед проверкой на управление исходным кодом
сборка script также может запускаться автоматически на сервере сборки (Hudson CI) для каждой фиксации, чтобы увидеть, что-то сломалось

И примечание о библиотеках компонентов: избежать установки пакета, если это возможно, предпочитайте создание компонентов во время выполнения. Если вам быстро понадобится применить исправление к пятилетней версии проекта, удаление/установка дюжины пакетов может расстроиться. По крайней мере, для невизуальных компонентов создание времени выполнения - это огромная экономия времени.

Проверка стороннего кода в исходном элементе управления может быть очень полезной, например, для обмена исправлениями, которые пока недоступны в качестве новых официальных выпусков. Наилучшие практики описаны в главе документации Subversion Филиалы поставщиков. Кроме того, с Subversion вы можете использовать svn: externals, чтобы разместить определенную версию (тег) прямо в структуре каталога проекта. Это можно использовать как с сторонней библиотекой, так и с собственным исходным кодом, и упрощает управление зависимостями и настройку рабочей станции.

p.s. Ant build script определяет пути поиска для всего, поэтому это "ссылка" для всех разработчиков, как настроить среду IDE, где размещать сторонние библиотеки и какие флаги компилятора использовать

p.p.s. ваш проект звучит очень весело - я открыт для контрактной работы:)

Ответ 6

Моя команда использует виртуализацию, и когда мы видим назад, это был настоящий хороший ход. Мы используем ноутбуки MacBook Pro и VmWare Fusion, но я уверен, что другие пакеты работают так же хорошо, как VirtualBox или VirtualPC.

Всегда хорошо знать, что, когда новый разработчик запускается или у старой установки возникают проблемы, нужно просто скопировать новый образ виртуальной машины из главного образа, а настройка точно, поскольку оригинал. Основное изображение хранится на быстром USB2-диске. Теперь, когда появятся Thunderbolt и USB3, было бы еще быстрее скопировать изображение. И нет никакой реальной проблемы с производительностью на современном компьютере, пока есть память. 8 ГБ должно быть достаточно для запуска 2 изображений в параллельном режиме. Еще одно преимущество виртуализации заключается в том, что так легко попробовать сценарий Что делать, если. Экспериментируйте с различными конфигурациями и версиями, не рискуя нарушить реальную рабочую среду.

Btw Я также считаю, что SourceSafe - это дерьмо...: -)

Ответ 7

Советы Somé:

Сделайте один групповой проект для всех приложений, принадлежащих проекту, каждое приложение в своем собственном каталоге в файле groupproj
Вы должны указать, какие типы файлов должны быть включены в вашу систему контроля версий. Убедитесь, что вы установили Delphi для записи файлов DFM в текстовом формате.
Вы можете сказать, что Delphi выдает DCU в поддиректорах под названием "dcu" под каждым приложением (менее визовом беспорядке).
Сторонние вещи часто настаивают на установке в разных местах, там мало что можно сделать. Создайте документ, описывающий, как настроить полную рабочую среду и поддерживать ее в актуальном состоянии
Разработка на виртуальных машинах. Новый разработчик получает копию виртуальной машины.
Поддержка разных версий Delphi? Переосмыслите это, попробуйте перейти к одной версии. Если вы абсолютно должны иметь два групповых проекта и структуры каталогов для каждой версии. [Я предполагаю, что вы не компилируете одно и то же приложение с двумя версиями Delphi, разработчиком ад]
Delphi XE2 будет выводиться в разные подкаталоги 32/64, что не должно создавать проблем.