Vad förändras när en självhostad Git-körmiljö blir en del av en utvecklares dagliga arbetsflöde?
När en självhostad Git-körmiljö blir en del av det dagliga arbetsflödet blir den ett produktionsberoende: utvecklare blir då beroende av dess kö, verktygskedja, nätverksåtkomst, hemligheter, cache och återställningstid.
Topologin bör därför skilja styrning från körning, göra jobb tillfälliga och bara bevara det tillstånd som avsiktligt delas. En snabb, beständig körmiljö är bekväm, men dold konfigurationsdrift och omfattande autentiseringsuppgifter kan förvandla bekvämligheten till en bräcklig förtroendegräns.
Behandla körmiljön som fjärrkörning av kod
Varje godkänt jobb kör kod som styrs av kodförrådet på infrastruktur du äger. Bestäm vilka kodförråd, grenar, medverkande och pull-förfrågningshändelser som får nå körmiljön innan du kopplar till några autentiseringsuppgifter för driftsättning eller paket.
En körmiljö utformad kring mikromaskiner använder virtuella engångsmaskiner för att bibehålla prestandan hos en självhostad lösning och samtidigt minska mängden tillstånd som förs vidare mellan jobb.
Använd separata grupper av körmiljöer för betrodda releasejobb och vanliga tester. Ett arbetsflöde som utlöses offentligt eller från en fork ska inte dela körmiljö med produktionshemligheter för driftsättning.
Gå från en snabb maskin till ett kösystem
Daglig användning skapar förväntningar på upphämtningstid, samtidighet, avbrytning och prioritet. Mät köfördröjningen separat från jobbets körtid, så att ett långsamt test inte förväxlas med otillräcklig kapacitet i körmiljön.
Sätt samtidighetsgränsen under nivån där samtidiga byggen mättar minnet, lagringen eller Docker-hämtningarna. Reservera kapacitet för interaktiva jobb eller releasejobb om de inte ska behöva vänta bakom långa testmatriser.
Dokumentera utvecklarens reservlösning när körmiljön är offline: värdbaserad körning, ett lokalt kommando eller ett fördröjt jobb som inte är kritiskt. Utan en reservlösning blir underhåll ett oplanerat avbrott i utvecklingsarbetet.
Skilj återskapningsbar cache från beständigt tillstånd
| Körmiljöns tillstånd | Behålla? | Skydd |
|---|---|---|
| Utcheckad källkod | Nej | Hämta för varje jobb |
| Cache för beroenden och lager | Återskapningsbar | Kvot och skräpinsamling |
| Registrering av körmiljö | Utbytbar | Automatisk registrering |
| Byggartefakter | Enligt lagringspolicyn | Externt artefaktlager |
| Hemligheter och driftsättningsnycklar | Ja, men inte på disk | Begränsad tjänst för hemligheter |
Cachar förbättrar det dagliga arbetsflödet men måste ha en storleksgräns, en ansvarsfördelning och en regel för radering. Byggartefakter och releaseunderlag hör hemma på en extern lagringsplats med uttryckliga lagringsregler, inte i en obegränsad arbetskatalog.
Gör körmiljön möjlig att ersätta med en avbildning eller ett konfigurationsskript. Om en ominstallation av värden förstör den enda signeringsnyckeln eller det enda testresultatet, har dessa tillgångar placerats i fel roll.
Inför korrigeringar, observerbarhet och tydligt ansvar för fel
Håll koll på körmiljöns version, uppdateringar av operativsystemet, Docker- eller verktygskedjeversioner, diskanvändning, andelen misslyckade jobb, köfördröjning och cachetillväxt. Utse ett underhållsfönster och en ansvarig person även om körmiljön finns på en personlig server.
En empirisk studie av underhåll av arbetsflöden visade att automation i sig medför löpande arbete med felrättning och förbättringar av CI. Självhosting lägger till värdens livscykel i underhållsarbetet.
Skapa aviseringar för frånkopplat läge, upprepade jobbfel, fulla diskar och ovanligt långa köer. Loggarna måste visa om felet berodde på kod i arkivet, körmiljöns avbildning, nätverksåtkomst eller värden.
Testa beredskapen för det dagliga arbetsflödet
Bygg upp en körmiljö på nytt, rotera en autentiseringsuppgift för distribution, kör två byggen samtidigt, fyll och rensa cachen och koppla avsiktligt bort värden medan ett jobb körs. Bekräfta att utvecklarna kan se felet och använda reservlösningen.
Kör körmiljön på en värd när avbrott är acceptabla och jobben är betrodda. Dela upp releaser, obetrodda jobb eller maskinvaruspecifika arbetsbelastningar när de kräver andra autentiseringsuppgifter eller underhållsfönster. Guiden till operativsystem för hemmaservrar hjälper dig att anpassa värden för körmiljön för repeterbara uppdateringar och återställning.
Behandla inte längre körmiljön som en hobbytjänst när missade jobb blockerar releaser eller kundarbete. Då ska du definiera tjänsteansvar, reservkapacitet och en testad ersättningslösning, precis som för alla andra utvecklingsberoenden.
Slutregel för konfigurationen
Konfigurationen är klar när varje tjänst har en tydlig roll, skyddat tillstånd, en kontrollerad åtkomstväg, en testad återställning 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.
