Работая с кэшем Xcode, стало совершенно ясно: это в корне проблема инфраструктуры в глубоко фрагментированном ландшафте систем сборки. Мы немедленно удвоили усилия в области инфраструктуры, потому что это наша защита. Но по мере углубления стало очевидно, что одной инфраструктуры недостаточно. Нам нужно было по-другому подходить к разработке программного обеспечения. Компании уже много лет делают это для Bazel, так что что могло бы сделать нас другими? Когда мы оглянулись вокруг, возникли два паттерна, которые сформировали наше мышление. Во-первых, все больше систем сборки принимают возможности кэширования. Скорость и объем, с которыми мы производим код, продолжают расти, и кэширование больше не является опциональным. Это необходимо. Во-вторых, нет стандартизации. Фрагментация систем сборки неизбежно приведет к фрагментации сервисов. Один сервис кэширования на каждую систему сборки. Одна инфраструктура на инструмент. Одни и те же проблемы решаются снова и снова немного разными способами. В Tuist мы могли бы решить эту проблему для Xcode и на этом остановиться. Но что если мы создадим что-то более фундаментальное? Что если мы создадим узкую талию между миром систем сборки и миром инфраструктуры кэширования? Уровень, который позволяет любой системе сборки взаимодействовать с любым бэкендом кэширования, а не создавать еще одно вертикальное решение. Я начал экспериментировать с этой идеей, и я убежден, что это путь вперед. Мы строим основу для инфраструктуры систем сборки как услуги. Не один сервис на систему сборки. Одно решение, которое работает для всех них. Что-то, что мы разрабатываем, поддерживаем и предлагаем как управляемый сервис, который может использовать любая команда, независимо от их инструмента сборки. И да, мы только начинаем с инфраструктуры. Наша цель — приблизить ее к тому месту, где разработчики, агенты и CI-пайплайны действительно выполняют свою работу. Проблема фрагментации в нашей отрасли реальна, и мы строим инфраструктуру для ее решения.