Внедрение механизмов CI/CD в процессы разработки под Directum RX

Введение

CI/CD (Continuous Integration, Continuous Delivery – непрерывная интеграция и доставка) – технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам (разработчикам, аналитикам, конечным пользователям и др.). Оно позволяет значительно сэкономить и сократить временные и финансовые затраты на поддержку. Также благодаря CI/CD баги системно выявляются на ранней стадии разработки, что значительно сокращает шансы возникновения серьёзных рисков для заказчика. Кроме того, непрерывная интеграция и поставка позволяет избежать репутационных и финансовых потерь, возникающих по причине возникновения багов после поставки продукта в продакшен.

Цели и задачи проекта

Основная задача проекта – автоматизация доставки изменений продукта в соответствующую среду: на тестовый и препрод стенды (для первичной проверки и тестирования) или в продакшен (для непосредственного внедрения в рабочий бизнес-процесс). Решение данной задачи позволило бы избавить разработчика и/или администратора системы от обязанностей по сборке, выгрузке и публикации пакета разработки, тем самым повышая продуктивность разработки в целом и попутно сокращая время доставки изменений на стенд.

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

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

Описание и возможности решения

Решение построено с использованием следующих компонент:

• инструмент для реализации процесса CI/CD – TeamCity
• исходный код хранится на корпоративном GitLab
• статический анализатор кода - Resharper от компании JetBrains
• стенды на ОС Windows
• нотификация выполнения процессов отправляется в канал MS Teams
• Directum RX 4.4

Для организации процесса CI/CD было создано несколько конфигураций в TeamCity :

рисунок 1. Конфигурации CI/CD

1. Dev-валидация

Инициатором запуска процесса является событие публикации разработчиком dev-ветки в систему контроля версий (Gitlab). CI/CD, отслеживая состояние Dev_* веток согласно установленному паттерну, при обнаружении изменений запускает процесс Dev-валидации.

В начале проверки выполняется загрузка Dev_* ветки в рабочий каталог с прикладными решениями (Work), а также исходный код базового решения (Base). Далее для сборки решения в невизуальном режиме, используя PowerShell CLI, запускается Development Studio (SDS).

Небольшое отступление: использование сторонних IDE и встраивание анализаторов кода затруднено ввиду отсутствия общего файла решения (.sln). Построить его обычные IDE не в силах ввиду сложной иерархии зависимостей проектов.

Успешность завершения процесса сборки проверяется по наличию созданного пакета публикации (т.к. при работе SDS в невизуальном режиме нет возможности вывода результата в stdout). В случае ошибки выполняется чтение последних 10 строк лога SDS:

Рисунок 2. Пример лога с сообщением об ошибке в процессе сборки

При отсутствии ошибок выводятся сообщения следующего вида:

Рисунок 3. Пример лога в случае успешной сборки пакета публикации

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

Рисунок 4. Пример результата работы Resharper по анализу кода

Рисунок 5. Расшифровка результатов проверки Resharper

Полностью весь процесс прохождения dev-валидации занимает порядка 20 мин.:

Рисунок 6. Лог TeamCity всего процесса успешной dev-валидации

2. Публикация на тест/препрод стенды

При успешном прохождении dev-валидации разработчик или ответственное лицо оформляет merge request (MR) в release_* ветку. После проверки и принятия MR ведущим разработчиком запускается CI/CD процесс на публикацию пакета разработки на тестовый стенд.

Для публикации пакета разработки на целевой стенд используется запуск DeploymentTool в невизуальном режиме (используя PowerShell CLI).

Тут стоить отметить несколько моментов:

Слияние из Dev_* в release_* ветку становится доступным после получения SUCCESS статуса CI/CD пайплайна, что отслеживается на стороне GitLab:

Рисунок 7. Статус пайплайна после выполнения MR

На сервере Directum RX посредством IIS реализован механизм ограничения доступа, который отображает страницу-заглушку «Сайт на обновлении» и блокирует вход пользователям в систему до завершения процесса обновления, что позволяет избежать проблем во время публикации и инициализации пакета.

Рисунок 8. Страница-заглушка на период обновления системы.

В случае успешного завершения процесса публикации пакета разработки настроено уведомление всех заинтересованных лиц посредством отправки информации в канал:

рисунок 9. Сообщение в канале MS Teams после успешного обновления стенда.

При возникновении ошибок создаются оповещения по эл. почте:

рисунок 10. Письмо-уведомление об ошибке при публикации.

После успешной публикации пакета разработки на тестовом стенде запускается процесс интеграционного тестирования. Для выполнения регрессионных тестов используется Selenuim WebDriver. Если какие-то тесты требуют внимания, они отображаются в TeamCity в соответствующем разделе:

Рисунок 11. Список не пройденных тестов

После успешной публикации доработок на тестовом стенде и прохождения тестирования, оформляется MR в release_candidate_* ветку для запуска CI/CD процессов публикации на препрод стенд. Процесс аналогичен вышеописанному для тестовой среды, но с параметрами, соответствующими препрод стенду.

Весь процесс публикации на тестовый/препрод стенд занимает порядка 40 минут и выглядит следующим образом:

Рисунок 12. Лог выполнения процесса публикации разработки

Результаты

Итогом работы стали настроенные процессы автоматической проверки и публикации решений, создаваемых разработчиками. Благодаря этому достигнуты следующие цели:

• экономия времени разработчиков (порядка 1 ч на каждую проверку сборки и публикацию пакета), что позволило сосредоточиться на создании доработок без отвлечения на процесс тестирования и публикации.
• внедрение анализаторов кода позволило наладить непрерывный процесс улучшения его качества.
• внедрение интеграционного тестирования позволило выявлять ошибки до момента публикации в рабочую среду.
• настроены оповещения ключевых пользователей системы о завершении процессов CI/CD.

Общий срок реализации проекта составил около 5 месяцев (параллельно с другими проектами). На сегодняшний день процесс сборки, проверки и публикации на тест и препрод стенды работает успешно с ноября 2023 г. За это время суммарно выполнено ~200 коммитов – таким образом, экономия рабочего времени одного разработчика составила порядка 20 рабочих часов в месяц.

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

Сложности реализации

В процессе реализации проекта мы сталкивались с различными проблемами, часть которых существенно влияли на сроки реализации:

• отсутствие в Directum RX единого инструмента для автоматизированного процесса непрерывной доставки (или интеграции с инструментами CI/CD);
• отсутствие настроек для включения возможности уведомлений и предупреждений пользователей о текущем обновлении (данная проблема решена в версии 4.9 наличием режима технического обслуживания);
• отсутствие в открытом доступе информации и опыта настройки процессов CI/CD, примеров разработанных решений на рынке, отсутствие документации данных возможностей, информации на форумах и т. д.;
• сложность использования «из коробки» сторонних IDE ввиду отсутствия общего файла решения (.sln), который обычные IDE не в силах построить ввиду сложной иерархии зависимостей проектов;
• сложность встраивания в процесс анализаторов кода на уровне решения из-за постоянной автогенерации файла решения (.sln);
• часть функционала из базового решения Directum RX Base оценивается анализатором как ошибочное ввиду специфики приложения – пришлось исключать из проверки базовые проекты и модифицировать правила для остальной части кода;
• отсутствие возможности перенаправления потока создаваемых логов в stdout для их отображения в терминале запуска (и в инструменте CI/CD) при использовании в невизуальном режиме инструментов Directum RX;
• как следствие вышеперечисленных проблем - сложность оптимизации процессов CI/CD.

Перспективы развития решения

С появлением в сети (в т. ч. на Directum club) информации о встраивании процессов CI/CD стало возможно перенимать опыт коллег, использовать передовые практики и инструменты.

Планируется:

• сократить время сборки пакета (есть сложности из-за отсутствия информации о нюансах работы SDS при сборке и недостаточно информативном отображении хода процесса);
• закончить настройку процесса интеграционного тестирования (+ расширить количество тестов);
• распространить практику автоматической публикации на продакшен стенд (при слиянии проверенной ветки release_candidate_* в master ветку).

Команда проекта

• Пономарев Кирилл - руководитель отдела разработки информационных систем
• Мигачев Константин – инженер по управлению программной инфраструктурой
• Сорокин Андрей – ведущий программист
• Зубков Владимир – программист
• Маркин Павел – тестировщик