«Иначе вы летите вслепую»: AWS собрала дашборд Git-метрик из шести серверлесс-сервисов

Зачем считать коммиты

Git-активность — один из самых богатых сигналов, которые производят инженерные команды, и источник непрерывной наблюдаемости за процессом разработки. Извлекать эти метрики в масштабе традиционно означало писать extract, transform and load (ETL) задачи руками, держать выделенную инфраструктуру и постоянно её сопровождать.

AWS описывает это через свою рамку AI-Driven Development Lifecycle (AI-DLC): если вы используете ИИ-инструменты для написания кода, нужны цифры, которые это подтверждают. Иначе вы летите вслепую и не узнаете, ускоряет ли ИИ работу, просто ли раздувает число коммитов или тихо приносит проблемы с качеством, которых никто не ожидал. Первое, что предлагает рамка, — задать базовый уровень, отслеживать изменения и продолжать наблюдение.

Решение выровнено по столпу наблюдаемости AI-DLC, потому что даёт непрерывное автоматическое измерение активности разработки: команда устанавливает базовую скорость до внедрения ИИ-инструментов, отслеживает изменения по ходу развёртывания и количественно оценивает улучшения со временем.

Шесть управляемых сервисов вместо самописного ETL

Архитектура собрана из шести ключевых сервисов AWS. Amazon EventBridge Scheduler запускает рабочий процесс по настроенному интервалу и выполняет цикл сбора автоматически, без внешних триггеров и ручного вмешательства. Оркестрацией занимается машина состояний AWS Step Functions: сначала она вызывает детектор изменений, чтобы понять, была ли новая активность, а по результату выбирает между полной и инкрементальной загрузкой. Полная загрузка собирает все метаданные репозиториев с нуля при первом запуске и далее каждые 24 часа, инкрементальная — только изменившееся с прошлого запуска, что сокращает число вызовов API и время исполнения.

Дальше workflow оценивает число активных репозиториев: если оно выше порога чанкования (по умолчанию 20), репозитории режутся на равные чанки и обрабатываются параллельно через Map state, причём каждый чанк обслуживает отдельный вызов AWS Lambda; если ниже порога, все репозитории собирает один прямой вызов. В рабочем процессе есть развёрнутая логика повторных попыток с экспоненциальной задержкой на случай временных сбоев API.

Детектор github-change-detector запрашивает ленты активности, чтобы определить тип загрузки, и следит за шестью категориями событий: push, пул-реквесты, создание и обновление issue, создание репозитория, удаление репозитория и изменения контрибьюторов. Если релевантных событий с прошлой проверки не нашлось, workflow завершается досрочно. Коллектор github-metrics-collector выполняет сам сбор данных и работает в трёх режимах: collect_all для прямой обработки, collect_chunk для подмножества репозиториев при параллельном исполнении и aggregate для объединения результатов чанков.

Токены Git хранятся в AWS Secrets Manager, и обе Lambda достают их в рантайме, поэтому учётные данные не зашиты в код и не передаются как переменные окружения. Собранные метрики лежат в Amazon S3 с включёнными версионированием и серверным шифрованием: на выходе структурированный JSON с полным ответом API и вложенными деталями по репозиториям плюс плоский CSV, оптимизированный под аналитику; в оба файла попадают имя репозитория, общее число коммитов, открытые и закрытые пул-реквесты, открытые и закрытые issue, число контрибьюторов, основной язык, время последней активности и дата создания репозитория.

Визуализацию берёт на себя Amazon Quick Sight: он читает CSV из S3 или через Amazon Athena для SQL-запросов и грузит данные в SPICE (Super-fast, Parallel, In-memory Calculation Engine), чтобы строить интерактивные дашборды — сводные метрики, тренды пул-реквестов, активность разработки во времени, разбор по отдельным репозиториям и анализ контрибьюторов.

Что экономит деньги и время

Первое заявленное свойство — интеллектуальное определение изменений: отдельная функция следит за GitHub events API и лентами активности GitLab, чтобы понять, были ли с прошлого сбора коммиты, пул-реквесты, issue, создание или удаление репозитория, и если изменений нет, обработка пропускается целиком. Второе — адаптивное чанкование: организациям с более чем 20 репозиториями решение автоматически режет нагрузку на параллельные чанки и обрабатывает их одновременно через Map state в Step Functions.

Третье — полные и инкрементальные загрузки: при первом исполнении система делает полную загрузку метаданных всех репозиториев, дальше использует инкрементальную логику и собирает только изменившееся, а полный refresh автоматически запускается каждые 24 часа ради точности данных. Четвёртое — настраиваемое расписание: частота сбора задаётся параметром AWS CloudFormation, который принимает и выражения rate(), и выражения cron().

Параметры установки в примере AWS тоже конкретны: расписание rate(10 minutes), порог чанкования 20 репозиториев и список платформ github,gitlab. Сам стек доходит до статуса CREATE_COMPLETE за 3–5 минут и создаёт S3-бакет с версионированием и шифрованием, две Lambda-функции на Python 3.13, IAM-роль исполнения с минимальными правами, машину состояний Step Functions, правило расписания EventBridge и связанные IAM-роли.

Публикация честно проговаривает границу решения: шаблон CloudFormation разворачивает для Lambda-функций только код-заглушку, и его нужно заменить реальной логикой. Для этого в репозитории лежит предсобранный пакет lambda-package.zip в каталоге deployment/, который загружается в созданный бакет S3 и подставляется в обе функции через aws lambda update-function-code.

Развёртывание и эксплуатация

Для GitHub предлагается брать минимально необходимые права, а не токен с избыточными полномочиями: repo — доступ только на чтение метаданных репозитория, коммитов и пул-реквестов — и read:org для чтения состава организации. Для GitLab нужен отдельный токен доступа с нужными скоупами, значение которого затем копируется и хранится в секрете.

Проверка после развёртывания описана по шагам: запустить исполнение workflow вручную и убедиться, что успешный прогон даёт статус SUCCEEDED за несколько минут, а в бакете S3 по префиксу output/ появляется файл response.json. Для дашбордов нужен manifest-файл, указывающий на бакет и JSON, после чего датасет подключается в Quick Sight; если Quick Sight не имеет доступа к бакету, доступ к S3-ресурсам нужно авторизовать в его настройках безопасности.

Мониторинг предлагается строить на Amazon CloudWatch: например, создать аларм, который срабатывает, когда число ошибок исполнения Step Functions превышает ноль в часовом окне, и шлёт уведомление в топик Amazon SNS для операционной команды. Уборка ресурсов описана в обратном порядке: сначала очистить и удалить S3-бакет, затем удалить стек CloudFormation и проверить статус через describe-stacks, после — удалить секреты из Secrets Manager и убрать созданные датасеты и анализы из консоли Quick Sight.

Что это даёт командам

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

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