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