Форма обратной связи
Свяжитесь с нами
Предпосылки создания системы управления качеством
При реализации проектов 1С немаловажная задача – управление качеством разработки. Для повышения качества разработки на рынке существует ряд технологий, которые в настоящее время активно используются: автоматизированная проверка качества кода, дымовые, сценарные тесты и прочее.
Чтобы развернуть и настроить такие системы, нужен определенный опыт, накопленный в том числе за счет изрядного количества случаев, которые можно охарактеризовать выражением «наступить на грабли»». Во избежание этого, как правило, привлекаются опытные специалисты – DevOps-инженеры, которые отвечают за развертывание и поддержку работы таких систем.
Как было бы здорово, если бы была возможность быстро развернуть и использовать такие инструменты, включающие в себя весь необходимый набор современных модулей тестирования, и при этом не тратить много времени.
Такого инструмента, к сожалению, на рынке нет, – а если чего-то нет, то ничего не остается, кроме как сделать это самому.
Чтобы развернуть и настроить такие системы, нужен определенный опыт, накопленный в том числе за счет изрядного количества случаев, которые можно охарактеризовать выражением «наступить на грабли»». Во избежание этого, как правило, привлекаются опытные специалисты – DevOps-инженеры, которые отвечают за развертывание и поддержку работы таких систем.
Как было бы здорово, если бы была возможность быстро развернуть и использовать такие инструменты, включающие в себя весь необходимый набор современных модулей тестирования, и при этом не тратить много времени.
Такого инструмента, к сожалению, на рынке нет, – а если чего-то нет, то ничего не остается, кроме как сделать это самому.
В нашей компании «Технологии Доверия» задумались о создании системы инсталляции и использования инструментов контроля качества разработки на основе зарекомендовавших себя программных продуктов DevOps на наших проектах.
Основная цель - контроль качества разработки при реализации проектов 1С, при этом система должна:
- Быстро разворачиваться без привлечения DevOps-специалиста.
- Быть удобной, информативной, доступной для конечного пользователя (программиста 1С на проекте).
Как мы используем систему в проектах:
Клиенту перед началом проекта предоставляются требования для организации серверов разработки и серверов инфраструктуры DevOps (если разработка ведется на серверах заказчика).
Предварительно необходимо установить сервер 1С:Предприятие и развернуть хранилище 1С.
Специалист 1С подготавливает конфигурационный файл и на сервере инфраструктуры DevOps с минимальными трудозатратами разворачивает необходимые программные модули с применением технологии контейнеризации Docker.
В ходе реализации проекта производятся автоматизированные проверки качества разработки и поиск ошибок. Разработчики получают информацию об этом в web-браузере (мы старались минимизировать использование дополнительных программных модулей).
Команда разработки получает инструкции для использования модулей в своей повседневной работе (методологическая часть).
Какие инструменты нужны архитектору 1С для повышения качества разработки?
Здесь мы придерживались принципа эффективности: трудозатраты на развертывание, поддержку и анализ ошибок должны быть значительно ниже, чем ущерб от возможных ошибок. В самом деле, можно потратить много времени на поддержание работы DevOps, ежедневный анализ ошибок (ведь он тоже требует от программистов дополнительных временных затрат) и выявить пару несущественных багов.
Поэтому мы стремились включить только самое необходимое:
- Анализ коммитов разработчиков в среде git-репозитория кода. Конфигуратор 1С не позволяет увидеть, кто внес изменение в конкретную строчку кода, а иногда это информация очень важна.
- Анализ качества кода инструментом SonarQube. Такой анализ и те ошибки, которые находит Sonar, дисциплинирует программиста, способствует повышению качества разработки, помогает писать программистам «хороший» код.
- Типовой анализ конфигурации 1С. Такой анализ можно выполнить, если в конфигураторе вызвать команду «Конфигурация – Проверка конфигурации», но не все это делают регулярно. Система в автоматическом режиме запускает проверку, анализирует полученный файл с замечаниями и сопоставляет ошибки и коммиты в git-репозитории. Это необходимо, чтобы получить персонифицированные ошибки.
- Дымовые тесты Vanessa-ADD. Дымовые тесты нужны для поиска «явных» ошибок, которые возникают при открытии форм, записи справочников, проведении документов. Мы добавили анализ файла ошибок, чтобы через git получить персонифицированные ошибки.
Как видно, все инструменты направлены на повышение качества разработки.
Основная цель – быстрая инсталляция и удобное использование автоматизированных инструментов контроля качества разработки специалистом, не имеющим профильной подготовки.
Основная цель – быстрая инсталляция и удобное использование автоматизированных инструментов контроля качества разработки специалистом, не имеющим профильной подготовки.
Настройка инструментов DevOps для неподготовленного пользователя – нетривиальная задача. Необходимо учитывать множество нюансов, во многом определяемых средой, в которой запускаются программные продукты, поэтому было принято решение все размещать в Docker.
Что такое Docker? Это система контейнеризации для программных модулей. Контейнер может содержать настройки программного продукта и максимально не зависеть от среды, в которой он запущен.
На момент написания статьи мы запускали и тестировали модули, запущенные в среде Linux. Как правило, собрать отдельный сервер Ubuntu сейчас не составляет труда.
Что такое Docker? Это система контейнеризации для программных модулей. Контейнер может содержать настройки программного продукта и максимально не зависеть от среды, в которой он запущен.
На момент написания статьи мы запускали и тестировали модули, запущенные в среде Linux. Как правило, собрать отдельный сервер Ubuntu сейчас не составляет труда.
Рекомендуемые характеристики сервера DevOps:
ОЗУ
24 Гб
HDD
500 Гб
Требуемые характеристики во многом зависят от анализируемой конфигурации. Сервер инфраструктуры DevOps должен иметь сетевой доступ к серверу 1С:Предприятие и к серверу хранилища 1С, также необходим доступ в интернет для загрузки образов контейнеров.
Программный модуль, запускаемый в контейнере Docker, может использовать файлы, которые хранятся вне контейнера. Например, базу данных рекомендуется размещать не в контейнере, а в примонтированном каталоге. Большое количество настроечных файлов мы храним во внешних каталогах.
Таким образом, в предлагаемом модуле поставляемые файлы состоят из подготовленных файлов настроек и программных модулей, размещенных в контейнере.
Общая архитектура представлена на схеме ниже и включает в себя:
Компоненты вне Docker:
- Сервер 1С:Предприятие с сетевыми и клиентскими лицензиями;
- Сетевое хранилище 1С:Предприятие;
- База данных 1С, в которой будет производится разбор конфигурации на текстовые файлы и запуск дымовых тестов;
- База данных 1С для дымовых тестов.
Компоненты, расположенные в контейнерах Docker:
- Клиент 1С:Предприятие интегрированный с git-репозиторием с применением среды исполнения oscript с установленными библиотеками: GitSync и Vanessa-ADD (Vanessa Automation Driven Development) ;
- Jenkins. Система для автоматического запуска и логирования выполнения заданий;
- SonarQube включает в себя сервер, PostgreSQL и сканер для автоматизированной проверки кода в конфигурации;
- Модуль для визуального доступа к репозиторию (один из двух):
- Gitweb – модуль для визуального, через браузер, доступа к git-репозиторию. Работает не очень хорошо, но потребляет мало оперативной памяти;
- GitLab – работает очень хорошо, очень удобен, но потребляет очень много оперативной памяти. Нам очень понравился модуль GitLab, удобный и красивый, и мы использовали его на одном из проектов для визуального доступа к git.
Контейнер 1С_Git содержит: клиент 1С:Предприятие, непосредственно git, oscript с установленными библиотеками GitSync , Vanessa-ADD.
Модуль собран на основе проекта: https://github.com/firstBitMarksistskaya/onec-docker.
Мы собираем необходимый Docker-образ под конкретный релиз 1С:Предприятие. Это не очень удобно, так как если, например, необходимо обновить версию 1С:Предприятие на сервере, то необходимо пересобирать Docker-образ.
Модуль собран на основе проекта: https://github.com/firstBitMarksistskaya/onec-docker.
Мы собираем необходимый Docker-образ под конкретный релиз 1С:Предприятие. Это не очень удобно, так как если, например, необходимо обновить версию 1С:Предприятие на сервере, то необходимо пересобирать Docker-образ.
Контейнер Jenkins
Jenkins расположен в отдельном контейнере.
Доступ в Jenkins осуществляется через браузер.
Настроены следующие задания:
- Выгрузка конфигурации в текстовые файлы;
- Запуск sonar scanner;
- Запуск дымовых тестов;
- Push git в GitLab (если используется GitLab).
Контейнеры SonarQube
Модуль SonarQube предназначен для анализа кода.
SonnarQube состоит из контейнеров:
- Сервер SonarQube;
- База данных PostgreSQL;
- Компонент sonarscanner.
Доступ в SonarQube осуществляется через web-браузер.
Более подробная информация о работе в SonarQube доступна в интернете.
Более подробная информация о работе в SonarQube доступна в интернете.
Дымовые тесты выполняются с использованием Vanessa ADD.
Включают в себя следующие тесты:
- Открытие форм;
- Запись справочников;
- Проведение документов;
- Проверка общих модулей;
- Проверка СКД.
Проверка конфигурации включает в себя тестирование конфигурации, как если бы в конфигураторе 1С:Предприятие нажать «Конфигурация – Проверка конфигурации», и выполняет:
- Синтаксическую проверку модулей
- Логическую проверку модулей
Для настройки дымовых тестов разработана обработка, которая позволяет создать настройки проверяемых объектов.
При запуске дымовых тестов выполняются следующие операции:
- Обновление конфигурации базы из хранилища.
- Обновление базы данных.
- Запуск дымовых тестов.
- Анализ результата дымовых тестов. На onescript написан скрипт, который разбирает файл результата дымовых тестов и формирует новый файл только с ошибками (типовой файл содержит информацию по всем исходам). По метаданным, в которых были обнаружены ошибки, система в git определяет последнего ответственного. В действительности результат дымовых тестов не содержит ответственных, и необходимо время, чтобы разобрать файл и разослать информацию ответственным. В данном случае система находит «последнюю руку».
- Запуск тестирования конфигурации.
- Анализ результата тестирования конфигурации. Выполняется разбор oscript для персонифицирования ошибок по аналогии с разбором результата дымовых тестов.
Результаты тестов доступны в файлах xml или рассылаются по электронной почте.
Конфигуратор 1С:Предприятие не позволяет получить информацию о том, кто вносил исправление в конкретную строчку файла. Иногда эта информация важна для анализа.
В используемой системе git выгруженной конфигурации доступен в каталоге, и в общем его можно анализировать любыми методами (через команды или плагины к среде разработки). Однако, на наш взгляд, удобно получать информацию через браузер.
Для этого предусмотрена возможность использовать на выбор один из модулей: Gitweb или GitLab. GitLab не предназначен для этих целей, но очень удобен в использовании. GitWeb нестабильно работает, есть проблемы с кириллицей.
В используемой системе git выгруженной конфигурации доступен в каталоге, и в общем его можно анализировать любыми методами (через команды или плагины к среде разработки). Однако, на наш взгляд, удобно получать информацию через браузер.
Для этого предусмотрена возможность использовать на выбор один из модулей: Gitweb или GitLab. GitLab не предназначен для этих целей, но очень удобен в использовании. GitWeb нестабильно работает, есть проблемы с кириллицей.
Для создания контейнеров необходимо выполнить настойки: указать имена баз, путь хранилища, пользователей хранилища и базы данных и прочую информацию.
Для настройки разработан модуль, который состоит из:
Для настройки разработан модуль, который состоит из:
- Конфигурационного файла;
- Скрипта, который на основе конфигурационного файла корректирует файлы настроек скриптов для создания контейнеров.
Таким образом, вот что должен выполнить специалист для настройки и установки контейнеров Docker:
- Запустить обработку 1С, ознакомиться с инструкцией, указать настойки, получить конфигурационные файлы
- Создать рабочий каталог на сервере DevOps и перенести в него файлы настроек (в процессе реализации выполняется доработка, чтобы файлы скачивались с ftp-сервера автоматически)
- Перенести конфигурационные файлы на сервер DevOps
- Запустить файл для корректировки файлов настройки
- Запускать последовательно файлы скрипты установки контейнеров Docker (bash скрипты)
Пока это, конечно, выполняется не одной кнопкой, но это проще, чем устанавливать и настраивать все компоненты.
Для работы с системой разработаны инструкции:
- ИнсталляцияИнструкция администратора содержит подробную информацию, которую необходимо выполнить для быстрой инсталляции модулей.
- ПоддержкаИнструкция администратора содержит информацию по часто возникающим вопросам в ходе работы системы (основные команды Docker, правка файла AUTHORS).
- Git-инструкция пользователяСодержит информацию по работе в gitlab и gitweb и предназначена для программистов, принимающих участие в проекте.
- Sonar-инструкция пользователяСодержит информацию по работе в SonarQube и предназначена для программистов, принимающих участие в проекте.
- Vanessa-инструкция пользователяСодержит информацию по работе с ошибками, выявленными в результате дымовых тестов, и предназначена для программистов, принимающих участие в проекте.
Это внутренний проект «Технологий Доверия», и он находится в постоянном развитии. Мы применяем его на своих проектах, но готовы поделиться технологией с заинтересованными лицами.
Будем благодарны за любую обратную связь.
Будем благодарны за любую обратную связь.
Контакты