Legora — это агентная операционная система для юридической работы, помогающая юристам в проведении исследований, анализе и составлении документов по сложным делам. Ею пользуются более 100 000 юридических специалистов в более чем 1 800 ведущих юридических фирмах и инхаус-командах в более чем 50 странах. Инженерный отдел развивался не менее темпами. Монорепозиторий вырос почти в два раза за год до более чем 600 проектов, а количество ежемесячных запусков CI выросло в шесть раз — и все это при поддержке команды платформы из трех человек. Их монорепозиторий построен на базе Nx, в основном на TypeScript, но также включает 43 проекта на Python, крейт на Rust, сервис на Java и проверки protobuf, и все это запускается в едином пайплайне Nx Agents.
Проблема
Рост Legora опережал настройки CI, созданные для его поддержки. Проверки выполнялись через матрицу GitHub Actions на Blacksmith с фиксированными размерами раннеров для каждой проверки и вручную настроенным шардированием (в 2 раза для функциональных тестов, в 6 раз для приемочных тестов) — конфигурация, хорошо подходившая под размер команды на тот момент. Этот рабочий процесс вырос с 94 до 621 строки без учета комментариев в период с марта по май 2026 года. Учитывая рост числа уникальных PR на 35% только в июне, модель со статической матрицей была не просто неудобной — ее становилось все сложнее поддерживать по мере масштабирования компании. Поддержание ее в актуальном состоянии вручную превращалось в растущую проблему для команды платформы из трех человек, так как по мере добавления новых проектов ничего не перебалансировалось автоматически. Приоритетом команды была прежде всего стабильность: убедиться, что быстро растущая инженерная организация может доверять своему пайплайну, прежде чем оптимизировать что-либо еще.
Кроме того, серьезным препятствием было доверие к кешу. К весне команда отключила кеширование для производственных сборщиков и написала собственный чекер, который выполнял сборку без кеша и сравнивал контрольные суммы вывода, поскольку закешированные и свежие сборки периодически расходились.
Решение
Песочница задач Nx Cloud заменила эти догадки трассировкой каждого файла, который реально читал и записывал каждый таск. Первый полный запуск выявил 811 проблем в 968 тасках. Примерно шесть недель спустя команда свела нарушения в песочнице к нулю и впервые включила строгий режим (strict mode). К середине июня коэффициент попадания в кеш вырос примерно с 50% до 73% всего за две недели.
Я поставила перед собой задачу свести нарушения в песочнице к нулю, чтобы мы могли действительно доверять нашему кешу. Чего я не ожидала, так это всех остальных проблем, которые это вскрыло: конфигурация, которая тихо ломала сама себя, входные данные, которые были незаметно перепутаны. В итоге весь репозиторий стал здоровее и быстрее.Софи Торсен(Sofie Thorsen)Сотрудник технического отдела, Legora
Я поставила перед собой задачу свести нарушения в песочнице к нулю, чтобы мы могли действительно доверять нашему кешу. Чего я не ожидала, так это всех остальных проблем, которые это вскрыло: конфигурация, которая тихо ломала сама себя, входные данные, которые были незаметно перепутаны. В итоге весь репозиторий стал здоровее и быстрее.
Софи Торсен
Сотрудник технического отдела, Legora
Затем Legora перенесла основные проверки кода на Nx Agents: веерную рассылку (fan-out) затронутых тасков для сборок, проверки типов, линтинг, модульные, функциональные и приемочные тесты — все это запускается на том же арендаторе Nx Cloud, который команда уже использовала в качестве удаленного кеша. Исчезла поддерживаемая вручную матрица, которая раньше назначала каждую проверку на определенный раннер.
Это примерно вдвое сокращает объем конфигурации рабочего процесса для поддержки, а для распределенных проверок отменяет ручное шардирование, подбор размера раннеров для каждой проверки и настройку обязательных проверок, которые требуются для Blacksmith. По мере добавления проектов система сама производит перебалансировку, в то время как Blacksmith требует постоянной ручной настройки.Софи Торсен(Sofie Thorsen)Сотрудник технического отдела, Legora
Это примерно вдвое сокращает объем конфигурации рабочего процесса для поддержки, а для распределенных проверок отменяет ручное шардирование, подбор размера раннеров для каждой проверки и настройку обязательных проверок, которые требуются для Blacksmith. По мере добавления проектов система сама производит перебалансировку, в то время как Blacksmith требует постоянной ручной настройки.
Софи Торсен
Сотрудник технического отдела, Legora
Как работают Nx Agents
Распределенное выполнение задач (DTE) в Nx Agents — это оркестратор распределения задач, а не раннер. Вместо того чтобы заранее назначать конкретные проверки конкретным раннерам, Nx непрерывно, задача за задачей, решает, какой агент какую работу выполняет. Пул агентов находится в готовности, и по мере освобождения каждый из них берет следующую задачу из очереди. Здесь нет заранее определенных границ шардов и нет ручного маппинга конкретной проверки на раннер определенного размера.
Эта непрерывная модель сама по себе решает несколько задач. Задачи, которые завершаются быстро, не простаивают в ожидании более медленной соседней задачи, а работа продолжает поступать к любому свободному агенту. Правила назначения направляют ресурсоемкие (по CPU или памяти) нетипичные задачи соответствующим образом, чтобы они не вызывали сбоев из-за нехватки памяти (OOM) на агенте недостаточного размера. Если задача определяется как нестабильная (flaky), Nx автоматически повторяет ее на новой машине, вместо того чтобы прерывать весь запуск. Песочница задач обеспечивает герметичность выполнения: каждый файл, который задача читает или пишет, отслеживается, а неявный доступ приводит к сбою задачи, поэтому закешированный результат и свежая сборка не могут незаметно разойтись. А поскольку Nx Cloud оркестрирует запуск, он собирает данные об использовании на уровне задач (процессор и память для каждой задачи) для настройки — видимость, которую модель со статической матрицей предоставить не может.
По мере роста кодовой базы ничего из этого не требует повторной настройки: новые проекты и тесты попадают в тот же непрерывный поток без необходимости кому-либо корректировать количество шардов или размеры агентов.
Результаты
Для проверок, перенесенных на Nx Agents, конфигурация CI сократилась примерно вдвое, а ручное шардирование, настройка размера раннеров для каждой проверки и привязка обязательных проверок, которые раньше требовались для этих проверок, ушли в прошлое.
У нас небольшая команда по обеспечению эффективности разработки (Dx) из трех человек, поэтому динамическое непрерывное назначение задач в DTE гораздо лучше подходит для монорепозитория нашего размера, чем статическая матрица. Оно также устраняет проблему, когда медленный шард заставляет простаивать весь остальной парк.Софи Торсен(Sofie Thorsen)Сотрудник технического отдела, Legora
У нас небольшая команда по обеспечению эффективности разработки (Dx) из трех человек, поэтому динамическое непрерывное назначение задач в DTE гораздо лучше подходит для монорепозитория нашего размера, чем статическая матрица. Оно также устраняет проблему, когда медленный шард заставляет простаивать весь остальной парк.
Софи Торсен
Сотрудник технического отдела, Legora
Рабочий процесс DTE теперь запускает 16 таргетов в TypeScript, Python, Rust и Java, а также семь общерепозиторных защитных механизмов (guardrails), которых не существовало в мае: дрифт локфайлов, синхронизация сгенерированных файлов, правила соответствия (conformance), версионирование авторизации, ключи перевода, совместимость protobuf и бандлы Temporal. Все это умещается в меньшее количество строк конфигурации, чем старая матрица.
