Когда речь заходит о DevOps, обычно представляют Git, Docker, автотесты и непрерывную доставку. Однако мир 1С живёт по своим законам. Здесь приходится иметь дело с огромными конфигурациями, специфическим софтом и процессами, которые устоялись ещё десятилетия назад.
В одном из проектов команда MiOps внедряла современные DevOps-практики в процесс разработки на платформе 1С. В этой статье мы расскажем, какие подходы существуют, какие инструменты мы использовали и с какими сложностями столкнулись.
Два подхода к разработке в 1С
Сегодня в экосистеме 1С есть два основных подхода к организации разработки.
Первый — классический. Он основан на использовании хранилища конфигурации 1С и применяется ещё со времён платформы 1С 8.0.
Тут разработчик работает непосредственно в конфигураторе, вносит изменения в базе разработки, а затем вручную накатывает их на рабочую систему. При командной разработке используют хранилище конфигурации, чтобы отслеживать код и не затирать чужие правки.
Второй подход — более современный. Он предполагает использование Git как единственного источника правды, работу через ветки, Merge Request и другие привычные для современного IT инструменты. Чаще всего для этого используется 1С EDT (Enterprise Development Tools).
Однако на практике большинство специалистов по 1С по-прежнему выбирают проверенный конфигуратор и хранилище. Переход на EDT происходит значительно медленнее, чем хотелось бы.
Поэтому наша реализация строилась именно вокруг классического хранилища 1С.
Архитектура решения
Схема работы выглядела следующим образом:
На первый взгляд схема выглядит привычно для любого DevOps-инженера. Но детали реализации в мире 1С оказываются гораздо интереснее.
GitSync и превращение конфигурации в исходный код
Главная проблема заключается в том, что конфигурация 1С обычно хранится в виде большого CF-файла. Его размер в крупных системах может раздуваться до десятков гигабайт, а адекватно пропихнуть такой объём в Git практически невозможно.
Для решения этой задачи использовался инструмент GitSync, написанный на языке OneScript. Он подключается к хранилищу конфигурации и раскладывает её содержимое на множество XML-файлов, где каждый объект получает собственное файловое представление. После этого структура проекта становится пригодной для хранения в GitLab и дальнейшей автоматизированной обработки.
Статический анализ кода
После попадания изменений в GitLab запускался SonarScanner, который формировал отчёт для последующей загрузки в SonarQube. Именно на этом этапе возникли основные сложности. Из-за большого объёма конфигурации 1С отчёт получался очень тяжёлым, и его обработка требовала значительных ресурсов.
Размер формируемых отчётов достигал нескольких гигабайт. Даже сервер с 60 ГБ оперативной памяти испытывал серьёзные трудности при их обработке и загрузке в SonarQube. Чтобы решить проблему, мы разделили конфигурацию на несколько логических частей и стали анализировать их отдельно. Только после этого процесс начал работать стабильно.
Автоматическая сборка конфигурации
После успешного анализа необходимо было собрать конфигурацию обратно в формат, понятный платформе 1С. Из XML-исходников формировался новый CF-файл, который затем автоматически загружался в тестовую базу. Именно на этой базе происходила дальнейшая проверка изменений.
Автоматическое тестирование
Для тестирования использовался подход BDD (Behavior Driven Development) и инструмент Vanessa Automation. Тестовые сценарии описывались на русском языке с использованием синтаксиса Gherkin.
Например, сценарий мог:
Тестировщик просто набрасывает бизнес-кейс обычным человеческим языком, а робот сам прокликивает его в интерфейсе 1С. Это позволяет гонять не отдельные функции, а проверять реальные сценарии из жизни пользователей.
Автоматизация тестового окружения
Для запуска тестов использовалось изолированное воспроизводимое окружение, позволяющее автоматически подготавливать необходимые компоненты и выполнять сценарии без ручной настройки серверов. Такой подход упростил сопровождение инфраструктуры и сделал процесс тестирования более предсказуемым. При внедрении решения также потребовалось учесть особенности лицензирования платформы 1С.
Отчёты и обратная связь
После завершения тестирования результаты публиковались в Allure Report. Разработчики автоматически получали информацию о результатах выполнения тестов и могли оперативно приступить к разбору выявленных ошибок.
Главная проблема — время выполнения тестов
Самым сложным этапом оказался именно запуск тестов. Полный набор сценариев занимал около трёх часов. И это далеко не предел.
На профильных конференциях коллеги по цеху, занимающиеся DevOps в 1С, делились историями о проектах, где полный прогон тестов занимает до четырнадцати часов.
Для подобных проектов единственным разумным решением становится параллельный запуск тестов и разделение сценариев между несколькими исполнителями.
По мере роста проекта необходимость в подобных механизмах становится неизбежной.
Что можно автоматизировать в 1С
Интересно, что разные заказчики видят ценность в разных частях пайплайна.
Кому-то критически важны только автотесты, а кому-то хочется на автомате собирать релизы и раскатывать их сразу по десяткам рабочих баз.
К примеру, если одна и та же конфигурация используется в двадцати филиалах компании, ручное обновление каждой базы превращается в многочасовую рутинную работу.
Автоматизация позволяет выполнять такие операции централизованно и значительно снижает вероятность ошибок.
Зачем всё это нужно
Несмотря на всю свою специфику, мир 1С на данный момент вполне совместим с современными DevOps-практиками. Да, здесь используются свои инструменты, объёмы данных зачастую исчисляются гигабайтами, а многие процессы исторически развивались по собственным правилам. Однако это не мешает применять в экосистеме 1С те же подходы, которые давно стали стандартом в других направлениях разработки: автоматический анализ кода, Git, CI/CD-пайплайны, автоматизированное тестирование и контейнеризацию.
В этом кейсе мы построили полноценный процесс: от фиксации изменений в хранилище конфигурации до автоматического тестирования и публикации отчётов. Следующим логичным шагом могла бы стать полностью автоматическая доставка изменений в продуктивную среду. Однако уже реализованная архитектура показала, что DevOps для 1С — это не экзотика, а вполне рабочий инструмент, который способен существенно упростить жизнь разработчикам и администраторам.
В одном из проектов команда MiOps внедряла современные DevOps-практики в процесс разработки на платформе 1С. В этой статье мы расскажем, какие подходы существуют, какие инструменты мы использовали и с какими сложностями столкнулись.
Два подхода к разработке в 1С
Сегодня в экосистеме 1С есть два основных подхода к организации разработки.
Первый — классический. Он основан на использовании хранилища конфигурации 1С и применяется ещё со времён платформы 1С 8.0.
Тут разработчик работает непосредственно в конфигураторе, вносит изменения в базе разработки, а затем вручную накатывает их на рабочую систему. При командной разработке используют хранилище конфигурации, чтобы отслеживать код и не затирать чужие правки.
Второй подход — более современный. Он предполагает использование Git как единственного источника правды, работу через ветки, Merge Request и другие привычные для современного IT инструменты. Чаще всего для этого используется 1С EDT (Enterprise Development Tools).
Однако на практике большинство специалистов по 1С по-прежнему выбирают проверенный конфигуратор и хранилище. Переход на EDT происходит значительно медленнее, чем хотелось бы.
Поэтому наша реализация строилась именно вокруг классического хранилища 1С.
Архитектура решения
Схема работы выглядела следующим образом:
- Разработчик сохраняет изменения в хранилище конфигурации 1С.
- Специальный процесс автоматически отслеживает появление новых изменений.
- Конфигурация выгружается из хранилища в набор XML-файлов.
- Исходный код публикуется в GitLab.
- Запускается статический анализ кода.
- Собирается новая версия конфигурации.
- Конфигурация загружается в тестовую базу.
- Выполняется автоматическое тестирование.
- Формируются отчёты и уведомления для разработчиков.
На первый взгляд схема выглядит привычно для любого DevOps-инженера. Но детали реализации в мире 1С оказываются гораздо интереснее.
GitSync и превращение конфигурации в исходный код
Главная проблема заключается в том, что конфигурация 1С обычно хранится в виде большого CF-файла. Его размер в крупных системах может раздуваться до десятков гигабайт, а адекватно пропихнуть такой объём в Git практически невозможно.
Для решения этой задачи использовался инструмент GitSync, написанный на языке OneScript. Он подключается к хранилищу конфигурации и раскладывает её содержимое на множество XML-файлов, где каждый объект получает собственное файловое представление. После этого структура проекта становится пригодной для хранения в GitLab и дальнейшей автоматизированной обработки.
Статический анализ кода
После попадания изменений в GitLab запускался SonarScanner, который формировал отчёт для последующей загрузки в SonarQube. Именно на этом этапе возникли основные сложности. Из-за большого объёма конфигурации 1С отчёт получался очень тяжёлым, и его обработка требовала значительных ресурсов.
Размер формируемых отчётов достигал нескольких гигабайт. Даже сервер с 60 ГБ оперативной памяти испытывал серьёзные трудности при их обработке и загрузке в SonarQube. Чтобы решить проблему, мы разделили конфигурацию на несколько логических частей и стали анализировать их отдельно. Только после этого процесс начал работать стабильно.
Автоматическая сборка конфигурации
После успешного анализа необходимо было собрать конфигурацию обратно в формат, понятный платформе 1С. Из XML-исходников формировался новый CF-файл, который затем автоматически загружался в тестовую базу. Именно на этой базе происходила дальнейшая проверка изменений.
Автоматическое тестирование
Для тестирования использовался подход BDD (Behavior Driven Development) и инструмент Vanessa Automation. Тестовые сценарии описывались на русском языке с использованием синтаксиса Gherkin.
Например, сценарий мог:
- открыть клиент 1С;
- создать документ;
- заполнить реквизиты;
- провести документ;
- проверить ожидаемый результат.
Тестировщик просто набрасывает бизнес-кейс обычным человеческим языком, а робот сам прокликивает его в интерфейсе 1С. Это позволяет гонять не отдельные функции, а проверять реальные сценарии из жизни пользователей.
Автоматизация тестового окружения
Для запуска тестов использовалось изолированное воспроизводимое окружение, позволяющее автоматически подготавливать необходимые компоненты и выполнять сценарии без ручной настройки серверов. Такой подход упростил сопровождение инфраструктуры и сделал процесс тестирования более предсказуемым. При внедрении решения также потребовалось учесть особенности лицензирования платформы 1С.
Отчёты и обратная связь
После завершения тестирования результаты публиковались в Allure Report. Разработчики автоматически получали информацию о результатах выполнения тестов и могли оперативно приступить к разбору выявленных ошибок.
Главная проблема — время выполнения тестов
Самым сложным этапом оказался именно запуск тестов. Полный набор сценариев занимал около трёх часов. И это далеко не предел.
На профильных конференциях коллеги по цеху, занимающиеся DevOps в 1С, делились историями о проектах, где полный прогон тестов занимает до четырнадцати часов.
Для подобных проектов единственным разумным решением становится параллельный запуск тестов и разделение сценариев между несколькими исполнителями.
По мере роста проекта необходимость в подобных механизмах становится неизбежной.
Что можно автоматизировать в 1С
Интересно, что разные заказчики видят ценность в разных частях пайплайна.
Кому-то критически важны только автотесты, а кому-то хочется на автомате собирать релизы и раскатывать их сразу по десяткам рабочих баз.
К примеру, если одна и та же конфигурация используется в двадцати филиалах компании, ручное обновление каждой базы превращается в многочасовую рутинную работу.
Автоматизация позволяет выполнять такие операции централизованно и значительно снижает вероятность ошибок.
Зачем всё это нужно
Несмотря на всю свою специфику, мир 1С на данный момент вполне совместим с современными DevOps-практиками. Да, здесь используются свои инструменты, объёмы данных зачастую исчисляются гигабайтами, а многие процессы исторически развивались по собственным правилам. Однако это не мешает применять в экосистеме 1С те же подходы, которые давно стали стандартом в других направлениях разработки: автоматический анализ кода, Git, CI/CD-пайплайны, автоматизированное тестирование и контейнеризацию.
В этом кейсе мы построили полноценный процесс: от фиксации изменений в хранилище конфигурации до автоматического тестирования и публикации отчётов. Следующим логичным шагом могла бы стать полностью автоматическая доставка изменений в продуктивную среду. Однако уже реализованная архитектура показала, что DevOps для 1С — это не экзотика, а вполне рабочий инструмент, который способен существенно упростить жизнь разработчикам и администраторам.
