Разработка с помощью ИИ может увеличить скорость создания кода командами, но этот прирост скорости реализуется только в том случае, если CI успевает за этим темпом. Большее количество пул-реквестов (PR) означает больше сборок, тестов и выполнений пайплайнов. Медленные задачи заставляют разработчиков и агентов кодирования ждать результатов, нестабильные падения тратят время на перезапуски и расследования, а избыточное выполнение тестов увеличивает потребность в раннерах по мере роста объемов поставки.
Datadog CI/CD Optimization помогает платформам, командам DevEx и DevOps превращать ускоренную разработку в больший объем поставляемого ПО. Решение объединяет данные о пайплайнах и тестах с коммитами, логами, раннерами и инфраструктурой каждого запуска, помогая командам сокращать циклы обратной связи, повышать надежность результатов CI и удерживать расходы на вычисления от роста пропорционально объемам пайплайнов. Разработчики могут быстрее проводить изменения через CI, в то время как платформенные команды тратят меньше средств на обработку каждой единицы работы по поставке.
В этой статье мы расскажем, как CI/CD Optimization помогает вам:
- Ускорять поставку за счет устранения узких мест в CI
Ускорять поставку за счет устранения узких мест в CI
- Повышать надежность CI за счет сокращения нестабильных тестов
Повышать надежность CI за счет сокращения нестабильных тестов
- Масштабировать поставку без масштабирования расходов на CI
Масштабировать поставку без масштабирования расходов на CI
- Исследовать пайплайны и тесты в едином пространстве
Исследовать пайплайны и тесты в едином пространстве
Ускорять поставку за счет устранения узких мест в CI
Сокращение времени выполнения пайплайна начинается с поиска мест, где реально накапливается задержка. Задача, которая тратит несколько минут на ожидание раннера, требует иного подхода, чем задача, время выполнения которой ухудшилось, поэтому простое добавление ресурсов не обязательно решает первопричину проблемы.
CI/CD Optimization отслеживает время выполнения пайплайнов, время в очереди, частоту сбоев и тенденции надежности в различных средах CI. Платформенные команды могут использовать эти сигналы для выявления пайплайнов и задач, оказывающих наибольшее влияние на поставку. Начиная с отдельного запуска, они могут исследовать этапы и задачи, влияющие на общую длительность, и связывать изменения производительности с соответствующими коммитами, ошибками, логами, раннерами и метриками инфраструктуры.
Такое различие помогает командам выбрать правильное решение. Если задача выполняется медленно из-за ожидания недостаточно крупного пула раннеров, может помочь добавление ресурсов. Если же замедлилась сама задача, команды могут исследовать изменения в коде, зависимостях, тестах или инфраструктуре, приведшие к регрессу, вместо того чтобы платить за выполнение той же медленной работы на большем количестве раннеров.
CI/CD Optimization также помогает командам выявлять регрессии до того, как они заблокируют новые изменения. Мониторы CI/CD и тестов могут предупреждать команды о сбоях или деградации пайплайнов и задач, предоставляя специалистам путь от алерта к затронутым данным CI. Вместо того чтобы узнавать об общем узком месте после того, как разработчики начинают жаловаться, платформенные команды могут исследовать изменения в состоянии пайплайнов по мере их возникновения.
Результатом становится более точный ответ на вопрос: «Почему это слияние занимает так много времени?». Каждая минута, которую команды убирают с часто выполняемого критического пути, — это минута, возвращаемая разработчикам и агентам кодирования при множестве изменений. По мере накопления этой экономии команды могут пропускать через CI больше PR и выпускать больше релизов без простого наращивания емкости раннеров. Используя Datadog, компания Betterment сократила среднюю длительность сборки почти с 40 минут до менее чем 10 минут, а The Browser Company сократила время CI-пайплайна на 50%, уменьшив интервал между изменением кода и получением полезной обратной связи.
Повышать надежность CI за счет сокращения нестабильных тестов
Более быстрые пайплайны увеличивают скорость поставки только тогда, когда разработчики доверяют результату. Нестабильный тест может окрасить успешную сборку в красный цвет, инициировать повторный запуск и потребовать от инженера выяснения того, отражает ли сбой изменение в коде. Когда это происходит регулярно, время, сэкономленное в других частях CI, теряется на расследования и повторные выполнения.
Инструмент управления нестабильными тестами (Flaky Management) в CI/CD Optimization выводит нестабильные тесты наряду с такими метриками, как сбои пайплайнов, потерянное в CI время и частота сбоев, позволяя командам расставлять приоритеты для тех сбоев, которые отнимают больше всего времени разработчиков и вычислительных ресурсов.
Командам не обязательно ждать устранения каждого нестабильного теста, чтобы предотвратить блокировку поставки такими тестами. Функция автоматического повтора тестов (Auto Test Retries) автоматически перезапускает падающие тесты до заданного предела, останавливаясь при успешном прохождении теста или исчерпании доступных попыток. Это помогает предотвратить ситуацию, когда сбой спорадического теста приводит к падению всей сборки и требует от разработчика ручного перезапуска.
Чтобы блокировать известные нестабильные тесты во время работы над исправлениями, команды могут использовать раннее обнаружение нестабильности (Early Flake Detection) и шлюзы PR (PR Gates), помогающие предотвратить попадание новых нестабильных тестов в ветку по умолчанию. Эти средства контроля работают на разных этапах жизненного цикла нестабильного теста: повторы снижают мгновенные неудобства, политики защищают от многократной блокировки несвязанных изменений известными сбоями, а обнаружение помогает остановить рост отставания.
Проводник управления нестабильностью (Flaky Management Explorer) делает результаты этой работы наглядными на уровне пайплайна. Он отслеживает такие метрики, как сбои из-за нестабильных тестов, потерянное из-за этих сбоев время CI, пайплайны, спасенные с помощью автоматических повторов, и время, сэкономленное благодаря оптимизации выполнения тестов.
Каждый ручной перезапуск, которого удается избежать разработчикам, возвращает их внимание к созданию продукта, а каждый нестабильный сбой, переставший блокировать валидное изменение, помогает большему количеству кода проходить через CI без еще одного полного выполнения пайплайна.
Масштабировать поставку без масштабирования расходов на CI
По мере ускорения разработки в CI поступает все больше изменений. Добавление раннеров может увеличить пропускную способность, но оно не решает проблему избыточной работы. Если каждый коммит по-прежнему выполняет избыточный набор тестов, более крупный пул раннеров может быстрее выполнять ту же нерелевантную работу, одновременно увеличивая расходы на инфраструктуру.
Анализ влияния тестов (Test Impact Analysis) сокращает объем работы, попадающей в пайплайн. Datadog сопоставляет тесты с кодом, который они покрывают, и использует эту информацию для определения того, какие тесты затронуты изменениями. Тесты, не имеющие отношения к изменениям, могут быть пропущены, что сокращает цикл обратной связи и избавляет от затрат на вычисления, которые они бы потребили.
Например, PR, в котором обновляется только файл README, может не требовать запуска тестов приложения. Выполнение полного набора увеличивает время CI без проверки измененного кода приложения и может подвергнуть сборку риску несвязанных нестабильных сбоев. Определяя, какие тесты затрагиваются изменением, Test Impact Analysis позволяет исключить эту лишнюю работу из критического пути.
Параллелизация тестов (Test Parallelization) помогает тем тестам, которые действительно необходимо запустить, завершаться быстрее. Она использует ожидаемую длительность тестов для выполнения необходимых проверок наиболее эффективным способом. Вместо разделения тестов по количеству и ожидания, пока один раннер обрабатывает долго выполняющиеся тесты после завершения остальных, система оценивает оптимальное число воркеров CI, а затем распределяет между ними тесты для завершения валидации как можно быстрее и с наименьшими затратами.
В совокупности эти возможности CI/CD Optimization помогают командам выполнять меньше лишней работы и быстрее завершать необходимую. Разработчики и агенты по кодированию быстрее получают результат, в то время как тот же парк раннеров может обрабатывать больше изменений. По мере роста объемов разработки команды могут выпускать больше релизов без необходимости пропорционально увеличивать расходы на раннеры и вычислительные мощности.
Исследуйте пайплайны и тесты в едином пространстве
Состояние пайплайнов и состояние тестов часто представляют собой две стороны одной и той же проблемы доставки. Разделение слишком большого набора тестов и нестабильного (flaky) теста заставляет инженеров тратить время на сопоставление данных, хотя цель состоит в том, чтобы провести изменение через CI и отправить его в продакшен.
CI/CD Optimization объединяет данные пайплайнов и тестов в рамках единого интерфейса Datadog, позволяя командам переключаться между выполнениями пайплайнов, заданиями и тестами при расследовании проблем доставки. Если PR заблокирован из-за сбоя в пайплайне, инженер может сразу открыть выполнение и выявить проблемное задание тестирования. Затем он может изучить историю сбоев теста, чтобы понять, происходил ли аналогичный сбой до внесения изменений. Вы можете ознакомиться с базовыми возможностями в документации по CI Visibility и документации по Test Optimization.
Поскольку данные CI являются частью платформы Datadog, команды также могут связывать сбои пайплайнов с логами и метриками инфраструктуры. Например, инженер, расследующий причину медленной работы задания, может определить, увеличилась ли его продолжительность из-за проблем с инфраструктурой раннеров, вместо того чтобы предполагать, что источником регрессии является само задание.
CI/CD Optimization также поддерживает команды, чьи среды охватывают такие CI-платформы, как GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps, CircleCI и Buildkite, а также облачные и локальные (self-hosted) раннеры. Команды могут оценивать производительность пайплайнов и тестов в этих средах, не ограничивая свой анализ дашбордами конкретных провайдеров.
Объединение данных пайплайнов и тестов означает меньше минут ожидания, меньше повторных запусков и меньше затрат вычислительных ресурсов на одно изменение. Это дает командам больше возможностей для продвижения ПО через CI в условиях, когда разработка с поддержкой ИИ увеличивает объем кода, готового к релизу.
Доставляйте быстрее без пропорционального роста затрат на CI
Datadog CI/CD Optimization помогает командам ускорять поставку за счет повышения надежности и экономической эффективности CI по мере роста объемов разработки. Команды могут находить узкие места, задерживающие наибольшее количество изменений, автоматически перезапускать нестабильные тесты, которые в противном случае приводили бы к сбоям сборки, пропускать тесты, выполнение которых не требуется, и использовать параллелизацию тестов (Test Parallelization) для скорейшего завершения оставшейся рабочей нагрузки тестирования.
Эта комбинация помогает разработчикам и агентам по кодированию тратить меньше времени на ожидание CI, а платформам — обрабатывать больший объем пайплайнов и тестов без пропорционального роста затрат на раннеры. Чтобы начать работу, ознакомьтесь с документацией по CI/CD Optimization и документацией по Test Impact Analysis.
Если у вас нет учетной записи Datadog, зарегистрируйтесь для получения бесплатной 14-дневной пробной версии, чтобы ускорить выпуск релизов с помощью надежного и экономичного CI.
