CircleCI jämfört med Google Cloud Build

Att välja rätt CI/CD-verktyg för ditt projekt kan vara svårt. I det här inlägget jämför vi två managed CI/CD-tjänster – CircleCI och Google Cloud Build. Sami Alajrami hjälper oss att bedöma denna spännande CI/CD-duell.

Förr i tiden innebar Continuous Integration i teamet att du behövde installera och hantera en CI/CD-server som Jenkins eller TeamCity. Några år senare har utmaningarna med att hantera självhostade CI/CD-servrar lett till att managed CI/CD-lösningar har vuxit fram.

Leverantörer av managed CI/CD-tjänster tar hand om den operativa driften så att teamet kan fokusera på mjukvaran ni skapar. Sådana lösningar skiljer sig dock ofta åt i funktioner och prismodeller och passar inte alltid projektets behov. Det kan tvinga dig att fortsätta använda en självhostad lösning för hela eller delar av projekten. Dessutom har olika leverantörer av managed CI/CD-tjänster olika styrkor och svagheter. Det finns ingen universallösning.

Du kan läsa mer om skillnaderna mellan självhostad och managed CI/CD här.

Jämförelse

Nyligen bad en kund oss att utvärdera två managed CI/CD-tjänster: CircleCI och Google Cloud Build (GCB), för att hjälpa dem välja den lösning som bäst passar deras behov. Det här inlägget sammanfattar våra resultat.

Vi gjorde jämförelsen genom att bygga samma kundprojekt med båda CI/CD-tjänsterna och jämföra dem i projektets kontext. Projektet är en Kotlin-applikation i ett monorepo med öppen källkod, byggd med Gradle. Även om jämförelsen gjordes utifrån ett kundspecifikt projekt är resultatet ganska generellt. Vi jämförde de två tjänsterna utifrån följande faktorer:

Användargränssnittets mognad

Vinnare: CircleCI

CircleCI har funnits på marknaden länge och har därför haft tid att utveckla sitt användargränssnitt. Det ger dig enkel åtkomst till byggen och arbetsflöden samt möjlighet att se loggar för enskilda steg i dina build jobs. GCB behöver lägga mer arbete på sitt användargränssnitt.

Stöd för felsökning

Vinnare: CircleCI

I början av ett projekt är det mycket sannolikt att dina arbetsflöden och skript innehåller fel och misslyckas flera gånger innan du har finslipat dem. I sådana fall är möjligheten att felsöka arbetsflöden och jobb avgörande. CircleCI låter dig köra om ett jobb med SSH. Det innebär att du kan ansluta via SSH till den körande build-containern eller VM:n. CircleCI erbjuder dessutom ett lokalt CLI-verktyg som låter dig återskapa CircleCI-miljön lokalt, vilket är mycket användbart vid felsökning. GCB erbjuder inget stöd för felsökning.

Inbyggda notiser

Vinnare: CircleCI (men med liten marginal!)

CircleCI vinner den här kategorin eftersom tjänsten har stöd för notiser via e-post, Slack, HipChat, Flowdock, Campfire och IRC direkt från start, medan GCB inte stöder någon av dem. CircleCI-notiser är dock inte alltid användbara, se till exempel här. CircleCI har nyligen uppdaterat sina notiser. Du kan ändå behöva implementera egna anpassade notiser som en del av dina arbetsflöden, vilket även är möjligt i GCB.

Integrationer med molnleverantörer

Vinnare: Google Cloud Build

CircleCI 2.0 har inga särskilda integrationsmekanismer för specifika molnleverantörer. Det innebär att du måste ansluta till din leverantör från dina jobb på samma sätt som från vilken annan maskin som helst. Du behöver också tillhandahålla autentiseringsuppgifter.

GCB är däremot en del av Google Cloud Platform (GCP) och kan få åtkomst till olika GCP-tjänster utan att du behöver ange ytterligare autentiseringsuppgifter.

GCB vinner dock bara i vissa fall. Om du använder andra leverantörer eller inte vill bli bunden till en leverantör är den här GCB-funktionen värdelös.

Risk för inlåsning

Vinnare: Ingen av dem!

CircleCI är neutralt eftersom det fungerar på exakt samma sätt med alla molnleverantörer. Google Cloud Build är tydligt – och förståeligt nog – anpassat för Google Cloud. Det ger dig enkel integration med andra GCP-tjänster, vilket kan leda till att du bygger dina projekt kring GCP-specifika tjänster. Det kan dock vara okej att bli bunden till GCP om valet av tjänster är motiverat.

Deklarativ konfiguration

Vinnare: CircleCI

CircleCI erbjuder en mer mogen och funktionsrik deklarativ konfiguration av arbetsflöden jämfört med GCB. I CircleCI kan du till exempel konfigurera filter för anpassade byggen för specifika taggar och branches. I GCB går det att uppnå samma sak, men då måste du använda Triggers, som konfigureras i konsolgränssnittet och inte som en del av den deklarativa konfigurationen. GCB har en bra funktion som låter dig dela upp arbetsflöden i olika filer som du kan koppla till olika triggers. Det räcker dock inte för att vinna den här kategorin.

Tillgänglig build-infrastruktur

Vinnare: Ingen av dem

CircleCI stöder tre typer av executors: Docker-containrar, virtuella maskiner och macOS. Du kan köpa ytterligare beräkningsresurser för Docker-containrar, upp till 8 vCPU och 16 GB RAM.

GCB erbjuder endast Docker-containrar som executor. Däremot tillhandahåller tjänsten en virtuell maskin som kör alla dina build-containrar. Den virtuella maskinen kan använda en av två maskintyper (max 32 vCPU/28,8 GB RAM). Fördelen med att köra alla containrar på en och samma virtuella maskin är att alla jobb i Google Cloud Build körs i samma Docker-nätverk och automatiskt kan komma åt artefakter från tidigare jobb. I CircleCI måste du spara artefakter i workspace och koppla dem där de behövs. Det innebär fler rader i din CircleCI-konfiguration och kan öka körtiden beroende på hur stora dina artefakter är.

Återkoppling till GitHub

Vinnare: CircleCI

Det är viktigt att kunna se resultatet av dina byggen i GitHub checks. CircleCI har stöd för detta direkt. GCB har nyligen lanserat en alfaversion av sin Github App. Appen kan trigga byggen och ge återkoppling till GitHub. Den fungerar dock för närvarande inte med triggers. Det innebär att den är oanvändbar om du har anpassade branch- eller taggfilter konfigurerade i triggers. CircleCI stöder byggen enbart från pull requests. GCB stöder inte byggen från pull requests i forks.

Hantering av hemligheter

Vinnare: Ingen av dem

De flesta projekt behöver använda vissa hemligheter under jobb för build, test och driftsättning. Hur dessa hemligheter skickas och hanteras är viktigt, eftersom du inte vill att de ska läcka eller hamna i fel händer. Oavsett tjänst måste du anförtro dina hemligheter åt en tredje part.

CircleCI använder HashiCorp Vault för att kryptera hemligheter och lagrar dem som miljövariabler som görs tillgängliga för jobben. Risken är att CircleCI gör alla jobbloggar offentliga för publika repositories. Därför måste du vara försiktig så att du inte loggar dina hemligheter i jobben. Dessutom kan alla GitHub-användare med skrivrättigheter till repositoryt trigga en omkörning med SSH och skriva ut alla miljövariabler, inklusive hemligheter.

GCB använder Google KMS för att dekryptera hemligheter vid körning och göra dem tillgängliga som miljövariabler. Det innebär att du manuellt måste skapa en KMS-nyckel och använda den för att kryptera din hemlighet. Du lägger sedan till den krypterade hemligheten i din versionshanterade GCB-konfigurationsfil, och GCB dekrypterar den vid körning. Det är dock värt att notera att storleken på din krypterade hemlighet är begränsad till 2 MB. En json-fil för ett Google Cloud-tjänstkonto kan ofta överskrida denna gräns när den krypteras. Det innebär att du måste lagra den i en Google bucket och hämta filen vid körning, eftersom åtkomst till buckets kan ske utan autentiseringsuppgifter.

Prissättning

Vinnare: Google Cloud Build

GCB erbjuder 120 kostnadsfria build-minuter per dag och upp till 10 samtidiga byggen. Därefter debiteras du 0,003 USD per minut för standardtypen av virtuell maskin (se här för mer information). CircleCI erbjuder 1 500 build-minuter per månad och ett samtidigt jobb utan kostnad för Linux-byggen. Du debiteras 50 USD per månad för varje ytterligare parallell container. Prissättningen skiljer sig för macOS-byggen (se här för mer information).

Sammanfattning

Det är tydligt att CircleCI erbjuder en mer mogen och funktionsrik CI/CD-tjänst jämfört med det yngre Google Cloud Build. Valet av verktyg bör dock alltid utgå från projektets specifika behov. Om du till exempel redan använder flera tjänster från Google Cloud och inte har något emot de GCB-begränsningar som nämns ovan, är GCB ett rimligt val. Om GCB inte fungerar för dig just nu är det ändå värt att följa dess utveckling, även om framstegen tidigare verkar ha varit långsamma.

Men det viktigaste är att du fattar ett välgrundat beslut. Verktyget är inte lika viktigt som hur du använder det. Du bör inte välja ett verktyg och anpassa ditt arbete efter dess funktioner. Försök i stället att få verktyget att fungera för dina behov, så länge du följer beprövad praxis. Känn till dina behov och förstå verktygens kompromisser och begränsningar. Då kan du välja det verktyg som fungerar bäst för dig.