Varför flyttar utvecklare CI-körningar, register och testdatabaser bort från sina bärbara datorer?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Why Are Developers Moving CI Runners, Registries, and Test Databases Off Their Laptops? - Zima Store Online

Team flyttar dessa tjänster från bärbara datorer för att göra byggen reproducerbara, gemensamma beroenden tillgängliga, testtillstånd flyktiga och leveransen oberoende av en utvecklares batteri eller arbetsmiljö.

Servern är inte en större bärbar dator. En CI-körning exekverar opålitliga projektinstruktioner, ett register lagrar artefakter från leveranskedjan och en testdatabas innehåller föränderligt tillstånd. Att kombinera dem kan vara effektivt för ett litet team, men bara när identiteter, nätverk, lagring, hemligheter, kvoter och återställning separeras efter roll.

Börja med arbetsflödets problem

CI på en bärbar dator misslyckas när ägaren sover, reser, byter nätverk, stänger locket eller behöver lokal CPU och minne. Ett lokalt register försvinner med den datorn, medan en testdatabas samlar på sig tillstånd som bara en utvecklare förstår.

Kontinuerlig integration bygger på frekvent, automatiserad verifiering som alla kan se. Martin Fowlers metoder för kontinuerlig integration betonar automatiskt självtestande byggen och synliga resultat - egenskaper som är svåra att garantera på en bärbar dator som bara är tillgänglig ibland.

Flytta en roll först efter att ha identifierat problemet den löser: köfördröjning, miljödrift, bilddistribution, gemensamt integrationstillstånd eller konkurrens om den bärbara datorns resurser.

Separera körningens förtroendegräns

Behandla CI-jobb som kodexekvering. Använd flyktiga containrar eller virtuella maskiner där det är praktiskt, undvik att montera värdens Docker-uttag i opålitliga jobb och tilldela snävt begränsade autentiseringsuppgifter per kodarkiv eller pipeline.

Begränsa arbetsyta och cache med kvoter. Ett misslyckat jobb får inte fylla serverns rotfilsystem eller läsa registeruppgifter som inte hör till projektet.

Definiera körningsetiketter efter förtroende och kapacitet. Skicka inte pull request-kod från en okänd bidragsgivare till en körning som kan nå produktionshemligheter eller hemnätverket.

Gör registret till en beständig distributionsroll

Lagra registerdata och konfiguration på beständig lagring med autentisering, TLS över opålitliga nätverksvägar, lagringsregler och tidsfönster för skräpinsamling. Separera oföränderliga utgåvetaggar från flyktiga avbildningar för grenar.

Säkerhetskopiera konfiguration, metadata och alla artefakter som inte kan byggas om. Om avbildningar kan återskapas från källan, dokumentera tiden för återskapning och bevara källan, byggdefinitionerna och externa beroenden i stället för att säkerhetskopiera varje cachelager.

Övervaka kapaciteten före rensning. Skräpinsamling i registret kan vara I/O-intensiv och kan, beroende på implementationen, kräva ett underhållsläge.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Håll testdatabaser flyktiga men representativa

Ge varje pipeline eller gren ett isolerat databasnamn, schema, container eller virtuell maskin. Initiera den från versionshanterade testdata eller en sanerad datamängd, kör migreringar automatiskt och förstör den efter lagringsperioden.

Kopiera aldrig produktionshemligheter eller oredigerade personuppgifter till testrollen. Begränsa nätverksåtkomsten så att ett komprometterat jobb inte kan ta sig från testdatabasen till orelaterade tjänster.

Bevara endast de loggar och artefakter som behövs för att diagnostisera misslyckade tester. Långlivade mystiska databaser återskapar problemet med den bärbara datorn på en större maskin.

Bygg servertopologin för det lilla teamet

Använd separata tjänstekonton, containernätverk, volymer, kvoter och säkerhetskopieringsregler för rollerna körning, register och databas. Den här guiden till NAS- och Docker-plattformar hjälper dig att avgöra om containrar eller virtuella maskiner bör tillhandahålla isoleringen.

Placera administrationsgränssnittet i ett begränsat nätverk. Exponera registret och CI-gränssnittet endast för teamet eller via ett autentiserat åtkomstlager. Dokumentera uppdateringar, ägarskap och återställning för varje tjänst.

Testa att återskapa en körning, återställa eller bygga om registret, initiera databasen på nytt, hantera ett fullt disksystem och starta om servern. Utvecklarna bör fortfarande kunna arbeta lokalt medan de gemensamma tjänsterna återställs.

Slutlig installationskontroll

Flytten är lyckad när byggen körs utan en specifik bärbar dator, miljöer återskapas från versionshanterade definitioner, registerartefakter har en plan för lagring och återställning, testdatabaser är isolerade och flyktiga och ingen körning har bredare hemligheter än vad jobbet kräver.