CI / CD som en tjänst: 10 verktyg för kontinuerlig integration och leverans i molnet

Molnet och kontinuerlig integration (CI) är en naturlig matchning. Medan molnet frigör oss från smärtan med att installera och underhålla fysiska servrar, automatiserar kontinuerlig integration mycket av smärtan med att bygga, testa och distribuera vår kod. Om båda syftar till att ta bort arbetet från utvecklingslagens axlar, är det bara meningsfullt att kombinera dem och eliminera ännu mer slitage med ett steg.

Det finns många kontinuerliga integrationstjänster och de gör alla samma sak, åtminstone i en abstrakt mening. De börjar med en lista över uppgifter som att sammanställa eller testa som måste utföras innan världen kan uppskatta genialiteten i din nya programvara. När du begår dina kodrader börjar verktygen arbeta igenom checklistan tills de stöter på en vägspärr. Om det inte finns några spärrar är alla nöjda.

Vem som helst kan använda kontinuerlig integration för alla programutvecklingsprojekt, men de största fördelarna åtnjuts av team, helst stora team som arbetar med samma, sammankopplade kodblock. De mest grundliga implementeringarna av kontinuerlig integration bygger och bygger om koden innan de testas och testas igen, allt på jakt efter nya fel och inkompatibiliteter som kan ha skapats när olika teammedlemmar checkar in sin kod. Kontinuerliga integrationsservrar synkroniserar alla programmerares arbete och hjälper teamet att upptäcka eventuella problem. 

Några listor över uppgifter för CI-servern slutar med testerna, men på senare tid utökar fler och fler team listorna till att omfatta distribution av den nya koden, en process som ibland kallas "kontinuerlig distribution". Helt automatiserad distribution gör vissa människor nervösa och de lägger ofta till några manuella pauser i processen. Genom att lägga till lite ansvar och mänsklig försäkran kan de slappna av lite. De kommer att kalla denna hybridstrategi "kontinuerlig leverans" eftersom den levererar koden till något iscensättnings- eller testkluster där den väntar på att en människa ska göra det sista steget till produktion. 

Om kontinuerlig integration är bra i serverrummet i korridoren kan det bli ännu bättre i molnet där det finns stora möjligheter för snabbare leverans och större effektivitet. I bästa fall kan molnen dela upp arbetet och köra uppgifterna parallellt. Tjänsterna börjar med en stor pool av hårdvara och delar sedan den bland många lag. Så länge som alla inte trycker på sin kod samtidigt kommer builds och test att gå mycket snabbare. Att köpa samma enorma hårdvaruhylla för just de ögonblick när utvecklarna vill köra alla tester är oöverkomligt, men om lagen delar racket kan de alla njuta av hastigheten.

Det finns dock faror och bekymmer, och den största kan vara förlust av kontroll. Alla molntjänster kräver att du överlämnar din kod till en tredje part, ett val som kan kännas befriande för vissa men skrämmande för andra. Alla molntjänster försöker hårt betona säkerhet, men på något sätt känns det annorlunda när koden är under ditt eget tak.

Förutom ett brett stöd för alla större språk, omfattar dessa tjänster ett överraskande antal mindre och mer än några verkligt konstiga och ovanliga. Detta är mer resultatet av bra arkitektoniska beslut i början än någon hjälteinsats från utvecklarna. Listorna över uppgifter är nästan alltid kodade som kommandon för ett skal eller kommandorad, så de kontinuerliga integrationsverktygen utfärdar ganska mycket kommandona tills listan är uttömd eller någon oöverstiglig vägspärr visas. Några av språken som Java erbjuder mer sofistikerade alternativ men för det mesta kan verktygen åstadkomma allt du kan göra med en kommandorad. 

Här är tio olika alternativ för kontinuerlig integration i molnet.

CloudBees

CloudBees Core började med Jenkins, det välkända öppen källkodsprojektet för kontinuerlig integration, sedan lagt till test, support och viss försäkran om att koden bara kommer att köras. Företaget utdelade alla experimentella plugins, lade till några egna och polerade sedan de rätta så att de fungerar som förväntat när du behöver dem.

CloudBees sysselsätter fortfarande 80 procent av Jenkins utvecklingsteam och de bidrar ofta med kod till open source-projektet, så du kan vara säker på att de har en god förståelse för den här dominerande plattformen. För att påskynda saker har CloudBees också lagt till omfattande parallellisering samt instrument för att spåra din utvecklingsprocess.

CloudBees erbjuder en mängd olika prispunkter som sträcker sig från gratis nivåer till "startpaket" under ett helt år av tjänsten. Företaget bryter också ut stöd för Jenkins för alla som behöver hjälp med verktyget men inte behöver eller vill ha cloud computing.

AWS CodePipeline

Amazons verktyg för kontinuerlig integration och distribution, AWS CodePipeline, är optimerat för att leverera kod till en AWS-server medan den fortfarande är öppen för mer detaljerade vägar för din kod och data. Grundverktyget erbjuder ett bra urval av förkonfigurerade byggmiljöer för de större språken (Java, Python, Node.js, Ruby, Go, Android, .Net Core för Linux) och dumpar sedan resultatet i en S3-hink innan den skickas av till en server för att börja köra.

Det finns ett överraskande stort antal lager med lite olika namn. CodeBuild hämtar ditt senaste geni från CodeCommit när det utlöses av CodePipeline och överlämnar sedan resultatet till CodeDeploy. Om det är för många kodsaker för dig att konfigurera kan du hoppa direkt till CodeStar, som erbjuder ytterligare ett automatiseringsskikt. Om det bara fanns en CodeBugEraserStar för att torka bort alla våra misstag automatiskt också. Det är värt att notera att du inte tekniskt betalar för något av dessa kodlager. Amazon fakturerar dig bara för de beräknings- och lagringsresurser som används längs vägen. Det är inte helt gratis, även om det känns som det.

Bitbucket-rörledningar

Atlassian, utvecklarna av det populära jobbspårningskortet, Jira och kodförvaret, Bitbucket, bestämde sig för att utnyttja sitt grepp om vårt arbetsflöde genom att skapa Bitbucket Pipelines, ett kontinuerligt integrationsverktyg i Bitbucket-molnet. Den hemliga såsen är mer integration, i detta fall i form av kopplingar mellan byggmekanismen och Atlassians andra verktyg. Åtminstone kosmetiskt är rörledningar inte ens en separat sak. Det är bara ett menyalternativ för varje projekt i Bitbucket. Ett annat menyalternativ pekar på distributioner, så att du kan välja var byggningarna hamnar.

Kopplingarna är en välsignelse och en begränsning. Om du väljer en av mallarna som redan har definierats för de större språken (Java, JavaScript, Python, PHP, .Net, etc.) kan du bygga och distribuera din kod med några få klick. Men om du glider bort från standarderna börjar du upptäcka att alternativen inte finns där. Atlassian uppmuntrar en marknadsplats för appar som verkar vara en blandning av diagram och webbkrokar till andra tjänster. Den översta appen på diagrammet när jag skriver detta kommer att ansluta Bitbucket med Jenkins, förmodligen för att göra något som inte kan göras snabbt inuti väggarna.

Den principiella fördelen med rörledningar är hastighet. Atlassian har förkonstruerat de flesta av de viktigaste vägarna från kod till igång distribution och du kan följa företagets fotspår för bara några dollar. Det är svårt att jämföra kostnaden för att använda Bitbucket eftersom builds prissätts på några minuter, som de flesta serverlösa modeller, men team dedikerar ofta ett kluster av instanser för att hantera Jenkins builds. Även om du stänger av dem på nätter och helger, ökar timmarna.

GitLab CI / CD

En av de största konkurrenterna till Atlassian är GitLab, ett annat företag som vill hantera varje steg i processen mellan dina fingrar och igång distribution. GitLabs bygg-, test- och distributionsmekanismer är också anslutna direkt till dess Git-arkiv så att de kan utlösas vid engagemang. Processen är till stor del uppbyggd kring Docker-behållare och denna caching kan i hög grad förenkla en del av konfigurationsarbetet som måste göras kring Jenkins-byggnader.

Bygguppgifterna kan rikta sig till vilket språk som helst men måste utlösas av GitLab Runner, ett autoskalningsverktyg skrivet i Go som är klart för de flesta plattformar. Denna flexibilitet innebär att du kan utlösa alla slumpmässiga jobb på andra maskiner, något som kan vara användbart med detaljerade arkitekturer som gör mer än att bara leverera mikrotjänster.

Prissättningen ingår i de olika nivåerna för att uppskatta behovet. Guldnivågrupper, till exempel, får alla de bästa funktionerna som säkerhetsinstrumentpaneler och 50 000 minuters byggnad på det delade maskineriet. Det finns ingen kostnad för att använda dina egna maskiner för en del av processen eller separata instanser i något annat moln.

CircleCI

Många av de kontinuerliga integrationsverktygen fokuserar på kod som kan byggas i Linux-miljön. CircleCI bygger och levererar i Linux-världen, men det erbjuder också en produkt som bygger Android-appar och allt som kommer ut från Apples Xcode (för iOS, MacOS, tvOS eller watchOS). Om du arbetar i ett team som producerar appar för dessa plattformar kan du begå din kod och låta CircleCI genomdriva några testdisciplin för alla teamets olika genier.

Listorna över uppgifter stavas i YAML-filer. CircleCI använder Docker, i all sin flerskiktiga ära, för att konfigurera testmiljöerna för koden. Byggen börjar med färska behållare och så gör alla tester. Mac-arbetet körs i virtuella maskiner som har en lika kort livslängd. Detta undviker några av problemen med konfigurationen eftersom de rena miljöerna inte har några kvarvarande bitar som ligger kvar. (Så om dina problem orsakas av kvarvarande digital flotsam, ja, det är ditt fel.)

Prissättningen är fokuserad på hur mycket CPU dina byggnader suger ner. Antalet användare och antalet förvar är begränsade till oändlighet. Antalet byggminuter och containrar som gör den här byggnaden mäts dock. Den första behållaren är gratis och du kan köra en byggnad i den. Om du vill ha mer parallellitet eller mer genomströmning får CircleCI tjäna lite pengar. Mac-användare får inte samma gratisavtal, men det finns introduktionsplaner för alla som testar tjänsten.

Travis CI

Om dina konstruktioner producerar kod som måste testas i Windows-rutor, erbjuder Travis CI dig ett enda stopp. Företaget har erbjudit MacOS och Linux-alternativ under en tid men har just rullat ut Windows-alternativet, vilket gör det enklare att producera kod som körs på ännu fler platser.

Uppgiftslistorna stavas också i YAML och jobben körs i rena virtuella maskiner med ganska standardkonfiguration. Linux-kod får några grundläggande versioner av Ubuntu, Mac-koden körs i en av ett dussin kombinationer av OS X och Xcode och JDK. Windows-koden kan bara hamna i en version av Windows Server (1803) för tillfället. Travis CI erbjuder en lång lista med 30 språk och byggregler som är förkonfigurerade och ganska redo att köras.

Prissättningen baseras på hur många samtidiga jobb som kan utföras samtidigt men det finns inga formella gränser för hur många minuter dessa byggnader kan ta upp. Det är som att du får ett fast antal dedikerade instanser för ditt arbete och de är redo hela tiden. Det finns inga kostnadsfria alternativ för eget arbete, men open source-projekt är "alltid gratis" - så det kan vara det enklaste sättet att prova Travis CI.

Azure Pipelines

Om du undrar om det moderna Microsoft har en "Inte uppfunnit här" attityd, leta inte längre än Azure Pipelines. Försäljningslitteraturen säger, "Vilket språk som helst, vilken plattform som helst." Även om detta nästan säkert är lite hyperbole och Azure förmodligen inte har mycket att erbjuda ENIAC-programmerarna, erbjuder det framträdande Microsoft-, Linux- och MacOS-banor för din kod. Apple-hörnet riktar sig bara mot MacOS-byggnader, inte iOS eller tvOS eller watchOS, men låt oss inte bli kräsen. Detta är ett glas som är mycket mer än halvfullt.

Sammanfattningsvis liknar systemet de andra. Det finns agenter som utför byggnader för att producera artefakter. Några av dessa kan vara självvärd om det alternativet hjälper. Stapeln omfattar helt Docker-behållare och Azures hårdvara är redo att köra dem åt dig. Alla dessa detaljer kan klickas tillsammans med en visuell designer inbyggd på en webbsida eller specificeras med YAML om du föredrar att bo i kommandoraden.

Prissättningen kommer med ett gratis "parallellt jobb" med 1800 minuters byggtid. Om du vill ha mer parallellitet eller mer byggd tid börjar du betala. Planen innehåller en generös gratis nivå för öppen källkodsprojekt, vilket återigen betonar Microsofts önskan att delta i det allmänna open source-samhället. Men om Microsoft ska spendera 7,5 miljarder dollar för att köpa en plats vid bordet genom att förvärva GitHub, ja, det är mycket meningsfullt. Var kommer all denna kod att köras? Azure Pipelines flyttar gärna det smidigt till Azure-hårdvara.