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

Непрерывная интеграция

Для начала давайте разберемся с тем, что из себя представляет непрерывная интеграция. Continuous Integration это процесс автоматической сборки и интеграции кода разработчиков в единую общую основную ветку разработки.

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

На платформе 1С:Предприятие имеется два основных инструмента разработки: конфигуратор и 1C:Enerprise Development Tools (1C:EDT).

При этом, оба решения поддерживают групповую разработку. Но в каждом из них она выглядит она по‑разному. Для того, чтобы понять, как можно организовать конвейер CI, рассмотрим оба инструмента в части возможности его построения.

Но здесь важно отметить, что независимо от выбранного инструмента разработки (конфигуратор/1С:EDT), масштаб группы разработчиков неограничен. Так каждый разработчик программирует в своей собственной информационной базе и не мешает другим.

Конфигуратор

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

Но в любом случае у такого подхода есть один существенный недостаток — минимальными единицами версионируемых объектов становятся целая конфигурация и/или расширение. И в целом, работа с конфигурацией в конфигураторе выполняется в рамках бизнес‑объектов.

Если у нас конфигурация построена на громоздких решениях, а в больших компаниях, как правило так и бывает, то такой подход к версионированию становится неприемлемым. Увеличиваются сроки проведения Code review, слияния разных версий и откат изменений.

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

Такой подход тоже применим, однако следует всегда помнить, что здесь будут отсутствовать инструменты контроля исходного кода (по крайней мере в автоматическом режиме).

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

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

Разработку в хранилище конфигураций можно представить в виде следующих основных шагов:

1. Изначально все работают в одном хранилище

2. Раз в несколько часов по расписанию происходит выгрузка конфигурации в файлы

3. Изменения в файлах сохраняются в репозиторий. При этом сложно отличить изменения одного разработчика от другого.

4. На отдельно выделенном ПК выполняется сборка готовой конфигурации с помощью пакетного режима конфигуратора.

5. Ответственный сотрудник вручную переносит все изменения между хранилищами.

6. Затем также вручную запускаются тесты.

7. Если все тесты были успешно выполнены, ответственный сотрудник готовит регламент обновления продуктивного контура (выполняет подготовительные процедуры).

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

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

1C:Enterprise Development Tools

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

Так, в 1C:EDT уже идет встроенная поддержка популярной системы контроля версий — Git. То есть, EDT интегрируется с хранилищем Git и разработчикам становится доступно создание различных веток, возможность выполнять слияние с другими ветками, доступ ко всем изменениям в кодовой базе моментально по запросу, без каких‑либо задержек.

Также 1С:EDT можно интегрировать с другими системами управления исходным кодом, таким как Gitlab, Gitea и другими. В результате можно выстроить полноценный DevOps процесс с возможностями автоматизации процессов сборки, тестирования и развертывания.

Для 1C:EDT как и для конфигуратора доступен интерфейс управления с помощью командной строки, который будет наиболее полезен при сборке конфигураций. Здесь проблема заключается в том, что 1C:EDT напрямую собирать конфигурацию не умеет.

Но с помощью интерфейса командной строки можно сконвертировать исходный код 1C:EDT в язык понятный для конфигуратора. Далее с помощью пакетного режима конфигуратора можно загрузить этот код и сохранить уже конфигурацию. Далее ее можно передавать как для автоматического, так и для ручного тестирования.

Здесь, для автоматизации процессов конфигуратор и 1C:EDT должны совместно работать по следующему алгоритму:

1. Разработка кода 1C:EDT с использованием Git, который поддерживается в EDT из коробки.

2. Сборка выполняется после слияния на отдельном узле с использованием командной строки 1C:EDT CLI и пакетного режима конфигуратора.

3. Одновременно запускается процесс статического анализа кода с генерацией отчета.

4. После сборки и анализа запускается процесс загрузки готовой конфигурации в базу с тестами с помощью пакетного режима конфигуратора.

5. После успешного завершения тестов запускается процесс подготовки к обновлению продуктивного контура.

6. Далее может выполняться автоматическая загрузка конфигурации и обновление информационной базы.

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

Статический анализ исходного кода

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

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

Проверять исходный код 1С можно с помощью двух инструментов: Автоматической проверки конфигурации (АПК), входящей в экосистему 1С и стороннего решения SonarQube.

АПК выполняет статический анализ технического качества конфигураций и расширений в автоматическом режиме, не требуя их запуска.

Ниже представлен отчет с ошибками, созданный после анализа конфигурации с помощью АПК.

Проверка выполняется автоматически, при слиянии с основной веткой разработки. Единственное, что потребуется сделать вручную, это распределить ответственных за исправление этих ошибок.

Сценарное тестирование

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

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

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

Для реализации тестов в экосистеме 1С можно использовать 1С:Сценарное тестирование и 1С:Тестировщик. 1С:Тестировщик это инструмент для проверки одного сценария. Его ключевое преимущество — простота использования: для запуска теста не требуется никаких специальных навыков или предварительных настроек. Этот инструмент идеален для быстрого тестирования небольших изменений или конкретных пользовательских действий.

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

Нагрузочное тестирование

Помимо сценарного тестирования большое значение имеет также проверка работы приложения под нагрузкой. Разработчикам важно понимать, как решение будет вести себя при большом количестве подключенных пользователей, выполняемых запросов и так далее В 1С одним из важных инструментов, который обеспечивает возможность проведения нагрузочного тестирования, является 1С:Тест‑центр. Это гибкое и удобное расширение, которое предлагает разработчикам и тестировщикам широкую функциональность для создания реалистичных сценариев использования системы, настройки параметров тестирования и проведения различных проверок.

1С:Тест‑центр имеет удобный пользовательский интерфейс, обеспечивающий простоту в создании и настройке тестовой среды и запуска сценариев. С его помощью разработчики могут определить различные сценарии использования системы, настроить параметры тестирования, включая количество виртуальных пользователей, и задать нагрузку на сервер.

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

Полученный в результате проведения нагрузочного тестирования отчет позволяет разработчикам понять насколько устойчиво их решение к высокой нагрузке и какие изменения необходимо внести для обеспечения его стабильной работы.

Мониторинг работы

После успешного завершения тестов, готовое решение может быть размещено в продуктивной среде, и на этом этапе важно вести мониторинг его работы.

1С:Центр управления производительностью (1С:ЦУП) предоставляет разработчикам и администраторам информационных систем функционал для обнаружения и анализа проблем, связанных с производительностью. Так, с помощью этого инструмента можно получить информацию о состоянии системы, нагрузке на процессор, память, дисковую подсистему, сеть и другие ресурсы.

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

Все выявленные с помощью 1С:ЦУП проблемы могут быть автоматически зарегистрированы как ошибки в Системе проектирования прикладных решений (СППР). Данная система предназначена для проектирования прикладных решений (конфигураций) на платформе 1С:Предприятие и ведения технической документации проекта. СППР может быть использована как в качестве инструмента для проектирования новых информационных систем, разрабатываемых в среде 1С:Предприятия, так и для описания и документирования существующих систем, разработанных ранее без использования СППР.

Заключение

В этой статье мы поговорили о том, как можно организовать процесс CI/CD на основе решений, входящих в экосистему 1С. Мы можем воспользоваться такими компонентами, как 1С:EDT, 1С:Сценарное тестирование и другими для того, чтобы реализовать различные этапы конвейера CI/CD. По сути, экосистема 1С ничем не уступает другим решениям для разработчиков и также позволяет эффективно выстраивать пайплайн.

Если вы работаете с платформой 1С и задумывались о том, как организовать CI/CD‑процессы, автоматизировать тестирование и упростить сопровождение проектов, вам будет полезен курс «Разработчик 1С. Professional».

На курсе вы познакомитесь с инструментами, которые позволяют выстраивать современный пайплайн разработки на 1С: от использования 1С:EDT и Git до сценарного и нагрузочного тестирования. Программа курса ориентирована на практическое применение, поэтому вы сможете отработать навыки работы с экосистемой 1С и понять, как встроить её инструменты в процессы командной разработки.

На странице курса можно записаться на бесплатные открытые уроки по 1С.