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

Question

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

Answer 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 конкретной машины.

В нашей среде IDE настроена переменная среды (т. Е. MRJ), которая указывает на «Общие \ Компоненты»\ Delphi ", поэтому в опциях проекта мы объявляем пути к нашим компонентам как $(MRJ)\MadCollection\2.6.0.0.

General содержит плагины 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

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

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

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

Answer 3

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

1. Сохраняйте простой путь к вашей библиотеке и убедитесь, что все в пути к библиотеке - это либо папка, поставляемая с delphi, либо двоичная (библиотечная) папка DCU в вашей папке d: \ Components \.

2. Используйте СОВРЕМЕННЫЙ тип управления версиями. Я рекомендую Mercurial над другими. Source Safe - это дерьмо, прекратите его использовать.

3. Создайте резервную копию вашей среды (экспортируйте ключи реестра и т. Д.) И восстановите ее на других компьютерах разработчика стандартным способом. Вы можете хранить несколько файлов .reg и .cmd (batch) для автоматизации установки новой системы. Вы можете поместить эти сценарии в свой репозиторий компонентов в своей системе контроля версий.

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

ps Сценарий сборки Ant определяет пути поиска для всего, поэтому он является «ссылкой».'для всех разработчиков, как настроить IDE, куда поместить сторонние библиотеки и какие флаги компилятора использовать

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

Answer 7

Советы Somé:

• Создайте один файл группового проекта для всех приложений, принадлежащих проекту, каждое приложение в своем собственном каталоге в файле groupproj

• Вы должны быть в состоянии указать, какие типы файлов включать в вашу систему контроля версий.Убедитесь, что вы настроили Delphi для записи файлов DFM в текстовом формате.

• Вы можете указать Delphi выводить DCU в подкаталогах с именем 'dcu' под каждым приложением (меньше беспорядка visul).

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

• Разработка на виртуальных машинах.Новый разработчик получает копию виртуальной машины.

• Поддержка для различных версий Delphi?Переосмыслите это, попробуйте перейти на одну версию.Если вам абсолютно необходимо иметь два групповых проекта и структуры каталогов для каждой версии.[Я предполагаю, что вы не компилируете одно и то же приложение с двумя версиями Delphi, это адский разработчик]

• Delphi XE2 будет выводить в разные подкаталоги 32/64, что не должно вызывать проблем.