Varför är en dedikerad byggcache användbar för utvecklare som arbetar med flera enheter?
En dedikerad byggcache är användbar när samma kodförråd byggs på en bärbar dator, stationär dator, CI-körmiljö eller plattformar med blandade processorer, och kostnaden för upprepat arbete överstiger kostnaden för cacheöverföring och underhåll.
Cachen bör förbli en optimering, inte sanningskällan. Byggen måste fortfarande lyckas efter en cachemiss, medan cache-nycklar, förtroendegränser, kvoter och skräpinsamling hindrar en enhet från att förgifta eller fylla den delade tjänsten.
Mät arbete som upprepas mellan enheter
Registrera nedladdningar av beroenden, containerlager, kompilerade objekt, genererade tillgångar och den totala byggtiden på varje enhet. Räkna hur ofta samma indata byggs om när du byter maskin eller startar ett tillfälligt CI-jobb.
En praktisk genomgång av fjärrcache i Bazel förklarar hur flera maskiner kan återanvända artefakter i stället för att oberoende bygga om identiska indata.
En dedikerad cache är motiverad när arbete upprepas ofta, artefakterna är deterministiska och överföringstiden är kortare än omberäkningstiden. Den tillför inte mycket värde när projekten är små eller enheterna sällan delar indata.
Definiera cache-nycklar och förtroendegränser
Nycklar bör omfatta källindata, låsta beroenden, kompilator- eller runtime-version, målarkitektur, viktiga miljöflaggor och byggsteget. En bred nyckel ger falska träffar, medan en alltför snäv nyckel inte ger någon återanvändning.
Ge betrodda CI-jobb skrivåtkomst och överväg skrivskyddad åtkomst för utvecklardatorer eller obetrodda grenar. En cachepost kan innehålla körbart resultat, så att tillåta skrivningar från godtycklig kod är ett beslut som påverkar leveranskedjans säkerhet.
Separata arkitekturer och verktygskedjegenerationer. En bärbar dator med Apple Silicon och en x86-baserad Linux-körmiljö kan dela hämtade källpaket, men behöver olika kompilerade artefakter.
Placera cachen nära det arbete som kostar mest
| Cacheväg | Styrka | Begränsning |
|---|---|---|
| Lokal cache per enhet | Lägst latens | Ingen återanvändning mellan enheter |
| Cache-server på det lokala nätverket | Snabb återanvändning hemma | Otillgänglig när du är borta |
| Register eller objektlagring | Fungerar på olika platser | Överförings- och utgående trafik |
| Fjärrbyggvärd | Cachen stannar nära beräkningsresurserna | Blir en exekveringsinfrastruktur |
| Hybridlösning med lokal och delad cache | Snabba cacheträffar och bred återanvändning | Mer policy att underhålla |
För ett arbetsflöde i hemmet bör du ha en liten lokal cache på varje enhet och en större delad cache på servern. Fjärrutvecklare kan använda det delade lagret bara när nätverksanslutningen är tillräckligt snabb för att det ska gå fortare än att bygga om.
Håll cachen borta från skyddade familjedelningar och säkerhetskopieringsmål. Hög omsättning och automatisk borttagning hör hemma i en dedikerad datamängd med egen kvot.
Hantera kvoter, skräpinsamling och cachemissar
Ange en maximal storlek, en övre och en nedre gräns, en maximal ålder och en policy för stora poster. Följ upp träffsäkerhet, överförda byte, sparad byggtid, borttagningsfrekvens och tid som läggs på uppslag i cachen.
En praktisk redogörelse för drift av infrastruktur för fjärrbyggen noterar att cacheenheter kan fyllas snabbare än skräpinsamlingen hinner rensa dem och att nätverkets svanslatens kan utradera vinsterna i genomsnitt.
Fortsätt utan cache om den inte är tillgänglig: bygget ska räkna om i stället för att stoppas. Återställ tjänsten från konfigurationen och låt posterna fyllas på igen, såvida en viss cache inte innehåller proveniensdata som inte går att återskapa.
Sätt en gräns för när cachen ska användas eller stoppas
Driftsätt en dedikerad cache när minst två enheter bygger om samma resurskrävande indata, träffsäkerheten går att mäta och en policy för en betrodd skrivare kan tillämpas. Börja med en verktygskedja i stället för att cacha alla pakethanterare på en gång.
Dela upp cachetjänsterna när projekten har olika krav på förtroende, lagringstid eller I/O-mönster. Lägg till SSD-kapacitet när borttagning av inaktuella objekt rensar bort ofta använda artefakter; lägg bara till nätverkskapacitet när överföringar, inte uppslag eller kompilering, är den uppmätta flaskhalsen. Arbetsflödet för testning av SMB med små filer kan hjälpa till att identifiera överföringsbegränsningar som beror på metadata.
Sluta utöka cachen om träffsäkerheten förblir låg eller incidenter med ogiltigförklaring kostar mer än den sparade byggtiden. En cachemiss utan problem är billigare än en snabb, felaktig artefakt.
Slutlig konfigurationsregel
Konfigurationen är godkänd när varje tjänst har en namngiven roll, ett skyddat tillstånd, en kontrollerad åtkomstväg, ett testat återställningsförfarande och en mätbar utlösare för att dela upp eller utöka topologin.
Rekommenderade produkter
Installation av NAS och server
Mer att läsa
Kan en server i studentrummet vara tillräckligt tyst för sömn, studier och videosamtal?
Ja - en server i studentrummet kan vara diskret om hårdvaran har låg strömförbrukning, vibrationer från lagringsenheterna dämpas, tunga jobb schemaläggs och ljudnivån testas...
Ett studenthomelabb som kan flytta från studentrummet till den första lägenheten
Gör studentens hemlabb portabelt genom att skilja tjänsterna från nätverket i det enskilda rummet, minimera hårdvaran, säkerhetskopiera data och öva på en smidig flytt.
Så delar du en hemmaserver med rumskamrater utan att dela konton eller privata filer
Ge varje rumskamrat en namngiven identitet, privat lagring och endast de delade roller som hen behöver; håll administration, säkerhetskopiering och avslut av åtkomst åtskilda.
