Автоматизация сборки Delphi-проектов с помощью Jenkins
Когда команда поддерживает несколько платформ — Android, iOS, Windows, macOS, Linux — ручная сборка превращается в источник постоянных ошибок. Пропущенный коммит, забытый релизный флаг, несовпадение версий библиотек: всё это стоит времени и нервов. В небольших проектах ещё можно обойтись локальной компиляцией на машине разработчика, но при росте числа целевых систем ручной режим быстро перестаёт справляться.
Я давно использую Jenkins как основной сервер непрерывной интеграции. Этот инструмент сочетает открытый исходный код, гибкую систему плагинов и удобную поддержку Windows-агентов, что критично для Delphi. Большинство альтернатив либо плохо работают с Windows, либо требуют сложной настройки. Jenkins же ставится за вечер и масштабируется по мере роста проектов.
Особенность Delphi в том, что компилятор тесно связан с RAD Studio и работает только под Windows. Это означает, что часть инфраструктуры придётся развернуть на «винде» даже тем, кто привык к Linux-серверам. В моей практике Jenkins стал связующим звеном между репозиторием, агентом сборки и хранилищем артефактов, а заодно позволил перенести часть операций из RAD Studio в скрипты.
Преимущества Jenkins для Delphi-проектов
Главное достоинство Jenkins — это его экосистема плагинов. Для Delphi-разработчика полезны Pipeline, Git, MSBuild, Warnings NG и Email-ext. С их помощью удаётся собрать пайплайн без написания внешних сервисов. Кроме того, Jenkins бесплатен и работает локально, что важно для проектов, где нельзя передавать исходный код во внешние облака.
Вторая сильная сторона — распределённые сборки. Можно поднять несколько агентов на разных машинах: на одной собирать VCL-приложения для Windows, на другой — FireMonkey-версии под macOS, на третьей — Android через командную строку Kotlin и Delphi одновременно. Каждый агент получает свой набор переменных окружения и путей к RAD Studio, что упрощает изоляцию проектов.
Наконец, Jenkins хранит историю сборок, артефакты, логи и метрики. Это позволяет анализировать, как менялось время компиляции, какие ветки стабильнее и где чаще появляются ошибки. Для кросс-платформенной разработки, где правки затрагивают несколько целевых систем, такой архив становится бесценным. Если вы только начинаете выстраивать процессы, посмотрите, как оформлен каталог на сайте с примерами проектов — там видно, сколько разных конфигураций приходится поддерживать.
Подготовка агента сборки
Агент для Delphi-проектов — это Windows-машина с установленной RAD Studio, JDK и агентом Jenkins. Я предпочитаю выделять отдельный сервер или виртуальную машину, чтобы не зависеть от рабочих компьютеров разработчиков. На агенте обязательно настраиваются переменные окружения: путь к BDS, BDSBIN, BDSCOMMONDIR, FrameworkDir и каталог с эмуляторами, если планируется сборка под мобильные платформы.
После установки агент регистрируется на главном сервере через JNLP или WMI. Для проектов на FireMonkey важно, чтобы агент имел доступ к лицензии RAD Studio — сетевой или локальной. Без неё компилятор выдаст ошибку при попытке собрать релизную конфигурацию. На практике я завёл отдельную служебную учётную запись Windows, под которой агент работает как сервис: так проще управлять правами и перезапускать процесс после обновлений.
Дополнительно стоит установить Git, MSBuild, сборочные утилиты для Android SDK и NDK, а также драйверы для тестовых устройств, если предполагается физическое тестирование. Весь набор инструментов версионируется в документации проекта, чтобы новые участники могли быстро развернуть идентичное окружение.
Сравнение способов запуска компилятора
Delphi предлагает несколько путей запуска компиляции, и выбор зависит от типа проекта. Для классических VCL-приложений удобнее всего работать с .dproj и MSBuild, тогда как небольшие утилиты и скрипты часто собираются напрямую через dcc32 или dcc64. У каждого способа свои требования к окружению и свои ограничения.
Чтобы быстро ориентироваться в этих вариантах, я составил небольшую сводку — она помогает выбрать подходящий механизм на старте проекта и при миграции между версиями RAD Studio.
| Способ | Где применяется | Плюсы | Минусы |
|---|---|---|---|
dcc32 / dcc64 напрямую |
Старые проекты, утилиты командной строки | Минимум зависимостей, быстрый запуск | Нет зависимостей проекта, сложно передавать макросы |
MSBuild + .dproj |
VCL, FMX, кросс-платформенные проекты | Полная поддержка конфигураций Debug/Release | Требует корректного .dproj и версии MSBuild |
rsvars.bat + MSBuild |
Корпоративные решения, CI-агенты | Правильные переменные окружения RAD Studio | Нужно вызывать rsvars.bat перед сборкой |
| Скрипт-обёртка PowerShell | Сложные пайплайны с подписью и публикацией | Гибкость, обработка ошибок | Больше кода, надо сопровождать |
В большинстве моих проектов побеждает связка rsvars.bat и MSBuild. Она запускает компилятор с теми же переменными, что и RAD Studio, но не требует графической оболочки. Для совсем маленьких утилит иногда удобнее прямой вызов dcc32 — это ускоряет отладку скриптов и снижает зависимость от .dproj. Если же предстоит сложный релиз с подписью, упаковкой в msi и публикацией в корпоративный репозиторий, я добавляю PowerShell-обёртку, которая управляет всем процессом.
Jenkinsfile и параметризация
Когда агент готов, логику сборки удобно описать в Jenkinsfile. Декларативный синтаксис позволяет задать несколько стадий — Checkout, Build, Test, Package, Deploy — и связать их условиями. Для Delphi-проектов я выделяю отдельные шаги под каждую целевую платформу: сборка Windows, сборка macOS, сборка Android. Это даёт наглядную картину, какая конфигурация упала.
Параметры пайплайна помогают управлять процессом без правки файла. Обычно я объявляю TARGET_PLATFORM (Windows, macOS, Android, iOS), CONFIGURATION (Debug, Release), VERSION (номер сборки) и SIGN (true/false для подписи). При запуске из интерфейса Jenkins разработчик выбирает нужные значения, а скрипт подставляет их в команды. Такой подход снижает количество ручных ошибок и делает сборки воспроизводимыми.
Ещё один приём — кеширование промежуточных артефактов. Delphi генерирует множество .dcu, .bpl, ресурсных файлов. Если перенести их в отдельный каталог и сохранять между сборками через плагин Workspace Cleanup, повторные прогоны заметно ускоряются. На больших проектах экономия достигает 30–40 %.
Интеграция с Git и уведомления
Чтобы Jenkins реагировал на изменения в репозитории, я настраиваю webhook между Git-сервером и сервером сборки. Для GitHub и GitLab есть готовые плагины, для собственного Gitea — универсальный webhook-плагин. После каждого push запускается нужная ветка пайплайна, что избавляет от ночных «сломанных» релизов.
Уведомления отправляются в Telegram и на почту. Telegram-бот удобен для мгновенных оповещений: он показывает, какая стадия упала, и прикладывает ссылку на лог. Email-ext подключается для ежедневных сводок и критических ошибок. Такой дублирующий канал помогает не пропустить проблему, даже если разработчик офлайн.
В перспективе можно прикрутить анализ компилятора Delphi и публиковать метрики в Grafana, но это уже тема отдельного материала — если интересно, посмотрите обзор темы Jupiter X и принципы визуализации данных, многие из них переносятся и на CI-дашборды. В итоге Jenkins закрывает задачи, которые раньше решались вручную или через самописные скрипты. Автоматизация сборки Delphi-проектов экономит часы, делает релизы предсказуемыми и позволяет сосредоточиться на коде, а не на обслуживании инфраструктуры.