Первая часть: Идеи и задачи автоматизации
💡 Цель первой части
Показать:
- с какими проблемами сталкивается Revit-разработчик без CI/CD;
- какие идеи и подходы лежат в основе автоматизации;
- как GitLab CI, Nuke и NuGet в симбиозе помогают упростить жизнь;
- зачем это нужно, даже если ты работаешь один;
- какие цели и перспективы ставились при внедрении этой практики.
🔧 Почему при разработке под Revit нужен CI/CD
- Сборка под конкретные версии Revit: обычно приходится пересобирать проект вручную под 2020, 2021, 2022 и т.д.
- Разные зависимости и API: каждый SDK требует отдельной настройки.
- Ошибки при ручной сборке: легко забыть переключить целевую платформу, версию .NET, забыть изменить путь вывода.
- Обновление плагинов в две стадии Development и Production : чтобы уменьшить пожары на production, можно внедрить тестовую группу пользователей (например bim-специалисты), чтобы в случае проблем плагин не нарушал цикл работы у проектировщиков.
🧱 Идеи и подходы, лежащие в основе автоматизации
В основе нашей системы автоматизации — простая, но мощная идея: Revit-плагины — это продукт, и подход к их сборке, доставке и обновлению должен быть соответствующий. Мы хотим, чтобы процесс сборки и распространения плагинов был:
- воспроизводимым — чтобы не зависел от настроек конкретного разработчика;
- прозрачным — чтобы можно было легко отследить, откуда появился конкретный build;
- предсказуемым — чтобы изменения в коде гарантированно доходили до пользователей нужной версии;
- гибким — чтобы мы могли работать с несколькими версиями Revit и несколькими аудиториями.
Для этого мы используем GitLab CI/CD, Nuke и раздельную публикацию NuGet-пакетов, а само окружение для сборки развёрнуто на выделенной GitLab Runner машине, где предустановлены SDK всех нужных версий Revit.
🛠 Сборка на выделенной машине
- Мы не запускаем сборку на shared runner'ах GitLab, а используем выделенный GitLab Runner, настроенный под наши задачи.
- На этом gitlab-runner установлены SDK Revit (2020–2025), .NET Framework, MSBuild и все зависимости, чтобы сборка плагина не зависела от локальной среды.
- Любое изменение в ветке Development и Production запускает триггер на сборку вашего проекта и публикацию на выделенный сервер. Рекомендую вести разработку в основной ветке, и уже потом итерационно накатывать изменения на ветви Development и Production.
🌿 Ветки и окружения: Development и Production
Одна из ключевых идей — разделение окружений по веткам Git:
В процессе автоматизации мы заложили идею разделения окружений в зависимости от ветки, в которую попадает код. Ветка Development используется как среда разработки (Development). Все коммиты и сборки, проходящие через неё, считаются тестовыми: они содержат черновые или экспериментальные изменения. Такие сборки автоматически распространяются среди ограниченного круга пользователей — в первую очередь BIM-специалистов и тестировщиков. Это позволяет быстро проверять новые функции, находить ошибки и получать обратную связь до релиза в Production.
Стабильные и готовые к использованию версии публикуются из ветки Production. Это считается продуктивной средой (Production). Плагины, собранные из этих веток, предназначены для широкого распространения среди проектировщиков и конечных пользователей. Такой подход позволяет отделить внутреннюю разработку от боевого применения, снизить риски и сделать обновления более управляемыми.
Что это даёт:
- Пользователи из тестовой группы всегда получают свежие версии для проверки новых функций.
- Проектировщики видят только проверенные и стабильные релизы.
- Одна и та же CI/CD-сборка может публиковать результат в разные директории на FTP-сервере в зависимости от ветки. Если код попадает в ветку Development, то собранный плагин размещается в папке DevelopmentPlugins, доступной только для тестовой группы. Если же изменения идут из ветки Production, то сборка автоматически отправляется в директорию ProductionPlugins, откуда её получают проектировщики. Такой подход обеспечивает простое и понятное разделение окружений, и еще раз повторюсь позволяет накидывать обновление на пользователей итерационно.
🔁 Как это работает: общий вид пайплайна
Вся автоматизация завязана на простую, но гибкую цепочку действий:
- GitLab Runner отслеживает изменения в репозитории и запускается при коммитах.
- Он вызывает скрипт сборки через Nuke — универсальную и кроссплатформенную систему автоматизации, написанную на C#.
- Nuke управляет всем процессом: от компиляции под нужную версию Revit до упаковки и публикации результатов.
- В зависимости от ветки (Development или Production), собранные .dll-файлы и вспомогательные ресурсы копируются на FTP-сервер в соответствующую папку (DevelopmentPlugins или ProductionPlugins).
- И уже лаунчер, предустановленный на компьютере проектировщика, сверяет актуальность файлов на ftp сервере и обновляет по необходимости из нужной папки. Лаунчер по обновлению плагинов в этой статье рассматриваться не будет, но небольшая подсказка: можете по дате изменения сравнивать файлы на хостинге и в локальной папке пользователя, на основании этого делать выводы какие файлы требуется обновлять))
- При необходимости, если проект представляет собой общую библиотеку, Nuke также собирает и публикует NuGet-пакет, который может быть использован в других решениях или плагинах.
Такой подход позволяет централизованно управлять всей цепочкой — от написания кода до распространения плагина среди пользователей — и при этом сохранять гибкость: легко адаптировать под другие проекты, добавить версии Revit, изменить структуру публикации и т.д.
Вторая часть: Переход к практике
Описание класса BasePluginBuild
Назначение
Класс BasePluginBuild представляет базовый шаблон для автоматизации сборки плагина Revit (или библиотеки), его упаковки и публикации на удалённые серверы (FTP и GitLab NuGet репозиторий). Используя Nuke, он структурирует процесс через набор целей (Targets), упрощая многократное использование и кастомизацию.
Основные возможности класса
- Конфигурация версии сборки:
Автоматический расчёт версии на основе параметров minorVersion, maintenanceVersion и значения конфигурации (например, Debug, Release).
Формат версии: major.minor.maintenance (например, 2024.1.0). - Чистка артефактов сборки:
Удаление содержимого папок bin и obj для выбранного проекта перед сборкой. - Компиляция проекта:
Запуск команды сборки с указанной конфигурацией и версией. - Загрузка скомпилированных DLL на FTP-сервер:
Подключение к FTP с использованием переменных окружения для аутентификации, проверка времени последнего изменения файла на сервере и загрузка новых или обновлённых DLL. При этом исключаются системные DLL и файлы от Autodesk. - Пакетирование NuGet-пакета:
Создание NuGet-пакета из собранного проекта без повторной сборки (используется уже скомпилированный артефакт). - Публикация NuGet-пакета в GitLab:
Загрузка собранного пакета в GitLab NuGet-репозиторий с проверкой API-ключа.
Дополнительные детали
- Для FTP-загрузки используется проверка последней даты изменения файла на сервере, чтобы избежать лишних загрузок.
- Исключены стандартные системные DLL (Revit API, Navisworks и др.), чтобы не загружать их повторно.
- Используются параметры из окружения (FTP_HOST, FTP_USER, FTP_PASSWORD, GITLAB_NUGET_API_KEY), что позволяет легко интегрировать процесс в CI/CD. Данные параметры необходимо через переменные gitlab передавать, чтобы не опубликовать лишние секреты наружу.
- Рекомендую BasePluginBuild данный класс вынести в отдельный корпоративный нугет пакет, чтобы файлы сборок в дальнейшем у отдельных проектах выглядели как на скриншоте ниже Build
Описание GitLab CI/CD файла
В данном файле описаны два этапа сборки плагина под Revit с помощью Nuke билдера — для среды разработки (Development) и продакшена (Production).
- Для каждой среды запускается отдельный job (build_development и build_production), который вызывает dotnet run с параметрами:
--Configuration — версия плагина (например, R21_Release),
--Stage — окружение (Development или Production),
--ProjectName — имя проекта для сборки. - Запуск задач привязан к веткам Git:
build_development — выполняется при коммитах в ветку Development,
build_production — в ветку Production. - В компании можно легко расширить этот конфиг, добавив скрипты для других версий Revit, например R22_Release, R23_Release и т.д., просто дописав новые jobs по аналогии с уже существующими.
Так же стоит обратить внимание на tags: по этому тегу запущенная заранее серверная машина с gitlab runner будет определять, что это задача на сборку направленна именно ей. Более подробно про настройку gitlab runner можно посмотреть тут.
Рекомендую завести отдельный сервер на Windows с установленными программами Revit и Navis, используемыми в вашей компании, чтобы в дальнейшем, например, запускать тесты в контексте данных программ.
Краткие примечания:
На скриншотах выше указано место, где можно сгенерировать токен, который может использоваться для публикации нугет пакетов и их получения внутри вашей компании.
На скриншоте выше указано место, где можно передать все необходимые переменные: FTP_HOST, FTP_USER, FTP_PASSWORD, GITLAB_NUGET_API_KEY. В рамках компании рекомендую сделать группу по bim разработке и задавать переменные для всей группы сразу, а не для проекта.
Для полной автоматизации процесса вам нужно дописать свой лаунчер по подмене dll файлов, а если у вас в компании используется несколько версий ревит, то доработать Nuke скрипт, чтобы файлы не просто падали в папки DevelopmentPlugins или ProductionPlugins, а падали в папки с префиксом версии Revit, например DevelopmentPlugins2021 или ProductionPlugins2021, DevelopmentPlugins2022 или ProductionPlugins2022.