CI/CD-подход, или разработка решений на платформе «1С» без использования хранилищ
Классический подход
Традиционный подход к разработке предполагает аккумуляцию всех обновлений в один большой пакет перед развертыванием новой версии ПО. При работе с платформой «1С» это означает продолжительное взаимодействие с хранилищем разработки и хранилищем релизов. Это простая, понятная и проверенная схема, которая отлично подходит для небольшой команды и небольшого количества изменений.
Однако при работе с крупными проектами, классический подход к разработке начинает приводить к ряду серьезных проблем:
-
монопольная работа с одним объектом конфигурации «1С» не позволяет параллельно вносить изменения нескольким разработчикам;
-
отслеживание множества изменений по конкретной задаче затруднено — как следствие, в продуктивный контур попадают «незапланированные» изменения;
-
невозможно приостановить работу над задачей без потери кода;
-
множество ручных операций, связанность изменений не позволяют оперативно предоставлять функциональность конечным пользователям;
-
конфигурация на продуктивном сервере может отличаться от согласованного релиза в хранилище;
-
тестирование либо не проводится вовсе, либо является ручным и частичным, что не гарантирует отсутствия критичных ошибок и уязвимостей в продуктивном контуре.
Как правильно
Чтобы избежать всех этих проблем, при работе над крупным проектом стоит применять DevOps-практики, а именно комбинацию непрерывной интеграции (Continuous Integration, CI) и непрерывной поставки/развертывания (Continuous Delivery, CD) программного обеспечения. В контексте «1С», CI означает сборку решения и проверку его работоспособности, а CD — обновление собранным решением тестового стенда для ручного тестирования, а также продуктивного контура для непосредственного использования конечными юзерами.
Методология CI предполагает внесение небольших правок в код с оперативными коммитами (сохранениями изменений в репозитории), частые автоматизированные сборки проекта (упаковки ПО, базы данных и других компонентов по факту обновления репозитория или по расписанию), механизм интеграции и проведение регулярных автоматизированных тестов (нагрузочных, интеграционных, регрессионных и других) для раннего выявления потенциальных дефектов, ошибок и уязвимостей. CI/CD позволяет увеличить производительность, повысить надежность и безопасность кода и гарантировать быстрые циклы выпуска ПО.
Для выполнения сборки ПО вместо использования хранилища стоит перейти на разработку с использованием системы контроля версий git. Эта технология позволяет вести параллельную разветвленную разработку одного решения (проекта), где каждая ветка содержит полный набор всех файлов. Любую ветку можно отдельно собрать, выполнить проверку работоспособности решения с внесенными изменениями и принять решение о готовности и возможности вливания изменений в общую кодовую базу решения. Использование git, по сути, является новым стандартом в разработке решений на платформе «1С:Предприятие 8» — только эта система контроля версий поддерживается новой средой разработки «1C:Enterprise Development Tools».
Что касается тестирования, его можно проводить как вручную, так и автоматизировано. Автоматизированное тестирование поведения давно доступно за счет предоставления механизмов менеджера и клиента тестирования, включенных в состав самой платформы «1С:Предприятие». Существующий набор инструментов для написания тестов поддерживает их выполнение в автоматизированном режиме в CI-конвейерах, что позволяет проверять каждое зафиксированное в репозитории изменение без участия человека.
Кроме непосредственно тестирования функциональности, необходимо анализировать и качество кода — обнаруживать ошибки и отклонения от требований по написанию кода. На данный момент стандартом считается применение статического open-source анализатора SonarQube с плагином для языка «1С», имеющего в своем составе богатый набор диагностик, постоянно пополняемый сообществом.
Отдельно стоит упомянуть возможность создания в «1С» конвейера «ночной сборки» для полного прогона всех проверок на тестовом стенде в нерабочее время.
Ночные тесты. Источник: BIA Technologies
За непрерывной интеграцией следует непрерывная поставка. CD предполагает частые (порой даже ежечасные!) автоматизированные релизы проекта в целевое окружение для скорейшей поставки функциональности пользователям. С помощью CD-инструментов автоматически производятся запросы к базам данных, веб-серверам и прочим необходимым сервисам, которые могут нуждаться в перезапуске или выполнении определенных действий при развертывании системы. Далее осуществляются дополнительные тесты, логирование и отправка оповещений о результатах тестирования. В случае провала теста, происходит автоматический откат итерации.
На практике
Опишу переход на CI/CD-методологию на реальном примере из нашей практики.
Заказчик хотел автоматизировать процесс сборки и поставки решений на платформе «1С:Предприятие». При автоматизации нужно было учесть изолированность контуров тестирования, предпродуктива и продуктива, интеграцию с системами проверки кода заказчика, а также организационную и территориальную структуру компании в части принадлежности информационных баз, ответственных и технологических окон.
Что было сделано:
-
разработка решений на «1С» переведена на использование системы ALM (Application Lifecycle Management), в которой ведутся задачи на разработку, ведется приемка результатов, исходный код хранится в git;
-
разработана архитектура ландшафта, включающая в себя изолированные кластера сборочных серверов, имеющих доступ только к нужным сегментам сети (управление происходит из единого центрального сервера ALM, не имеющего доступа к информационным базам и стендам);
-
разработаны сценарии сборки и тестирования решения, автоматически запускающиеся при возникновении событий в системе контроля версий;
-
создан шаблонный сценарий релизного конвейера, включающий этапы тестирования на тестовом окружении, испытаний на предпродуктивном стенде и поставки на продуктивный сервер; шаблон позволяет настраивать сценарии для развертывания релиза исключая отдельные среды, либо указывая несколько информационных баз в среде (для параллельной поставки).
В результате заказчик добился существенного сокращения релизного цикла, получил возможность работы над одним решением любого количества команд, включая внешних подрядчиков, с более простым процессом верификации и объединения изменений, а также смог осуществлять автоматическую сборку и поставку релиза на продуктивную среду для каждой информационной системы в удобное технологическое окно.
* * *
Конечно, переход на CI/CD-методологию требует определенных затрат и усилий: необходимо перестроить процессы разработки, тестирования и поставки решения, обучить новым технологиям и подходам всех сотрудников, выделить бюджет на дополнительное ПО и «железо» и в дальнейшем поддерживать новые инструменты в рабочем состоянии. Нужно быть готовым к тому, что в первые 2–6 месяцев команда столкнется с просадкой в производительности разработки в 2–3 раза.
Но игра стоит свеч: практика CI/CD сведет число регрессионных ошибок к минимуму, снизит количество рутинных операций за счет их автоматизации, выстроит четкую взаимосвязь между требованиями и внесенными изменениями, позволит разработчикам сосредоточиться на улучшении системы и не тратить силы на ее развертывание, сократит time-to-market и, самое важное, повысит качество решений в целом.
Наталья Усова, директор практики 1С BIA Technologies
Опубликовано 07.01.2023