Опыт разработки, накапливаемый на крупных и сложных проектах, воплощается в полезные инструменты и инженерные практики, которыми необходимо обогащать процессы разработки, переосмысливая его целиком раз за разом. Именно осознание ценности приобретенного опыта как артефакта, желание развиваться, привело нас к пониманию необходимости внедрения инструментов и практик в текущие процессы. И мы запустили кардинальный пересмотр подходов к проектированию решений и к процессу разработки в целом. Нет смысла описывать типичные ограничения и недостатки «классического» подхода к командной разработке в мире 1С. На эту тему уже много сказано. Опишу лишь паттерны, которые позволили нам сделать эти недостатки маленькими и почти не страшными.
Итак знакомьтесь, интегрированный стенд разработки!
Проектируя архитектуру стенда, мы стремились охватить весь жизненный цикл внедряемых на проектах решений, имплементировать приобретенный опыт, стандартизировать процессы, автоматизировать рутину. При этом, нужно было заложить потенциал развития, сохранить способность к масштабированию и максимальную простоту, с точки зрения обслуживания, развития и работы пользователей. Инструменты и методики, которые доказали свою эффективность на практике, должны добавляться в процесс. А все бесполезное, мешающее в работе, должно быть удалено.
Жизненный цикл любого решения практически не меняется в зависимости от масштаба и сложности проекта. Он включает в себя: анализ, проектирование, разработку, тестирование, внедрение, сопровождение, вывод из эксплуатации. Чтобы получить максимальную эффективность, каждый из этих процессов должен быть выверен и согласован с предшествующими и последующими процессами, объединен в подобие автоматизированного конвейера, который может тиражироваться под неограниченное количество проектов. Решить поставленную задачу, позволила реализация системы в виде связанных через экспортируемые API микросервисов в изолированных контейнерах, которую возможно развернуть как в облачном сервисе, так и в локальной сети предприятия.
Вот так выглядит наш стек, реализующий процесс:
Мы постарались свести к минимуму использование платных сервисов с закрытым исходным кодом, что положительно отразилось на стоимости владения. Практически все сервисы с открытым исходным кодом и работают на ОС Linux.
Процесс построен так, что мы получаем максимальную отдачу от каждого члена команды разработки, а стандартизация и автоматизация избавляют от чрезмерной сложности и рутины.
Один из наиболее значимых этапов при старте проекта — проектирование будущего решения на основе анализа требований. Основная задача — максимально понятно, однозначно и быстро описать архитектуру будущего решения, в терминах понятных как разработчику/инженеру, так и консультанту. Описать метаданные, алгоритмы реализуемых бизнес-процессов. При этом, хотелось максимально задействовать готовые, быстро настраиваемые под конкретные условия шаблоны, которые можно адаптировать к данным на входе и получить проектную документацию на выходе.
Мы внедрили конфигурацию «1С: СППР» в качестве единого интерфейса для проектирования прикладных решений, значительно переработали концепцию описания бизнес-процессов и функций, а также проектирования ТП (ФДР). Еще автоматизировали процессы генерации документации через интеграцию с функционалом «1С: ДО» и микросервисами по генерации документов формата docx.
«1С: СППР». Редактирование информации о проекте:
«1С: СППР». Отчёт по процессам:
«1С: СППР». Редактирование метаданных объектов:
«1С: СППР». Редактирование схемы бизнес-процесса:
Кстати, мы можем визуализировать взаимосвязь между бизнес-процессами и объектами в системе, сформировать список доработок на основе зарегистрированных требований и получить проектную документацию автоматически, что упрощает процесс управления изменениями. А значит, детально спланировать процесс разработки, видеть сложность, связанность задач, точнее определять сроки и порядок их реализации.
Конечно, нельзя сказать, что процесс проектирования изменился кардинально, однако унификация организационных подходов и автоматизация многих функций уже вносит вклад в качество проектов.
Мы постарались сфокусироваться на возможности всестороннего, непрерывного, автоматизированного контроля качества разрабатываемого кода, чтобы гарантировать соответствие установленному в КРОК стандарту. Причем, даже если привлекаем сторонние команды разработчиков, методики, инструменты и стандарты разработки которых могут существенно отличаться от принятых у нас.
На стенде каждый коммит разработчика автоматически запускает процедуру разбора конфигурации в структуру каталогов и файлов через сервис Gitsync. Полученные изменения индексируются и помещаются в репозиторий Git. В нашем случае это сервис Gitlab. Сообщение коммита автоматически формируется из текста комментария, введенного при помещении изменений в хранилище конфигурации, а автор коммита в системе контроля версий сопоставляется с пользователем хранилища конфигурации. Во время разбора из текста комментария мы можем получить информацию о задаче разработки и трудозатратах, передать ее системе отслеживания задач, например, Jira. Это дает исчерпывающую картину истории разработки. Например, мы можем найти автора по строке кода, а smart-комментарии к коммитам позволяют управлять автоматически статусами задач и оценивать код в привязке к задачам непосредственно в самих задачах.
Gitlab. Теперь возможно прокомментировать любую строку помещаемого коммитом кода:
Gitlab. Провести «Code Review» c подсветкой синтаксиса:
Gitlab. Получить наглядную картину изменений кода в новом коммите:
После каждого коммита в репозитории автоматически запускается процедура статической инспекции кода сервисом SonarQube. BSL код коммита проверяется на соответствие набору правил (профиль качества), описывающих стандарт разработки кода. Процедура выполняется как для кода разрабатываемой конфигурации, так и для внешних механизмов: расширений, внешних отчетов и обработок и, в принципе, любого другого кода проекта, даже на других языках.
SonarQube:
Каждая проверка обновляет информацию отслеживаемых метрик качества кодовой базы, таких как:
Собранные в результате проверки метрики дают наглядное представление о текущем состоянии кодовой базы проекта, позволяют оценить качество, выявить риски, оперативно исправить ошибки.
Профиль качества может расширяться собственными наборами правил через XPath, а также за счет выпуска новых правил в составе собственной реализации плагина для языка 1С. Это позволяет гибко управлять требованиями качества, исходя из реалий конкретного решения.
Автоматизированный запуск процессов разбора конфигурации, инспекции кода, автоматизированного тестирования и т.д. запускает сервис непрерывной интеграции (сервис Jenkins). Количество и характер таких сборочных линий может быть изменено в соответствии со спецификой того или иного проекта.
Несмотря на относительную сложность описанного процесса, все механизмы конвейера, которые выполняют рутину, скрыты в облачном сервисе. А разработчик имеет дело с привычным для него интерфейсом конфигуратора, а также может развивать свои навыки, используя более продвинутые инструменты. Например, git, репозиторий для внешних механизмов в связке со сторонними редакторами кода и SonarLint, SourceTree, и т.п.
В общем случае разработчик подключает информационную базу к сервису хранилища конфигурации 1С, пишет код и помещает его в этот сервис, тем самым запуская скрытый от него процесс на стенде. Если в результате проверки коммита в коде выявлены недостатки, разработчик получает почтовое уведомление (или сообщение чат-бота) со ссылкой на описание ошибки и с рекомендациями по исправлению и временной оценкой трудозатрат в интерфейсе сервиса SonarQube. После исправления ошибки, происходит новый коммит и процесс повторяется, отредактированные задачи автоматически закрываются… технический долг уменьшается. По той же логике построен процесс автоматизированного тестирования, где каждый коммит инициирует запуск развёртывания тестового окружения, подключает необходимые тесты из библиотеки тестов. А после прогона агрегируется информация об ошибках при тестировании, а также о покрытии кода тестами.
Трудно переоценить эффект от непрерывной, всесторонней проверки кода, за которой следует автоматизированное тестирование разрабатываемого функционала. Это позволяет избавиться от далеко идущих последствий, сделать этапы разработки прозрачными, а вкупе с правильно выстроенными процессами, объективно оценить квалификацию разработчиков, что исключает риски зависимости от подрядчиков. Оценивая параметры текущей кодовой базы, мы можем оперативно выявлять и нивелировать возникающие риски, исправлять недочеты проектирования, своевременно реагировать на меняющиеся требования.
Модульная организация архитектуры стенда позволяет встраивать в процесс новые модули, тиражировать решение для необходимого количества проектов. Схематически она выглядит так:
Выше я уже говорил про сервис непрерывного тестирования, который интегрирован в конвейер процесса разработки. На данный момент на стенде реализован прогон дымовых тестов и unit-тестов. Функционал автотестов реализуется с использованием фреймворка xUnitFor1C.
Запуск процессов тестирования, так же как инспекция кода, привязан к событию коммита в репозиторий проекта. Для unit-тестов подразумевается разработка теста параллельно с разработкой функционала. Непосредственно перед их выполнением производится автоматизированное развертывание последней версии конфигурации в подготовленную тестовую информационную базу. Затем запускается клиент, который выполняет сценарии тестирования для уже реализованного функционала. Тесная интеграция сервисов автоматизированного тестирования с BSL плагином SonarQube позволяет вычислить такой параметр как покрытие кода тестами. Результат прогона тестов — отчет, который загружается в систему анализа и визуализации результатов тестирования ReportPortal. Этот сервис представляет собой портал отчетов, в котором агрегируются данные о прогонах тестов (статистика и результаты), производится базовое обучение системы по категоризации падений и дальнейшее автоматическое определение причин. Все параметры прогонов тестов доступны в удобном веб-интерфейсе с различными досками для графиков, диаграмм (виджетов). Для расширения функций портала возможно использовать собственные расширения.
Сервис автоматизированного тестирования — это еще один этап, снижающий риски попадания в релиз кода, который ломает ранее реализованной функционал или работает с ошибками.
ReportPortal. Дашборд:
ReportPortal. Неудачные запуски тестов:
ReportPortal. Типы дефектов:
ReportPortal. Редактирование типов дефектов:
Оценивая результаты проделанной работы, мы видим, что из задуманного уже реализовано, какие идеи уже успешно работают, какие еще только предстоит реализовать.
Из планов на ближайшую перспективу развития стенда — создание портала управления сервисами стенда. Веб-интерфейс портала позволит работать с заявками на подключение проектов к стенду, с калькулятором стоимости сервисов, с их автоматизированным развертыванием по запросу под проект. В результате менеджер сразу же может получить калькуляцию стоимости выбранных услуг и оценить затраты, определить разработчиков на проект.
Мы планируем провести интеграцию портала с облачным решением эксплуатации систем 1С. Это поможет быстро разворачивать тиражируемые типовые решения в связке с сервисами разработки, реализованными на стенде для более эффективной миграции систем заказчика в облако КРОК.
Портал управления планируем также интегрировать с сервисом автоматизированного управления конфигурацией (развертывание, настройка, удаление). Это позволит сократить время развертывания, упростить настройку и обслуживание системы. А для повышения уровня безопасности внедрим сервис сквозной аутентификации по всем сервисам стенда, чтобы использовать одну и ту же учетную запись во всех из них.
Если рассматривать весь процесс с точки зрения истории полного цикла разработки решения, то созданный конвейер позволит собрать и агрегировать большое количество разнообразных метрик как по артефактам проекта, так и по специалистам, которые принимали в нем участие. Такая подробная ретроспектива будет способствовать накоплению и повторному использованию опыта в решении сложных задач, формировать команды из успешных разработчиков для более эффективной и слаженной работы.
UPD. По просьбам в комментариях добавляем список опенсурсных продуктов, которые используем, с ссылками.
Итак знакомьтесь, интегрированный стенд разработки!
Общие принципы архитектуры
Проектируя архитектуру стенда, мы стремились охватить весь жизненный цикл внедряемых на проектах решений, имплементировать приобретенный опыт, стандартизировать процессы, автоматизировать рутину. При этом, нужно было заложить потенциал развития, сохранить способность к масштабированию и максимальную простоту, с точки зрения обслуживания, развития и работы пользователей. Инструменты и методики, которые доказали свою эффективность на практике, должны добавляться в процесс. А все бесполезное, мешающее в работе, должно быть удалено.
Процесс
Жизненный цикл любого решения практически не меняется в зависимости от масштаба и сложности проекта. Он включает в себя: анализ, проектирование, разработку, тестирование, внедрение, сопровождение, вывод из эксплуатации. Чтобы получить максимальную эффективность, каждый из этих процессов должен быть выверен и согласован с предшествующими и последующими процессами, объединен в подобие автоматизированного конвейера, который может тиражироваться под неограниченное количество проектов. Решить поставленную задачу, позволила реализация системы в виде связанных через экспортируемые API микросервисов в изолированных контейнерах, которую возможно развернуть как в облачном сервисе, так и в локальной сети предприятия.
Вот так выглядит наш стек, реализующий процесс:
Мы постарались свести к минимуму использование платных сервисов с закрытым исходным кодом, что положительно отразилось на стоимости владения. Практически все сервисы с открытым исходным кодом и работают на ОС Linux.
Процесс построен так, что мы получаем максимальную отдачу от каждого члена команды разработки, а стандартизация и автоматизация избавляют от чрезмерной сложности и рутины.
Проектирование (Сервис Проектирования Прикладных Решений)
Один из наиболее значимых этапов при старте проекта — проектирование будущего решения на основе анализа требований. Основная задача — максимально понятно, однозначно и быстро описать архитектуру будущего решения, в терминах понятных как разработчику/инженеру, так и консультанту. Описать метаданные, алгоритмы реализуемых бизнес-процессов. При этом, хотелось максимально задействовать готовые, быстро настраиваемые под конкретные условия шаблоны, которые можно адаптировать к данным на входе и получить проектную документацию на выходе.
Мы внедрили конфигурацию «1С: СППР» в качестве единого интерфейса для проектирования прикладных решений, значительно переработали концепцию описания бизнес-процессов и функций, а также проектирования ТП (ФДР). Еще автоматизировали процессы генерации документации через интеграцию с функционалом «1С: ДО» и микросервисами по генерации документов формата docx.
«1С: СППР». Редактирование информации о проекте:
«1С: СППР». Отчёт по процессам:
«1С: СППР». Редактирование метаданных объектов:
«1С: СППР». Редактирование схемы бизнес-процесса:
Кстати, мы можем визуализировать взаимосвязь между бизнес-процессами и объектами в системе, сформировать список доработок на основе зарегистрированных требований и получить проектную документацию автоматически, что упрощает процесс управления изменениями. А значит, детально спланировать процесс разработки, видеть сложность, связанность задач, точнее определять сроки и порядок их реализации.
Конечно, нельзя сказать, что процесс проектирования изменился кардинально, однако унификация организационных подходов и автоматизация многих функций уже вносит вклад в качество проектов.
Разработка (Сервисы непрерывной интеграции, инспекции и тестирования)
Мы постарались сфокусироваться на возможности всестороннего, непрерывного, автоматизированного контроля качества разрабатываемого кода, чтобы гарантировать соответствие установленному в КРОК стандарту. Причем, даже если привлекаем сторонние команды разработчиков, методики, инструменты и стандарты разработки которых могут существенно отличаться от принятых у нас.
На стенде каждый коммит разработчика автоматически запускает процедуру разбора конфигурации в структуру каталогов и файлов через сервис Gitsync. Полученные изменения индексируются и помещаются в репозиторий Git. В нашем случае это сервис Gitlab. Сообщение коммита автоматически формируется из текста комментария, введенного при помещении изменений в хранилище конфигурации, а автор коммита в системе контроля версий сопоставляется с пользователем хранилища конфигурации. Во время разбора из текста комментария мы можем получить информацию о задаче разработки и трудозатратах, передать ее системе отслеживания задач, например, Jira. Это дает исчерпывающую картину истории разработки. Например, мы можем найти автора по строке кода, а smart-комментарии к коммитам позволяют управлять автоматически статусами задач и оценивать код в привязке к задачам непосредственно в самих задачах.
Gitlab. Теперь возможно прокомментировать любую строку помещаемого коммитом кода:
Gitlab. Провести «Code Review» c подсветкой синтаксиса:
Gitlab. Получить наглядную картину изменений кода в новом коммите:
После каждого коммита в репозитории автоматически запускается процедура статической инспекции кода сервисом SonarQube. BSL код коммита проверяется на соответствие набору правил (профиль качества), описывающих стандарт разработки кода. Процедура выполняется как для кода разрабатываемой конфигурации, так и для внешних механизмов: расширений, внешних отчетов и обработок и, в принципе, любого другого кода проекта, даже на других языках.
SonarQube:
Каждая проверка обновляет информацию отслеживаемых метрик качества кодовой базы, таких как:
- технический долг – суммарные трудозатраты необходимые для исправления выявленных ошибок;
- порог качества – предельно допустимые показатели ошибок, уязвимостей и других недостатков кода, при достижении которых, выпуск релиза считается не возможным;
- дублирование кода – количество строк кода, повторяющихся многократно в рамках разрабатываемой конфигурации;
- цикломатическая и когнитивная сложность – алгоритмы с большим количеством ветвлений, усложняющие поддержку и доработку кода.
Собранные в результате проверки метрики дают наглядное представление о текущем состоянии кодовой базы проекта, позволяют оценить качество, выявить риски, оперативно исправить ошибки.
Профиль качества может расширяться собственными наборами правил через XPath, а также за счет выпуска новых правил в составе собственной реализации плагина для языка 1С. Это позволяет гибко управлять требованиями качества, исходя из реалий конкретного решения.
Автоматизированный запуск процессов разбора конфигурации, инспекции кода, автоматизированного тестирования и т.д. запускает сервис непрерывной интеграции (сервис Jenkins). Количество и характер таких сборочных линий может быть изменено в соответствии со спецификой того или иного проекта.
Несмотря на относительную сложность описанного процесса, все механизмы конвейера, которые выполняют рутину, скрыты в облачном сервисе. А разработчик имеет дело с привычным для него интерфейсом конфигуратора, а также может развивать свои навыки, используя более продвинутые инструменты. Например, git, репозиторий для внешних механизмов в связке со сторонними редакторами кода и SonarLint, SourceTree, и т.п.
В общем случае разработчик подключает информационную базу к сервису хранилища конфигурации 1С, пишет код и помещает его в этот сервис, тем самым запуская скрытый от него процесс на стенде. Если в результате проверки коммита в коде выявлены недостатки, разработчик получает почтовое уведомление (или сообщение чат-бота) со ссылкой на описание ошибки и с рекомендациями по исправлению и временной оценкой трудозатрат в интерфейсе сервиса SonarQube. После исправления ошибки, происходит новый коммит и процесс повторяется, отредактированные задачи автоматически закрываются… технический долг уменьшается. По той же логике построен процесс автоматизированного тестирования, где каждый коммит инициирует запуск развёртывания тестового окружения, подключает необходимые тесты из библиотеки тестов. А после прогона агрегируется информация об ошибках при тестировании, а также о покрытии кода тестами.
Трудно переоценить эффект от непрерывной, всесторонней проверки кода, за которой следует автоматизированное тестирование разрабатываемого функционала. Это позволяет избавиться от далеко идущих последствий, сделать этапы разработки прозрачными, а вкупе с правильно выстроенными процессами, объективно оценить квалификацию разработчиков, что исключает риски зависимости от подрядчиков. Оценивая параметры текущей кодовой базы, мы можем оперативно выявлять и нивелировать возникающие риски, исправлять недочеты проектирования, своевременно реагировать на меняющиеся требования.
Модульная организация архитектуры стенда позволяет встраивать в процесс новые модули, тиражировать решение для необходимого количества проектов. Схематически она выглядит так:
Тестирование (сервис непрерывного тестирования)
Выше я уже говорил про сервис непрерывного тестирования, который интегрирован в конвейер процесса разработки. На данный момент на стенде реализован прогон дымовых тестов и unit-тестов. Функционал автотестов реализуется с использованием фреймворка xUnitFor1C.
Запуск процессов тестирования, так же как инспекция кода, привязан к событию коммита в репозиторий проекта. Для unit-тестов подразумевается разработка теста параллельно с разработкой функционала. Непосредственно перед их выполнением производится автоматизированное развертывание последней версии конфигурации в подготовленную тестовую информационную базу. Затем запускается клиент, который выполняет сценарии тестирования для уже реализованного функционала. Тесная интеграция сервисов автоматизированного тестирования с BSL плагином SonarQube позволяет вычислить такой параметр как покрытие кода тестами. Результат прогона тестов — отчет, который загружается в систему анализа и визуализации результатов тестирования ReportPortal. Этот сервис представляет собой портал отчетов, в котором агрегируются данные о прогонах тестов (статистика и результаты), производится базовое обучение системы по категоризации падений и дальнейшее автоматическое определение причин. Все параметры прогонов тестов доступны в удобном веб-интерфейсе с различными досками для графиков, диаграмм (виджетов). Для расширения функций портала возможно использовать собственные расширения.
Сервис автоматизированного тестирования — это еще один этап, снижающий риски попадания в релиз кода, который ломает ранее реализованной функционал или работает с ошибками.
ReportPortal. Дашборд:
ReportPortal. Неудачные запуски тестов:
ReportPortal. Типы дефектов:
ReportPortal. Редактирование типов дефектов:
Развитие
Оценивая результаты проделанной работы, мы видим, что из задуманного уже реализовано, какие идеи уже успешно работают, какие еще только предстоит реализовать.
Из планов на ближайшую перспективу развития стенда — создание портала управления сервисами стенда. Веб-интерфейс портала позволит работать с заявками на подключение проектов к стенду, с калькулятором стоимости сервисов, с их автоматизированным развертыванием по запросу под проект. В результате менеджер сразу же может получить калькуляцию стоимости выбранных услуг и оценить затраты, определить разработчиков на проект.
Мы планируем провести интеграцию портала с облачным решением эксплуатации систем 1С. Это поможет быстро разворачивать тиражируемые типовые решения в связке с сервисами разработки, реализованными на стенде для более эффективной миграции систем заказчика в облако КРОК.
Портал управления планируем также интегрировать с сервисом автоматизированного управления конфигурацией (развертывание, настройка, удаление). Это позволит сократить время развертывания, упростить настройку и обслуживание системы. А для повышения уровня безопасности внедрим сервис сквозной аутентификации по всем сервисам стенда, чтобы использовать одну и ту же учетную запись во всех из них.
Если рассматривать весь процесс с точки зрения истории полного цикла разработки решения, то созданный конвейер позволит собрать и агрегировать большое количество разнообразных метрик как по артефактам проекта, так и по специалистам, которые принимали в нем участие. Такая подробная ретроспектива будет способствовать накоплению и повторному использованию опыта в решении сложных задач, формировать команды из успешных разработчиков для более эффективной и слаженной работы.
UPD. По просьбам в комментариях добавляем список опенсурсных продуктов, которые используем, с ссылками.
| Продукт | Вендор/Автор | Ссылки №1 | Ссылки №2 |
|---|---|---|---|
| 1С | 1С | http://v8.1c.ru | |
| 1С: СППР | 1С | http://v8.1c.ru/model/ | |
| 1С: ДО | 1С | http://v8.1c.ru/doc8/ | |
| Git | SFC | https://ru.wikipedia.org/wiki/Git | |
| Gitlab | Gitlab | https://ru.wikipedia.org/wiki/GitLab | https://about.gitlab.com/ |
| Jira | Atlassian | https://ru.wikipedia.org/wiki/Jira | https://ru.atlassian.com/software/jira |
| ReportPortal | EPAM Systems, Inc. | https://github.com/reportportal | https://rp.epam.com/ui/ |
| SonarQube | SonarSource | https://ru.wikipedia.org/wiki/SonarQube | https://github.com/SonarSource/sonarqube |
| Jenkins | Косукэ Кавагути | https://ru.wikipedia.org/wiki/Jenkins | https://github.com/jenkinsci |
| SourceTree | Atlassian | https://www.sourcetreeapp.com/ | |
| xUnitFor1C | artbear | https://github.com/xDrivenDevelopment/xUnitFor1C | https://github.com/artbear |
| Gitsync | EvilBeaver | https://github.com/oscript-library/gitsync | https://github.com/EvilBeaver |
| SonarQube 1C (BSL) Plugin | Silver Bulleters | https://silverbulleters.org/sonarqube | https://github.com/silverbulleters/sonar-1c-bsl-public |
