Cloud og kontinuerlig integration (CI) er en naturlig match. Mens skyen frigør os fra smerten ved at installere og vedligeholde fysiske servere, automatiserer kontinuerlig integration meget af smerten ved at opbygge, teste og implementere vores kode. Hvis begge sigter mod at fjerne arbejdet fra udviklingsholdets skuldre, er det kun fornuftigt at kombinere dem og eliminere endnu mere udmattelse med et trin.
Der er mange kontinuerlige integrationstjenester, og de gør alle meget det samme, i det mindste i en abstrakt forstand. De begynder med en liste over opgaver som kompilering eller test, der skal udføres, før verden kan sætte pris på genialiteten i din nye software. Når du begår dine kodelinjer, begynder værktøjerne at arbejde gennem tjeklisten, indtil de løber ind i en vejspærring. Hvis der ikke er nogen spærringer, er alle glade.
Alle kan bruge kontinuerlig integration til ethvert softwareudviklingsprojekt, men de største fordele nyder holdene, fortrinsvis store hold, der arbejder på de samme, sammenlåsende kodeblokke. De mest grundige implementeringer af kontinuerlig integration bygger og genopbygger koden inden test og gentestning, alt sammen på jagt efter nye fejl og inkompatibiliteter, der kan være oprettet, når forskellige teammedlemmer tjekker deres kode. Kontinuerlige integrationsservere synkroniserer alle programmørernes arbejde og hjælper teamet med at opdage eventuelle problemer.
Nogle lister over opgaver til CI-serveren slutter med testene, men i det seneste udvider flere og flere hold listerne til at omfatte implementering af den nye kode, en proces, der undertiden kaldes "kontinuerlig implementering." Helt automatiseret implementering gør nogle mennesker nervøse, og de vil ofte tilføje nogle manuelle pauser i processen. Tilføjelse af lidt ansvarlighed og menneskelig sikkerhed lader dem slappe af lidt. De vil kalde denne hybrid tilgang "kontinuerlig levering", fordi den leverer koden til en eller anden iscenesættelses- eller testklynge, hvor den venter på, at et menneske gør det sidste skub til produktionen.
Hvis kontinuerlig integration er god i serverrummet nede i hallen, kan det være endnu bedre i skyen, hvor der er store muligheder for hurtigere levering og større effektivitet. I de bedste tilfælde kan skyerne opdele arbejdet og køre opgaverne parallelt. Tjenesterne starter med en stor pulje af hardware og deler den derefter blandt mange hold. Så længe alle ikke skubber deres kode på samme tid, kører builds og test meget hurtigere. At købe det samme enorme rack hardware til netop de øjeblikke, hvor udviklerne ønsker at køre alle testene er uoverkommelige, men hvis holdene deler racket, kan de alle nyde hastighedsudbruddene.
Der er dog farer og bekymringer, og det største kan være tab af kontrol. Alle cloudtjenester kræver overdragelse af din kode til en tredjepart, et valg, der måske føles befriende for nogle, men skræmmende for andre. Alle cloudtjenesterne prøver hårdt på at understrege sikkerheden, men på en eller anden måde føles det anderledes, når koden er under dit eget tag.
Ud over bred støtte til alle de store sprog dækker disse tjenester et overraskende antal mindre og mere end et par virkelig mærkelige og usædvanlige. Dette er mere et resultat af gode arkitektoniske beslutninger i starten end nogen heroisk indsats fra udviklerne. Listerne over opgaver er næsten altid kodet som kommandoer til en eller anden skal eller kommandolinje, så de kontinuerlige integrationsværktøjer udsender stort set kommandoerne, indtil listen er opbrugt, eller der vises en uoverstigelig vejspærring. Nogle af sprogene som Java tilbyder mere sofistikerede muligheder, men for det meste kan værktøjerne udrette alt, hvad du kan gøre med en kommandolinje.
Her er 10 forskellige muligheder for kontinuerlig integration i skyen.
CloudBees
CloudBees Core startede med Jenkins, det velkendte open source-projekt til kontinuerlig integration, tilføjede derefter test, support og en vis sikkerhed for, at koden bare vil køre. Virksomheden udrullede alle de eksperimentelle plugins, tilføjede nogle få af deres egne og polerede derefter de rigtige, så de fungerer som forventet, når du har brug for dem.
CloudBees beskæftiger stadig 80 procent af Jenkins-udviklingsteamet, og de bidrager ofte med kode til open source-projektet, så du kan være sikker på, at de har en god forståelse af denne dominerende platform. For at fremskynde tingene tilføjede CloudBees også omfattende parallelisering samt instrumentering til at spore din udviklingsproces.
CloudBees tilbyder en række prispoint, der spænder fra gratis niveauer til "startpakker" i et helt år af tjenesten. Virksomheden bryder også support til Jenkins til alle, der har brug for hjælp til værktøjet, men ikke har brug for eller ønsker cloud computing.
AWS CodePipeline
Amazons værktøj til kontinuerlig integration og implementering, AWS CodePipeline, er optimeret til at levere kode til en AWS-server, mens den stadig er åben for mere detaljerede stier til din kode og data. Grundværktøjet tilbyder et godt udvalg af forudkonfigurerede byggemiljøer til de største sprog (Java, Python, Node.js, Ruby, Go, Android, .Net Core til Linux) og dumper derefter resultatet i en S3-spand, inden den sendes ud til en server for at begynde at køre.
Der er et overraskende stort antal lag med lidt forskellige navne. CodeBuild griber dit seneste geni fra CodeCommit, når det udløses af CodePipeline, og afleverer derefter resultatet til CodeDeploy. Hvis der er for mange kode ting til dig at konfigurere, kan du hoppe lige til CodeStar, som tilbyder et andet lag af automatisering. Hvis der kun var en CodeBugEraserStar, der også slettede alle vores fejl automatisk. Det er værd at bemærke, at du ikke teknisk betaler for nogen af disse kodelag. Amazon fakturerer dig kun for de beregnings- og lagerressourcer, der bruges undervejs. Det er ikke ligefrem gratis, selvom det føles som det.
Bitbucket-rørledninger
Atlassian, udviklerne af det populære jobsporingskort, Jira og kodelageret, Bitbucket, besluttede at udnytte deres greb om vores arbejdsgang ved at oprette Bitbucket Pipelines, et kontinuerligt integrationsværktøj i Bitbucket-skyen. Den hemmelige sauce er mere integration, i dette tilfælde i form af forbindelser mellem byggemekanismen og Atlassian's andre værktøjer. I det mindste kosmetisk er rørledninger ikke engang en separat ting. Det er bare en anden menupunkt for hvert projekt i Bitbucket. En anden menupunkt peger på implementeringer, så du kan vælge, hvor buildene ender.
Forbindelserne er en velsignelse og en begrænsning. Hvis du vælger en af de skabeloner, der allerede er defineret til de store sprog (Java, JavaScript, Python, PHP, .Net osv.), Kan du opbygge og implementere din kode med et par klik. Men hvis du glider væk fra standarderne, begynder du at finde ud af, at mulighederne ikke er der. Atlassian opmuntrer ikke en markedsplads for apps, der ser ud til at være en blanding af diagrammer og webhooks i andre tjenester. Den øverste app på diagrammet, når jeg skriver dette, forbinder Bitbucket med Jenkins, formodentlig for at gøre noget, der ikke kan gøres hurtigt inde i væggene.
Den primære fordel ved rørledninger er hastighed. Atlassian har forudkonstrueret de fleste af de store veje fra kode til kørende implementeringer, og du kan følge i virksomhedens fodspor for blot et par dollars. Det er svært at sammenligne omkostningerne ved at bruge Bitbucket, fordi builds er prissat på få minutter, som de fleste serverløse modeller, men hold dedikerer ofte en klynge af forekomster til at håndtere Jenkins builds. Selvom du lukker dem om nætter og weekender, tilføjes timerne.
GitLab CI / CD
En af de største konkurrenter til Atlassian er GitLab, et andet firma, der ønsker at håndtere hvert trin i processen mellem dine fingre og køre implementering. GitLabs opbygnings-, test- og implementeringsmekanismer er ligeledes forbundet direkte til dets Git-arkiver, så de kan udløses efter forpligtelse. Processen er stort set bygget op omkring Docker-containere, og denne caching kan i høj grad forenkle noget af det konfigurationsarbejde, der skal udføres omkring Jenkins builds.
Byggeopgaverne kan målrette mod ethvert sprog, men skal udløses af GitLab Runner, et autoskalningsværktøj skrevet i Go, der er klar til de fleste platforme. Denne fleksibilitet betyder, at du kan udløse ethvert tilfældigt job på andre maskiner, noget der kan være nyttigt med detaljerede arkitekturer, der gør mere end bare at levere mikrotjenester.
Prissætningen er samlet med de forskellige niveauer for at tilnærme behovet. Guldgrupper får for eksempel alle de bedste funktioner som sikkerhedsdashboards og 50.000 minutters bygning på den delte klynge af maskiner. Der er ingen omkostninger for at bruge dine egne maskiner til en del af processen eller separate forekomster i en anden sky.
CircleCI
Mange af de kontinuerlige integrationsværktøjer fokuserer på kode, der kan bygges i Linux-miljøet. CircleCI bygger og leverer i Linux-verdenen, men det tilbyder også et produkt, der bygger Android-apps og alt, hvad der kommer ud af Apples Xcode (til iOS, MacOS, tvOS eller watchOS). Hvis du arbejder på et team, der producerer apps til disse platforme, kan du begå din kode og lade CircleCI håndhæve nogle testdiscipliner for hele dit teams forskellige geni.
Listerne over opgaver er stavet i YAML-filer. CircleCI bruger Docker i al sin flerlags herlighed til at konfigurere testmiljøerne til koden. Bygningerne starter med friske containere, og det samme gør alle testene. Mac-arbejdet kører i virtuelle maskiner, der har en tilsvarende kort levetid. Dette undgår nogle af problemerne med konfiguration, fordi de rene miljøer ikke har nogen resterende bit liggende. (Så hvis dine problemer skyldes langvarig digital flotsam, så er det din skyld.)
Prissætningen er fokuseret på, hvor meget CPU dine bygninger suger ned. Antallet af brugere og antallet af arkiver er begrænset til uendelig. Antallet af byggeminutter og containere, der udfører denne bygning, måles dog. Den første container er gratis, og du kan køre en build i den. Hvis du vil have mere parallelitet eller mere gennemstrømning, får CircleCI nogle penge. Mac-brugerne får ikke den samme gratis aftale, men der er introduktionsplaner for alle, der tester tjenesten.
Travis CI
Hvis dine builds producerer kode, der skal testes på Windows-kasser, tilbyder Travis CI dig et enkelt stop. Virksomheden har i nogen tid tilbudt MacOS og Linux, men har lige rullet Windows-indstillingen ud, hvilket gør det nemmere at producere kode, der kører endnu flere steder.
Opgavelisterne er også stavet i YAML, og jobene køres på rene virtuelle maskiner med ret standardkonfiguration. Linux-kode får nogle grundlæggende versioner af Ubuntu, Mac-koden kører i en af et dusin kombinationer af OS X og Xcode og JDK. Windows-koden kan kun ende i en version af Windows Server (1803) indtil videre. Travis CI tilbyder en lang liste på 30 sprog og byggeregler, der er forudkonfigurerede og stort set klar til at køre.
Prissætningen er baseret på hvor mange samtidige job der kan udføres på én gang, men der er ingen formelle begrænsninger for antallet af minutter, som disse builds kan tage op. Det er som om du får et fast antal dedikerede forekomster til dit arbejde, og de er klar hele tiden. Der er ingen gratis muligheder for proprietært arbejde, men open source-projekter er "altid gratis" - så det kan være den enkleste måde at prøve Travis CI på.
Azure-rørledninger
Hvis du spekulerer på, om det moderne Microsoft har en “Ikke opfundet her” holdning, skal du ikke se længere end Azure Pipelines. Salgslitteraturen siger: "Ethvert sprog, enhver platform." Selv om dette næsten helt sikkert er en smule hyperbole, og Azure sandsynligvis ikke har meget at tilbyde ENIAC-programmørerne, tilbyder det tydeligt Microsoft, Linux og MacOS-stier til din kode. Apple-hjørnet er kun målrettet mod MacOS-builds, ikke iOS eller tvOS eller watchOS, men lad os ikke blive kræsne. Dette er et glas, der er meget mere end halvt fyldt.
I det abstrakte svarer systemet til de andre. Der er agenter, der udfører byggerier for at producere artefakter. Nogle af disse kan være selvhostede, hvis denne mulighed hjælper. Stakken omfatter fuldt ud Docker-containere, og Azure's hardware er klar til at køre dem for dig. Alle disse detaljer kan klikkes sammen med en visuel designer indbygget i en webside eller specificeres med YAML, hvis du foretrækker at bo i kommandolinjens verden.
Prissætningen leveres med et gratis "paralleljob" med 1800 minutters byggetid. Hvis du vil have mere parallelitet eller mere byggetid, begynder du at betale. Planen inkluderer et generøst gratis niveau for open source-projekter, der igen understreger Microsofts ønske om at deltage i det generelle open source-samfund. Men hvis Microsoft vil bruge 7,5 milliarder dollars til at købe et sæde ved bordet ved at erhverve GitHub, ja, det giver masser af mening. Hvor kører al denne kode? Azure Pipelines flytter det glat til Azure-hardware.
