Всем привет.
У нас в департаменте 1С ведется разработка множества проектов. Куча репозиториев, хранилищ, разработчиков, архитекторов. Каждый день вносятся десятки изменений в разные учетные системы компании.
Для хранения исходников мы используем наш корпоративный гитлаб. В нем мы можем получить информацию о коммитах конкретного репозитория/ветки, о коммитах конкретного разработчика/архитектора. Но какого-то сводного отчета, да еще бы и с фильтром по периоду и каким-то другим разрезам напрямую в гитлабе получить нельзя.
Такую же информацию из каждого хранилища конфигурации получить, в принципе, можно, но тоже не особо удобно. Тем более не всегда разработка ведется вообще с использованием хранилища.
А если у вас, как, например, у нас на проекте, 5 репозиториев и надо бы свести информацию об изменениях всех этих репозиториев в одном месте. Или вообще вспомнить, когда и куда вы что-то коммитили за прошлую неделю, чтобы заполнить отчет о трудозатратах?
А как понять, кто из разработчиков регулярно ведет активную разработку, а кто немного нет? Можно, конечно, использовать всякие сомнительные способы вроде записи экрана разработчика и удары тока при бездействии мышки, но это совсем не наш метод.
С другой стороны, мы же давно работаем в 1С и у нас есть удобная система компоновки данных прямо в любой 1С-ной базе и было бы здорово получить информацию о коммитах именно там. Еще бы и в режиме реального времени.
Например, такую информацию:
Да, это отчет в нашей общей базе. И это статистика по коммитам по всему департаменту 1С с фильтром по дате, ветке, команде разработки, разработчику и чему угодно, у нас же тут СКД, и каждый сам решает, какие именно данные ему полезны.
Или, например, такую информацию:
Кажется, в пятницу я ничего так и не закоммитил на прошлой неделе. Писал эту статью, а может просто не успел что-то выложить в гит.
Еще лучше, если бы нам на почту регулярно приходил такой отчет, чтобы не формировать его каждый раз вручную. Например, такой:
Или такой:
Сразу видно кто и как лично поработал на прошлой неделе, и какой вклад каждый внес в выпуск очередного релиза нашей системы. Есть что обсудить на ретроспективе, как говорится. И кому выдать почетный вымпел передовика производства.
Так родилась идея этой публикации, а заодно и новая версия расширения Ssl-ci под кодовым номером 1.0.3
Про идею расширения и как мы у себя до него дошли, я подробно рассказывал в прошлой публикации Devops-кухня. Рецепты приготовления дополнительных отчетов и обработок.
Если пересказать идею вкратце, то мы у себя разработали расширение для работы с апи гитлаба для синхронизации справочника дополнительных отчетов и обработок и репозитория, где ведется их разработка. Обновление всех или не всех доп. отчетов и обработок по одной кнопке, откат изменений на любой коммит, автодобавление всех новых отчетов и обработок в ci-контуре для запуска тестов и многое другое. Но это все было еще и в версии 1.0.2.
Апи гитлаба позволяет делать много других вещей, поэтому к версии 1.0.3 по сути расширение предоставляет нашу реализацию работы с этим апи на 1С.
Давайте покажу, что получилось из этой идеи. И как можно запустить такой отчет по коммитам на любом проекте, даже если вы совсем не используете функционал дополнительных отчетов и обработок.
Например для департамента 1С у нас это расширение загружено и настроено в нашей общей СППР, где никаких дополнительных отчетов и обработок нет (не включены).
Все скриншоты ниже выполнены на демо-базе БСП для чистоты эксперимента. Расширение поддерживает работу на версиях БСП 3.0.* и 3.1.*
Остальные версии не добавляли, оставили задел для контрибьютеров.
Важное дополнение. Мы у себя используем в качестве таск-трекера jira, поэтому текущая версия расширения поддерживает только интеграцию с этим таск-трекером. Но вы всегда можете либо добавить поддержку вашей версии либо вообще не использовать настройки таск-трекера, работать будет и без него (теоретически).
Новое в релизе 1.0.3
Добавили подсистему “Интеграция с гитом” в командный интерфейс. Подсистема доступна только для полноправных пользователей.
Настройки интеграции переехали в эту подсистему. Раньше для доступа к этим настройкам нужно было открывать список элементов справочника “Дополнительные отчеты и обработки”. Подробнее о настройках можно почитать тут. Расскажу только про новые настройки, которые появились в версии 1.0.3
В отчете по коммитам мы хотели получать не просто номер задачи и сообщение коммита, но и аналитику по задаче из нашего таск-трекера. Например, наименование задачи, так как просто сообщения коммита не всегда дает понимание, а что вообще дорабатывалось.
Для этого в настройках появился блок “Описание задач из таск трекера (для отчета по коммитам)”. Эти настройки используются для заполнения в справочнике “Команды разработки” по умолчанию (см. ниже).
Справочник “Команды разработки”
Справочник “Команды разработки” нужен для хранения списка репозиториев проекта.
Колонка “Наименование репозитория” нужна для вывода такой же колонки в отчете по коммитам.
Колонка “Ид репозитория” это ид проекта в гитлабе. Для конкретного репозитория его можно узнать тут:
Колонка “Префикс задачи” нужна, чтобы разбивать сообщение коммита на часть с номером задачи и часть с описанием задачи.
Например, на скриншоте мой коммит. Слева номер задачи в jira, справа описание изменения (оно, как видите, не всегда информативно). Если префикс не задать или в сообщении коммита такой префикс не найдется, то колонка “Номер задачи” в отчете не будет заполнена, и описание задачи из jira тоже не получится. Будут пустые поля.
Вот тут я уже описывал, как мы сделали так, чтобы все коммиты в любой репозиторий содержали номер задачи из трекера.
Каждая команда не всегда использует одинаковый таск-трекер или может отличаться служебный пользователь для доступа к проекту, например. Поэтому в каждой команде разработке есть свои настройки для доступа к таск-трекеру.
Но их всегда можно заполнить по умолчанию из общей настройки интеграции.
Справочник “Разработчики”
Справочник “Разработчики” нужен для сопоставления автора коммита конкретному разработчику. Часто бывает ситуация, когда один и тот же разработчик коммитит изменения под разным email, поэтому email тут сделана в виде ТЧ.
Отчет по коммитам
По умолчанию сделали 3 варианта отчета. Также сделали по умолчанию фильтр по веткам разработки (master & develop), т.к. для анализа обычно хватает данных этих двух веток. Так как многие коммиты часто бывают сразу в нескольких ветках, то ветки коммита выводятся через запятую. При получении данных о коммитах каждого репозитория перебираются все ветки репозитория, так мы можем быть уверены, что ни один коммит не пройдет незамеченным.
Разработчики к сопоставлению
Нужен на первом этапе запуска отчета для получения всех email авторов, которые делают коммиты в репозитории команды разработки.
Например, видно, что в основной репозиторий у меня были коммиты под двумя авторами с одинаковой почтой. Такое произошло потому, что в гитсинке у меня указан один автор, а напрямую в репозиторий я коммитил под другим пользователем.
Данные по коммитам
Это основной вариант отчета. Сюда выводятся подробные данные по коммитам.
Так как среди коммитов попадаются мержи изменений, которые не несут особой смысловой нагрузки для этого отчета, то по умолчанию включено игнорирование таких коммитов - флаг “Без мержей”.
Пример мерж-коммита:
Отчет показывает данные по коммитам в разрезе команды разработки и разработчика.
Поле “Номер задачи” вычисляется из сообщения коммита по префиксу задачи из настройки. Если номер задачи вычислить не получилось, то все сообщение коммита уйдет в поле “Сообщение коммита”.
Поле “Описание задачи” берет описание задачи из таск-трекера (у нас это Jira). Если интеграция с таск-трекером не настроена, то будет пустое поле, ничего страшного.
Поле “Ветка” содержит через запятую все ветки, где есть указанный коммит.
Поле “Ссылка” содержит ссылку для быстрого перехода на коммит.
Поле “Всего строк” содержит общее количество измененных строк коммита. Мы его используем для понимания - большой был коммит или нет. Это не совсем “чистые” строки кода, так как в зачет идет любое изменение файла исходников, например макета печатной формы или какой-то xml структуры.
Статистика по коммитам
Этот вариант отчета позволяет в целом оценить вклад каждого разработчика в разработку на проекте.
Мы обычно смотрим количество коммитов по дням и в целом по каким задачам велась работа за период.
Рассылка
Благодаря типовому функционалу БСП можно настроить рассылку любого варианта отчета на почту.
У нас настроено две рассылки:
-
вариант “Данные по коммитам” каждую пятницу всем разработчикам для заполнения отчета по трудозатратам
-
вариант “Статистика по коммите” всей команде разработки раз в месяц перед выпуском релиза
Для просмотра всех рассылок отчетов в БСП есть специальный справочник “Рассылки отчетов”.
Архитектура отчета
По сути перед формированием отчета мы получаем из гитлаба и jira (опционально) таблицу данных:
Дальше эти данные можно группировать/настраивать как угодно. Кроме описания задачи из jira можно получать любую другую информацию по задаче, если это необходимо.
Например, мы у себя смотрим еще плановые и фактические трудозатраты по каждой задаче из jira на СКД. Правда, в другом отчете и его выкладывать пока не планировали. Но принцип составления отчета, думаю, понятен.
Также часть процедур и функций для работы с апи в релизе 1.0.3 переехала в другой общий модуль, чтобы можно было обращаться по апи гитлаба как с клиента, так и с сервера.
Поскольку это опенсорс, то весь код открытый и реализацию всегда можно посмотреть в репозитории проекта. Например, тут
Описание апи гитлаба можно посмотреть тут. Что еще можно вытащить по коммитам, можно посмотреть, например, тут
Что можно вытащить из апи jira, можно посмотреть тут
На гитхабе есть куча разработок с разными вариантами получения такой статистики.
Также есть публикация с альтернативным способом получения статистики по коммитам тут
Заключение
В целом использование отчета по коммитам на СКД внесло в нашу разработку больше порядка и, лично для меня, понимания, кто и чем занимается на проекте.
Надеюсь что этот отчет пригодится и вам в вашей работе. Или нет. На вкус и цвет все фломастеры разные.
