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

11.07.25

Разработка - DevOps и автоматизация разработки

Цель статьи – показать, что DevOps можно внедрять в проектах любого масштаба, даже с ограниченными ресурсами. Автор делится личным опытом: рассказывает, как начиналось внедрение, какие ресурсы потребовались, какие задачи удалось решить и как организован текущий рабочий процесс. Вы узнаете, как DevOps-практики помогают участникам разработки и чем DevOps-инженеры полезны для всех, кто участвует в создании решений. В статье подробно разбираются преимущества, которые дал переход на EDT, его влияние на процессы сборки, а также анализируется опыт внедрения Kubernetes – что это уже принесло и что принесет в будущем.

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

 

Меня зовут Андрей Ворона, я инженер 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.

Вступайте в нашу телеграмм-группу Инфостарт

См. также

Тестирование QA DevOps и автоматизация разработки Программист Пользователь 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.178.26.

4800 руб.

20.01.2022    10097    36    1    

19

Тестирование QA DevOps и автоматизация разработки Программист 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.17.168.

2400 руб.

04.07.2022    10413    43    1    

34

DevOps и автоматизация разработки Тестирование QA Программист Пользователь 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.30.230.

3360 руб.

05.08.2024    3324    19    1    

13

DevOps и автоматизация разработки Программист Бесплатно (free)

Облачные технологии и DevOps кардинально меняют подход к разработке на платформе 1С:Предприятие. Делимся реальным опытом построения CI/CD-конвейера в GitLab: от сборки и тестирования с YAxUnit и Vanessa Automation до интеграции с SonarQube и безопасного развертывания в продакшен. Вы узнаете, как с помощью Docker и автоматизации превратить рутину в предсказуемый и надежный процесс, сократив риски и освободив время для решений, которые действительно требуют вашего профессионализма.

18.08.2025    733    ComboBoy    0    

3

DevOps и автоматизация разработки Программист Бесплатно (free)

Задумывались ли вы, сколько времени разработчики тратят не на код, а на рутинные действия – от настройки окружения до поиска ответственных и документации? Эта статья о том, как найти и устранить «ерунду», которая тормозит процесс и раздражает на каждом этапе разработки. Разбираемся, как с помощью автоматизации, чек-листов и правильных процессов сделать разработку комфортной, эффективной и даже приятной.

18.08.2025    2764    mrXoxot    1    

17

DevOps и автоматизация разработки Программист Бесплатно (free)

Так сложилось, что чаще всего для целей CI/CD в проектах 1С применяется Jenkins и чуть реже GitLab CI. Но существует множество других решений для построения сборочных контуров. Ниже речь пойдет о применении решения Azure DevOps в проектах на 1С. В основе – реальный кейс, шаблоны, инструменты и собственные расширения.

15.08.2025    947    ktb    0    

10

DevOps и автоматизация разработки OneScript Программист Бесплатно (free)

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

12.08.2025    4703    untru    13    

22

EDT Групповая разработка (Git, хранилище) Программист 1С v8.3 Бесплатно (free)

Плагин, расширяющий функциональность EDT, предоставляя возможность работы с хранилищем конфигурации 1С без использования 1С:ГитКонвертер.

04.08.2025    2946    ZigRinat85    5    

33
Для отправки сообщения требуется регистрация/авторизация