GitHub eller GitLab: gratis CI-minuter säger inte hela kostnaden

|Författare: QUASA:s redaktion|6 min läsning
GitHub eller GitLab: gratis CI-minuter säger inte hela kostnaden

GitHub är ett rimligt val för team som vill ha kodsamarbete och vanliga bygg- och testflöden utan att drifta kodplattformen. GitLab kan vara mer intressant när pipelines behöver samordnas mellan projekt eller när teamet vill drifta plattformen självt. Valet beror därför på både abonnemanget och arbetet med körmiljöer, säkerhet och leveransflöden.

Gratis CI-minuter ger en första jämförelse, men säger inte vad en fungerande lösning kostar. Egna runners flyttar kostnaden från leverantörens körning till organisationens maskiner och drift. Ett byte av plattform kräver dessutom att behörigheter, hemligheter och beroenden mellan jobb fungerar i den nya miljön.

Kvoterna gäller olika tjänster och körmiljöer

GitHubs faktureringsregler för Actions anger 2 000 inkluderade minuter per månad för Free-organisationer och 3 000 för Team vid körning på vanliga GitHub-hostade runners i privata förråd. En Linux-runner med två kärnor kostar 0,006 dollar per minut utöver kvoten. Standardkörning för publika förråd och körning på egna runners förbrukar inte den inkluderade kvoten; större GitHub-hostade runners debiteras även när minuter finns kvar.

GitLabs pris- och villkorssida anger 400 compute-minuter per månad för GitLab.com Free och 10 000 för Premium. Premium listas till 29 dollar per användare och månad vid årsvis fakturering. Gränsen på fem användare i Free gäller privata toppnivågrupper på GitLab.com, medan egna runners inte förbrukar GitLabs compute-minuter. Sidan listar också extra kapacitet för 10 dollar per 1 000 minuter.

Det är alltså kvoter för leverantörernas körmiljöer, inte en allmän mängd kostnadsfri datorkraft. GitHub räknar minuter för den runner som utför jobbet och debiterar överskott enligt dess pris. GitLab räknar körtid på sina delade runners. Flera jobb i samma pipeline bidrar var för sig till förbrukningen, och en ändrad uppdelning av tester kan därför ändra både minuter och väntetid utan att mängden kod ändras.

Tre typteam visar vad fakturan lämnar utanför

Litet team med låg förbrukning

Anta ett team med tre utvecklare, privata förråd och 600 debiterade minuter per månad på respektive tjänsts vanliga hostade körmiljö. På GitHub Free ryms den antagna volymen inom kvoten. På GitLab.com Free överskrider den kvoten med 200 minuter, medan teamets storlek ryms inom gränsen för en privat toppnivågrupp. Teamet kan köpa mer kapacitet, minska körningen eller använda en egen runner.

En egen runner är attraktiv om organisationen redan har en lämplig miljö och någon som kan sköta den. Den behöver fortfarande resurser, uppdateringar och hantering av jobb som fastnar. För ett litet team kan den arbetstiden vara mer betydelsefull än priset på de extra minuterna. Exemplet förutsätter också att samma byggjobb går att köra med jämförbar körtid hos båda leverantörerna; det är ett räkneantagande, inte ett testresultat.

Växande team med tätare pipelines

Anta tolv utvecklare och 6 000 debiterade Linux-minuter per månad. GitHubs prislista visar Team till 4 dollar per användare och månad under de första tolv månaderna. Med 3 000 inkluderade minuter och priset för Linux-körning ovan blir den förenklade månadskalkylen 48 dollar för användarna och 18 dollar för överskjutande körning, sammanlagt 66 dollar. Lagring, säkerhetstillägg och egen drift ingår inte i beräkningen.

GitLab.com Free passar inte den antagna privata gruppen med tolv användare. Premium motsvarar 348 dollar per månad i licenser vid årsvis fakturering, och 6 000 minuter ryms inom dess angivna kvot. Skillnaden mellan 66 och 348 dollar är inte en jämförelse av likvärdiga funktionspaket eller avtalsperioder. Om teamet behöver Premium-funktioner måste deras värde vägas in; om behovet främst gäller fler minuter ger den större kvoten ensam inget tillräckligt beslutsunderlag.

Större team med krav på egen installation

Anta trettio utvecklare, 20 000 jobbminuter i månaden och ett krav på att även kodplattformen ska köras på organisationens infrastruktur. Då är GitLab Self-Managed och GitHub Enterprise Server relevanta driftformer. Molntjänsternas inkluderade minuter beskriver inte kapaciteten eller kostnaden för egna runners i en sådan installation. Licensvillkor och driftmiljö måste jämföras utifrån samma krav på tillgänglighet, åtkomst och lagring.

Här blir kostnaden för maskiner, säkerhetskopiering, uppgraderingar och beredskap en egen post vid sidan av runnerkapaciteten. Hög jobbvolym kan motivera egna runners, men kräver också planering för köer, isolering mellan jobb och åtkomst till interna system. Utan offerter och en uppskattning av den egna driftinsatsen går det inte att sätta ett trovärdigt totalpris på något av alternativen.

Pipelines kan spara eller skapa arbete

GitLabs dokumentation om nedströms pipelines beskriver både parent-child-pipelines inom ett projekt och flerprojekts-pipelines som utlöser körningar i andra projekt. Funktionerna finns även på Free-nivån. En användare som startar en körning i ett annat projekt måste ha rätt behörighet där, och den nedströms körningens status påverkar inte automatiskt den utlösande körningens status.

För ett team med många tjänster kan den modellen samla beroenden som annars behöver hanteras i egen konfiguration. Vinsten beror på hur leveranserna faktiskt hänger ihop: en pipeline som bygger flera delar i samma förråd har andra behov än en release som väntar på jobb i flera förråd. GitHub Actions har återanvändbara arbetsflöden och kan utlösa jobb mellan förråd, men ett sådant upplägg behöver bedömas utifrån behörigheter, statuskrav och mängden konfiguration som teamet ska underhålla.

Migreringens arbetskostnad uppstår när samma leveransbeteende ska återskapas på en annan plattform. Utlösare, hemligheter, återanvända steg, artefakter och regler för godkännande måste få motsvarande funktion. Särskilt vid körningar över flera projekt kan ett flöde se färdigt ut i konfigurationen men ändå ge fel resultat när åtkomst saknas eller ett nedströms jobb misslyckas.

Säkerhet och driftform ändrar jämförelsen

GitHubs licensregler för Advanced Security beskriver Secret Protection och Code Security som separata produkter. För privata förråd beräknas licensbehovet utifrån unika aktiva kodbidragsgivare i förråd där funktionerna har aktiverats. Därför påverkar valet av förråd kostnaden; antalet anställda med tillgång till organisationen ger inte ensamt rätt underlag.

GitLab listar grundläggande statisk applikationssäkerhetstestning på Free, medan Ultimate samlar fler funktioner för applikationssäkerhet och regelefterlevnad och prissätts efter kontakt med leverantören. Den relevanta jämförelsen är vilka kontroller teamet behöver i sina privata projekt och hur fynden ska hanteras. Licensen är en post, men tid för att granska resultat och hålla reglerna användbara är också arbete.

En molntjänst minskar ansvaret för själva kodplattformen. En egen installation ger kontroll över miljön och kräver samtidigt kapacitet och löpande underhåll. För ett team som ska välja mellan GitHub och GitLab blir en användbar kalkyl därför uppdelad i licenser, hostad CI-förbrukning, egna runners, säkerhetsfunktioner, plattformsdrift och migration. Det är först när de posterna avser samma driftkrav och samma leveransflöden som skillnaden mellan alternativen blir meningsfull.

Läs också:

Dela:

Prenumerera på vårt nyhetsbrev

Få de senaste nyheterna om Web3, AI och krypto direkt i din inkorg.

0