Хабрахабр

Интегрированный стенд разработки КРОК для 1С и не только

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

Итак знакомьтесь, интегрированный стенд разработки!

Общие принципы архитектуры

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

Процесс

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

Вот так выглядит наш стек, реализующий процесс:

Практически все сервисы с открытым исходным кодом и работают на ОС Linux. Мы постарались свести к минимуму использование платных сервисов с закрытым исходным кодом, что положительно отразилось на стоимости владения.

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

Проектирование (Сервис Проектирования Прикладных Решений)

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

Еще автоматизировали процессы генерации документации через интеграцию с функционалом «1С: ДО» и микросервисами по генерации документов формата docx. Мы внедрили конфигурацию «1С: СППР» в качестве единого интерфейса для проектирования прикладных решений, значительно переработали концепцию описания бизнес-процессов и функций, а также проектирования ТП (ФДР).

Редактирование информации о проекте:
«1С: СППР».

Отчёт по процессам:
«1С: СППР».

Редактирование метаданных объектов:
«1С: СППР».

Редактирование схемы бизнес-процесса:
«1С: СППР».

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

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

Разработка (Сервисы непрерывной интеграции, инспекции и тестирования)

Причем, даже если привлекаем сторонние команды разработчиков, методики, инструменты и стандарты разработки которых могут существенно отличаться от принятых у нас. Мы постарались сфокусироваться на возможности всестороннего, непрерывного, автоматизированного контроля качества разрабатываемого кода, чтобы гарантировать соответствие установленному в КРОК стандарту.

Полученные изменения индексируются и помещаются в репозиторий Git. На стенде каждый коммит разработчика автоматически запускает процедуру разбора конфигурации в структуру каталогов и файлов через сервис Gitsync. Сообщение коммита автоматически формируется из текста комментария, введенного при помещении изменений в хранилище конфигурации, а автор коммита в системе контроля версий сопоставляется с пользователем хранилища конфигурации. В нашем случае это сервис Gitlab. Это дает исчерпывающую картину истории разработки. Во время разбора из текста комментария мы можем получить информацию о задаче разработки и трудозатратах, передать ее системе отслеживания задач, например, Jira. Например, мы можем найти автора по строке кода, а smart-комментарии к коммитам позволяют управлять автоматически статусами задач и оценивать код в привязке к задачам непосредственно в самих задачах.

Теперь возможно прокомментировать любую строку помещаемого коммитом кода:
Gitlab.

Провести «Code Review» c подсветкой синтаксиса:
Gitlab.

Получить наглядную картину изменений кода в новом коммите:
Gitlab.

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

SonarQube:

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

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

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

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

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

А разработчик имеет дело с привычным для него интерфейсом конфигуратора, а также может развивать свои навыки, используя более продвинутые инструменты. Несмотря на относительную сложность описанного процесса, все механизмы конвейера, которые выполняют рутину, скрыты в облачном сервисе. Например, git, репозиторий для внешних механизмов в связке со сторонними редакторами кода и SonarLint, SourceTree, и т.п.

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

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

Схематически она выглядит так:
Модульная организация архитектуры стенда позволяет встраивать в процесс новые модули, тиражировать решение для необходимого количества проектов.

Тестирование (сервис непрерывного тестирования)

На данный момент на стенде реализован прогон дымовых тестов и unit-тестов. Выше я уже говорил про сервис непрерывного тестирования, который интегрирован в конвейер процесса разработки. Функционал автотестов реализуется с использованием фреймворка xUnitFor1C.

Для unit-тестов подразумевается разработка теста параллельно с разработкой функционала. Запуск процессов тестирования, так же как инспекция кода, привязан к событию коммита в репозиторий проекта. Затем запускается клиент, который выполняет сценарии тестирования для уже реализованного функционала. Непосредственно перед их выполнением производится автоматизированное развертывание последней версии конфигурации в подготовленную тестовую информационную базу. Результат прогона тестов — отчет, который загружается в систему анализа и визуализации результатов тестирования ReportPortal. Тесная интеграция сервисов автоматизированного тестирования с BSL плагином SonarQube позволяет вычислить такой параметр как покрытие кода тестами. Все параметры прогонов тестов доступны в удобном веб-интерфейсе с различными досками для графиков, диаграмм (виджетов). Этот сервис представляет собой портал отчетов, в котором агрегируются данные о прогонах тестов (статистика и результаты), производится базовое обучение системы по категоризации падений и дальнейшее автоматическое определение причин. Для расширения функций портала возможно использовать собственные расширения.

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

Дашборд:
ReportPortal.

Неудачные запуски тестов:
ReportPortal.

Типы дефектов:
ReportPortal.

Редактирование типов дефектов:
ReportPortal.

Развитие

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть