Під час роботи над кешем Xcode щось стало кришталево зрозумілим: це фундаментальна проблема інфраструктури в глибоко фрагментованому ландшафті систем збірки. Ми одразу подвоїли зусилля на інфраструктурі, тому що це наш рів. Але коли ми копнули глибше, стало очевидно, що однієї інфраструктури недостатньо. Нам теж потрібно було робити програмне забезпечення по-іншому. Компанії роблять це для Bazel протягом багатьох років, тож що може відрізняти нас? Коли ми озирнулися навколо, то виявили дві закономірності, які сформували наше мислення. По-перше, все більше систем збірки використовують можливості кешування. Швидкість і обсяг, з яким ми створюємо код, постійно зростає, а кешування більше не є необов'язковим. Це важливо. По-друге, немає стандартизації. Фрагментація системи збірки неминуче призведе до фрагментації служби. Одна служба кешування на кожну систему збірки. Одна інфраструктура на інструмент. Одні й ті ж проблеми вирішувалися знову і знову трохи по-різному. У Tuist ми могли б вирішити це для Xcode і закінчити цей день. Але що, якщо ми побудуємо щось більш фундаментальне? Що, якщо ми створимо вузьку межу між світом систем збірки та світом інфраструктури кешування? Шар, який дозволяє будь-якій системі збірки обмінюватися даними з будь-яким бекендом кешування, а не створювати ще одне вертикальне рішення. Я почав працювати над цією ідеєю, і переконався, що це шлях уперед. Ми будуємо основу для побудови системної інфраструктури як послуги. Не один сервіс на систему збірки. Одне рішення, яке працює для всіх них. Щось, що ми розробляємо, підтримуємо та пропонуємо як керований сервіс, який може використовувати будь-яка команда, незалежно від інструменту складання. І так, ми тільки починаємо працювати з інфраструктурою. Наше бачення полягає в тому, щоб максимально наблизити його до місця, де розробники, агенти та пайплайни CI насправді виконують свою роботу. Проблема фрагментації в нашій галузі реальна, і ми будуємо інфраструктуру для її вирішення.