Skyen og kontinuerlig integrasjon (CI) er en naturlig kamp. Mens skyen frigjør oss fra smerten ved å installere og vedlikeholde fysiske servere, automatiserer kontinuerlig integrasjon mye av smerten ved å bygge, teste og distribuere koden vår. Hvis begge tar sikte på å ta arbeidet av skuldrene til utviklingsteamene, er det bare fornuftig å kombinere dem og eliminere enda mer sløvhet med ett trinn.
Det er mange kontinuerlige integrasjonstjenester, og de gjør alle det samme, i det minste i en abstrakt forstand. De begynner med en liste over oppgaver som kompilering eller testing som må utføres før verden kan sette pris på genialiteten i den nye programvaren. Når du bruker kodelinjene dine, begynner verktøyene å fungere gjennom sjekklisten til de kommer inn i en veisperring. Hvis det ikke er noen sperringer, er alle fornøyde.
Alle kan bruke kontinuerlig integrasjon for ethvert programvareutviklingsprosjekt, men de største fordelene nytes av team, helst store team som jobber med de samme, sammenlåsende kodeblokkene. De mest grundige implementeringene av kontinuerlig integrasjon bygger og bygger om koden før du tester og tester den, alt på jakt etter nye feil og inkompatibiliteter som kan ha blitt opprettet når forskjellige teammedlemmer sjekker inn koden. Kontinuerlige integrasjonsservere synkroniserer arbeidet til alle programmererne og hjelper teamet med å oppdage eventuelle problemer.
Noen lister over oppgaver for CI-serveren slutter med testene, men i det siste utvider stadig flere lag listene til å omfatte distribusjon av den nye koden, en prosess som noen ganger kalles "kontinuerlig distribusjon." Helt automatisert distribusjon gjør noen mennesker nervøse, og de vil ofte legge til noen manuelle pauser i prosessen. Å legge til litt ansvarlighet og menneskelig forsikring lar dem slappe av litt. De vil kalle denne hybridtilnærmingen for "kontinuerlig levering" fordi den leverer koden til noen iscenesettelses- eller testklynger der den vil vente på at et menneske skal gjøre det siste presset til produksjonen.
Hvis kontinuerlig integrasjon er bra i serverrommet nede i gangen, kan det bli enda bedre i skyen der det er store muligheter for raskere levering og større effektivitet. I de beste tilfellene kan skyene dele opp arbeidet og kjøre oppgavene parallelt. Tjenestene starter med et stort utvalg av maskinvare og deler den deretter mellom mange lag. Så lenge alle ikke skyver koden sin samtidig, vil builds og testene løpe mye raskere. Å kjøpe det samme enorme maskinvarestativet for akkurat de øyeblikkene da utviklerne vil kjøre alle testene er uoverkommelig, men hvis lagene deler stativet, kan de alle glede seg over hastighetsutbrudd.
Det er imidlertid farer og bekymringer, og den største kan være tap av kontroll. Alle skytjenestene krever at du overleverer koden din til en tredjepart, et valg som kan føles befriende for noen, men skremmende for andre. Alle skytjenestene prøver hardt å legge vekt på sikkerhet, men på en eller annen måte føles det annerledes når koden er under ditt eget tak.
I tillegg til bred støtte for alle de store språkene, dekker disse tjenestene et overraskende antall mindre og mer enn noen få virkelig rare og uvanlige. Dette er mer et resultat av gode arkitektoniske beslutninger i begynnelsen enn noen heroisk innsats fra utviklerne. Oppgavelistene er nesten alltid kodet som kommandoer for et skall eller kommandolinje, så de kontinuerlige integrasjonsverktøyene fortsetter med å utstede kommandoene til listen er oppbrukt eller noen uoverstigelig sperring vises. Noen av språkene som Java tilbyr mer sofistikerte alternativer, men for det meste kan verktøyene oppnå alt du kan gjøre med en kommandolinje.
Her er 10 forskjellige alternativer for kontinuerlig integrering i skyen.
CloudBees
CloudBees Core startet med Jenkins, det velkjente open source-prosjektet for kontinuerlig integrering, og la deretter til testing, støtte og litt forsikring om at koden bare vil kjøre. Selskapet utdelte alle eksperimentelle plugins, la til noen få egne og polerte deretter de riktige slik at de fungerer som forventet når du trenger dem.
CloudBees sysselsetter fortsatt 80 prosent av Jenkins-utviklingsteamet, og de bidrar ofte med kode til open source-prosjektet, slik at du kan være sikker på at de har god forståelse av denne dominerende plattformen. For å få fart på ting, la CloudBees også til omfattende parallellisering samt instrumentering for å spore utviklingsprosessen.
CloudBees tilbyr en rekke prispoeng som spenner fra gratis nivåer til "startpakker" for et helt år av tjenesten. Selskapet bryter også ut støtte for Jenkins for alle som trenger hjelp med verktøyet, men ikke trenger eller vil ha cloud computing.
AWS CodePipeline
Amazons verktøy for kontinuerlig integrering og distribusjon, AWS CodePipeline, er optimalisert for å levere kode til en AWS-server mens den fremdeles er åpen for mer detaljerte veier for koden og dataene dine. Det grunnleggende verktøyet tilbyr et fint utvalg av forhåndskonfigurerte bygningsmiljøer for de viktigste språkene (Java, Python, Node.js, Ruby, Go, Android, .Net Core for Linux) og dumper deretter resultatet i en S3-bøtte før du sender den av til en server for å begynne å kjøre.
Det er et overraskende stort antall lag med litt forskjellige navn. CodeBuild henter ditt siste geni fra CodeCommit når det utløses av CodePipeline og overleverer deretter resultatet til CodeDeploy. Hvis det er for mange kode ting for deg å konfigurere, kan du hoppe rett til CodeStar, som tilbyr et nytt lag med automatisering. Hvis det bare var en CodeBugEraserStar for å tørke bort alle feilene våre automatisk. Det er verdt å merke seg at du ikke teknisk betaler for noen av disse kodelagene. Amazon fakturerer deg bare for beregnings- og lagringsressursene som brukes underveis. Det er ikke akkurat gratis, selv om det føles som det.
Bitbucket-rørledninger
Atlassian, utviklerne av det populære jobbsporingsbrettet, Jira, og kodelageret, Bitbucket, bestemte seg for å utnytte grepet om arbeidsflyten vår ved å lage Bitbucket Pipelines, et kontinuerlig integrasjonsverktøy i Bitbucket-skyen. Den hemmelige sausen er mer integrering, i dette tilfellet i form av forbindelser mellom byggemekanismen og Atlassians andre verktøy. I det minste kosmetisk er ikke rørledninger engang en egen ting. Det er bare et annet menyvalg for hvert prosjekt i Bitbucket. Et annet menyalternativ peker på distribusjoner, slik at du kan velge hvor byggene ender.
Forbindelsene er en velsignelse og en begrensning. Hvis du velger en av malene som allerede er definert for de viktigste språkene (Java, JavaScript, Python, PHP, .Net, etc.), kan du bygge og distribuere koden din med noen få klikk. Men hvis du kommer bort fra standardene, begynner du å oppdage at alternativene ikke er der. Atlassian oppmuntrer til en markedsplass for apper som ser ut til å være en blanding av diagrammer og webhooks i andre tjenester. Den øverste appen på diagrammet når jeg skriver dette, vil koble Bitbucket med Jenkins, antagelig for å gjøre noe som ikke kan gjøres raskt innenfor veggene.
Hovedfordelen med rørledninger er hastighet. Atlassian har forhåndskonstruert de fleste hovedveiene fra kode til å kjøre distribusjoner, og du kan følge i selskapets fotspor for bare noen få dollar. Det er vanskelig å sammenligne kostnadene ved å bruke Bitbucket fordi buildene blir priset på få minutter, som de fleste serverløse modeller, men team dedikerer ofte en klynge av forekomster for å håndtere Jenkins-builds. Selv om du stenger dem på netter og i helgene, blir timene til.
GitLab CI / CD
En av de største konkurrentene til Atlassian er GitLab, et annet selskap som ønsker å håndtere hvert trinn i prosessen mellom fingrene og løpende distribusjon. GitLabs bygg-, test- og distribusjonsmekanismer er også koblet direkte til Git-arkivene, slik at de kan utløses ved forpliktelse. Prosessen er i stor grad bygget rundt Docker-containere, og denne cachingen kan i stor grad forenkle noe av konfigurasjonsarbeidet som må gjøres rundt Jenkins builds.
Byggeoppgavene kan målrette seg mot hvilket som helst språk, men må utløses av GitLab Runner, et autoskaleringsverktøy skrevet i Go som er klart for de fleste plattformer. Denne fleksibiliteten betyr at du kan utløse en vilkårlig jobb på andre maskiner, noe som kan være nyttig med forseggjorte arkitekturer som gjør mer enn bare å levere mikrotjenester.
Prisen er samlet sammen med de forskjellige nivåene for å tilnærme behovet. Gullnivågrupper får for eksempel alle de beste funksjonene som sikkerhetsdashboards og 50000 minutter med å bygge på den delte klyngen av maskiner. Det koster ingenting å bruke dine egne maskiner for en del av prosessen eller separate forekomster i en annen sky.
CircleCI
Mange av verktøyene for kontinuerlig integrering fokuserer på kode som kan bygges i Linux-miljøet. CircleCI bygger og leverer i Linux-verdenen, men det tilbyr også et produkt som vil bygge Android-apper og alt som kommer ut av Apples Xcode (for iOS, MacOS, tvOS eller watchOS). Hvis du jobber med et team som produserer apper for disse plattformene, kan du forplikte koden din og la CircleCI håndheve testdisiplin for alle de forskjellige geniene i teamet ditt.
Oppgavelistene er stavet i YAML-filer. CircleCI bruker Docker, i all sin flerlags herlighet, for å konfigurere testmiljøene for koden. Byggene starter med ferske beholdere, og det gjør også alle testene. Mac-arbeidet kjører i virtuelle maskiner som har en like kort levetid. Dette unngår noen av problemene med konfigurasjonen fordi de rene miljøene ikke har noen rester av biter som ligger rundt. (Så hvis problemene dine skyldes langvarig digital flam, er det din feil.)
Prissettingen er fokusert på hvor mye CPU du bygger suger ned. Antall brukere og antall arkiver er begrenset til uendelig. Antallet byggminutter og containere som gjør denne bygningen, blir imidlertid målt. Den første beholderen er gratis, og du kan kjøre en versjon i den. Hvis du vil ha mer parallellitet eller mer gjennomstrømning, får CircleCI tjene penger. Mac-brukerne får ikke den samme gratis avtalen, men det er introduksjonsplaner for alle som tester ut tjenesten.
Travis CI
Hvis byggene dine produserer kode som må testes på Windows-bokser, så tilbyr Travis CI deg et enkelt stopp. Selskapet har tilbudt MacOS og Linux-alternativer i noen tid, men har nettopp rullet ut Windows-alternativet, noe som gjør det enklere å produsere kode som kjører enda flere steder.
Oppgavelistene er også stavet i YAML og jobbene kjøres i rene virtuelle maskiner med ganske standard konfigurasjon. Linux-kode får noen grunnleggende versjoner av Ubuntu, Mac-koden kjører i en av et dusin kombinasjoner av OS X og Xcode og JDK. Windows-koden kan bare ende opp i en versjon av Windows Server (1803) for nå. Travis CI tilbyr en lang liste med 30 språk og bygge regler som er forhåndskonfigurert og ganske klar til å kjøre.
Prissettingen er basert på hvor mange samtidige jobber som kan utføres samtidig, men det er ingen formelle begrensninger på antall minutter disse byggene kan ta. Det er som om du får et fast antall dedikerte forekomster for arbeidet ditt, og de er klare hele tiden. Det er ingen gratis alternativer for proprietært arbeid, men open source-prosjekter er "alltid gratis" - så det kan være den enkleste måten å prøve Travis CI ut.
Azure Pipelines
Hvis du lurer på om det moderne Microsoft har en “Ikke oppfunnet her” -holdning, se ikke lenger enn Azure Pipelines. Salgslitteraturen sier: "Alle språk, hvilken som helst plattform." Selv om dette nesten helt sikkert er litt hyperbole, og Azure sannsynligvis ikke har mye å tilby ENIAC-programmørene, tilbyr det fremtredende Microsoft-, Linux- og MacOS-stier for koden din. Apple-hjørnet retter seg bare mot MacOS builds, ikke iOS eller tvOS eller watchOS, men la oss ikke bli kresne. Dette er et glass som er mye mer enn halvfullt.
I det abstrakte ligner systemet på de andre. Det er agenter som utfører bygg for å produsere gjenstander. Noen av disse kan være selvorganiserte hvis det alternativet hjelper. Stakken omfatter fullt ut Docker-containere, og Azure's maskinvare er klar til å kjøre dem for deg. Alle disse detaljene kan klikkes sammen med en visuell designer innebygd i en webside, eller spesifiseres med YAML hvis du foretrekker å bo i kommandolinjeverdenen.
Prissettingen kommer med en gratis “parallell jobb” med 1800 minutters byggetid. Hvis du vil ha mer parallellitet eller mer byggetid, begynner du å betale. Planen inkluderer et sjenerøst gratis nivå for open source-prosjekter, og understreker igjen Microsofts ønske om å delta i det generelle open source-fellesskapet. Men hvis Microsoft skal bruke $ 7,5 milliarder dollar på å kjøpe et sete ved bordet ved å anskaffe GitHub, vel, det gir god mening. Hvor vil all denne koden kjøre? Azure Pipelines flytter den glatt til Azure-maskinvare.
