Tijdens het werken aan de Xcode-cache werd iets kristalhelder: dit is fundamenteel een infrastructuurprobleem in een diep gefragmenteerd landschap van buildsystemen. We hebben onmiddellijk extra ingezet op infrastructuur omdat het onze voorsprong is. Maar naarmate we dieper groeven, werd het duidelijk dat alleen infrastructuur niet genoeg was. We moesten software ook anders aanpakken. Bedrijven doen dit al jaren voor Bazel, dus wat zou ons anders kunnen maken? Toen we om ons heen keken, kwamen er twee patronen naar voren die ons denken vormden. Ten eerste, meer buildsystemen nemen cachingmogelijkheden over. De snelheid en hoeveelheid waarin we code produceren blijft toenemen, en caching is niet langer optioneel. Het is essentieel. Ten tweede, er is geen standaardisatie. De fragmentatie van buildsystemen zal onvermijdelijk leiden tot fragmentatie van diensten. Eén cachingdienst per buildsysteem. Eén infrastructuur per tool. Dezelfde problemen keer op keer opgelost op iets andere manieren. Bij Tuist hadden we dit voor Xcode kunnen oplossen en het daarbij kunnen laten. Maar wat als we iets fundamentelers bouwden? Wat als we een smalle taille creëerden tussen de wereld van buildsystemen en de wereld van cachinginfrastructuur? Een laag die elk buildsysteem laat communiceren met elke cachingbackend, in plaats van weer een verticale oplossing te bouwen. Ik begon met het experimenteren met dit idee, en ik ben ervan overtuigd dat dit de weg vooruit is. We bouwen de basis voor buildsysteeminfrastructuur als een dienst. Niet één dienst per buildsysteem. Eén oplossing die over allemaal werkt. Iets dat we ontwikkelen, onderhouden en aanbieden als een beheerde dienst die elk team kan gebruiken, ongeacht hun buildtool. En ja, we zijn net begonnen met infrastructuur. Onze visie is om het zo dicht mogelijk bij de rand te brengen, waar ontwikkelaars, agents en CI-pijplijnen daadwerkelijk hun werk doen. Het fragmentatieprobleem in onze industrie is echt, en we bouwen de infrastructuur om het op te lossen.