Наш DevOps: вчера, сегодня, завтра

О чем эта история

Меня зовут Андрей Ворона, я инженер DevOps. Я работаю в 1С с 2002 года – начинал еще с версии 7.7. За свою карьеру прошел путь от разработчика до специалиста по автоматизации процессов. В статье хочу рассказать, как у нас в команде происходило внедрение DevOps-подхода, какие этапы мы прошли, какие решения принимали и какие сложности встретили на пути.

Эта история будет не о том, как все делается «по книжкам», а о реальном опыте – уникальном, местами болезненном, но результативном. Я буду говорить «мы», потому что это не моя личная история – это опыт всей нашей команды.

Начало пути: выбор Jenkins как сервера автоматизации

Все началось с выбора инструментов. Мы решили использовать Jenkins в качестве сервера автоматизации. Почему именно он, а не GitLab или другой CI/CD-инструмент? Во-первых, на тот момент большинство компаний уже использовали Jenkins, так что мы просто шли за общей тенденцией. Во-вторых, GitLab тогда был лишь хранилищем выгруженного из хранилища кода, разработчики туда не ходили, ничего там не делали.

Сейчас ситуация изменилась, и GitLab стал играть важную роль. Часть команд ведет разработку на EDT, разработчики заходят туда, чтобы сделать запрос на слияние, провести код ревью. Возможно, если бы мы выбирали сейчас, то наш выбор был бы другим.

Все файлы Jenkins и настройки проектов мы хранили в едином репозитории. Это позволило нам структурировать процессы и унифицировать подходы. Для запуска задач указывался источник настроек, результаты тестирования выводились в Allure и на сервер SonarQube. Артефакты хранились на сетевых дисках, а для повторного использования функционала между пайплайнами использовались подключаемые модули.

Переход на EDT: шаг к групповой разработке через Git

Одним из ключевых этапов стало внедрение EDT (1C:Enterprise Development Tools). Это дало возможность перейти к групповой разработке через Git. Раньше мы работали через хранилища объектов, где часто возникали проблемы: захват объектов, очереди, взаимоблокировки.

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

Переход на Git позволил организовать полноценную непрерывную интеграцию (CI). Теперь, когда разработчик создает Merge Request, автоматически запускаются проверки качества кода и тесты. Результаты отправляются ревьюверу, который принимает решение – принять или отклонить изменения. Таким образом, проверка происходит до слияния, а не после, как это было ранее.

Организация ветвления и автослияние

Мы используем простую схему ветвления: есть ветка master, в которой находится стабильный код. Для каждой задачи разработчики создают собственную ветку, которая периодически обновляется из master благодаря автослиянию. Это позволяет как можно чаще интегрировать актуальные изменения и выявлять конфликты на ранних этапах. Если при автослиянии возникают конфликты, разработчик получает уведомление и должен их разрешить.

После завершения работы над Merge Request и успешного прохождения всех проверок изменения объединяются с master. Перед выпуском релиза ветка master блокируется, делается тег на нужный коммит, формируется комплект поставки, который окончательно тестируется и устанавливается в продакшен. Затем ветка разблокируется.

Единые стандарты проектов и использование Pipeline Libraries

Чтобы упростить работу с несколькими проектами, мы пришли к единому стандарту структуры проектов. Например, в каждом репозитории есть каталог для инициализации данных, куда кладутся XML-файлы эталонных баз для тестов. Также в одном месте находятся исходники основной конфигурации, расширений и обработок – это удобно при работе в EDT.

Для управления пайплайнами мы используем библиотеку Pipeline Libraries, вдохновленную проектом Jenkins Lib Никиты Федькина. Благодаря этому Jenkins-файлы остаются компактными, а основной функционал вынесен в отдельные модули. Можно легко менять версии библиотек, тегировать их и использовать разные версии для разных проектов или каталогов. Это обеспечивает гибкость и безопасность при тестировании новых возможностей.

Тестирование: параллельное выполнение и отчетность

Тестирование проводится последовательно-параллельно на нескольких виртуальных машинах. Сразу после начала сборки параллельно запускается проверка качества кода через SonarQube и подготовка баз данных. После подготовки базы параллельно выполняются дымовые тесты, проверка синтаксиса конфигурации и валидация средствами EDT. Сценарные тесты тоже запускаются параллельно, согласно блокам, на которые они разбиты, но на других машинах. Так как unit тестов у нас не много, и они выполняются быстро, то они не вынесены в параллельный блок, а выполняются после всех тестов. Результаты всех тестов собираются в едином отчете Allure.

Подготовка базы для тестов включает загрузку эталонной базы, конвертацию кода ветки из формата EDT, загрузку сконвертированных файлов в базу, выполнение неотложных обработчиков обновления и инициализацию данных из файлов в формате XML. Если нужно протестировать реструктуризацию, то предварительно база откатывается до версии, относительно которой нужно тестировать реструктуризацию, и заданным образом включается запись в технологический журнал. Такая гибкость позволяет заранее выявлять потенциальные проблемы при обновлениях.

Инициализация данных и работа с тестами

Инициализация данных – важная часть процесса. Допустим, разработчик меняет алгоритм формирования движений документа. Это вызывает падение дымовых тестов, так как в них проверяется корректность этих движений. Чтобы тесты не падали, разработчик добавляет выгрузку правильных движений с учетом доработки в каталог инициализации. Для этого используется стандартная обработка – универсальный обмен данными в формате XML.

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

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

Мониторинг и метрики: контроль состояния систем

Для мониторинга используются Grafana и Prometheus. Основные метрики – количество упавших сборок и «здоровье» регламентных пайплайнов. Это позволяет оперативно реагировать на сбои и своевременно их устранять.

Регламентные пайплайны отвечают за выполнение фоновых задач, таких как обновление эталонных баз или формирование комплектов поставки. Мы следим за тем, чтобы все они выполнялись корректно и полностью.

Переход в Kubernetes: новые возможности и вызовы

На данный момент мы работаем над переходом в Kubernetes. Цель – перевести сервисы (Jenkins, Nexus, Prometheus, Grafana) в эту среду для лучшей масштабируемости, отказоустойчивости и возможности использовать подход «инфраструктура как код». Также планируется запускать тесты в контейнерах, чтобы эффективнее использовать ресурсы и уменьшить влияние «мусора», который накапливается на виртуальных машинах.

Несмотря на преимущества, у такого подхода есть и сложности: непривычная среда исполнения, трудности с отладкой и особенности работы 1С в контейнерах. Однако сообщество уже нашло решения этих проблем, и мы активно ими пользуемся.

Как мы обосновали необходимость DevOps бизнесу

Интересный момент: бизнес сам пришeл к нам с идеей внедрения DevOps. В компании много IT-команд, которые занимаются веб-сервисами, мобильными приложениями и другими продуктами. У них уже существовала система DevOps, и они видели ее преимущества. Представители бизнеса спросили: «А почему у вас, 1С-разработчиков, этого нет? Вы же тоже программисты». Так началась наша история.

DevOps действительно помогает: если тесты ловят ошибки за 15 минут до выхода в прод, люди понимают ценность подхода. А когда команда чувствует, что процессы улучшают качество и скорость работы, внедрение становится органичным.

Итоги: что у нас есть и куда мы идeм

С момента начала пути команда значительно эволюционировала:

• Jenkins-файлы теперь хранятся в репозитории проекта.

• Артефакты – в Nexus.

• Появились юнит-тесты и возможность выполнять тесты на автономном сервере.

• Интеграция с GitLab позволяет запускать проверки при событиях в репозитории – например, при создании Merge Request или обновлении ветки master.

Число используемых виртуальных машин увеличилось с 5 до 50, что связано с ростом числа проектов и необходимостью параллельного тестирования каждого Merge Request.

Мы продолжаем развивать инфраструктуру, переходим на Kubernetes и внедряем новые практики. Это не самый простой путь, но он даeт реальные результаты.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.