DevOps er et sæt koncepter og en måde at arbejde på, der stammer fra Agile og Lean tilgang til operationer. Det vedrører softwareudviklingsteams (Dev) og informationsteknologiske operationer (Ops), der arbejder sammen om at forbedre produktiviteten, automatisere infrastruktur og kontinuerligt måle applikationsydelse. Dette er alt for at levere flere softwareløsninger på en kortere periode.
DevOps har også modtaget en akademisk definition fra tre datalogiforskere, der arbejder på Amerikansk forsknings- og udviklingscenter i Pennsylvania og Commonwealths videnskabelige og industrielle forskningsorganisation. Len bas, Dr. Ingo Weberog Dr. Liming Zhu har defineret det som et ”sæt praksis, der har til formål at reducere tiden mellem at begå en ændring af et system og ændringen placeres i normal produktion, samtidig med at der sikres høj kvalitet.”
Udviklere og systemadministratorer arbejder sammen gennem alle faser af udviklingscyklussen. Dette inkluderer den faktiske skrivning af koden, test og produktionsstøtte.
For bedre at forstå forskellene, som denne tilgang bringer til bordet, lad os se på, hvad en normal udviklingscyklus betyder, fra den faktiske kodeskrivning til testning, implementering og produktion. Derefter ser vi på, hvordan denne proces effektivt transformeres gennem en DevOps-måde at arbejde på og snakker lidt om de vigtigste principper historien bag DevOps.
Softwareudviklingssiden af kodning
Softwarevirksomheder kører med hinanden for at komme med nye og spændende produkter eller opdateringer til deres kunder. Softwaren starter med en udvikler eller et helt team, der skriver koden til nye produkter, funktioner, opdateringer, fejlrettelser osv. I et ikke-DevOps-arbejdsmiljø ved udvikleren ikke, om koden fungerer, før den er sat i produktion.
Det tager dog uger, før koden går i produktion. Mellem den tid skal de også tage sig af det næste parti koder på forhånd, mens de også har den afventende kode bagest i deres sind.
Også interessant: DevOps og IT-projekter i den virkelige verden
Når en stor del af koden til sidst implementeres i produktionsmiljøet, kan der lejlighedsvis opstå fejl. Dette betyder, at udviklere er nødt til at stoppe, hvad de arbejder på, og komme tilbage den kode, de havde skrevet for et par uger siden for at finjustere den, så der ikke ville opstå fejl.
Hvorfor fejlene i første omgang? Det skyldes for det meste, at udviklingsmiljøet er noget andet end produktionsmiljøet.
IT-driftssiden af kodning
Driftsteamet er ansvarligt for at opretholde produktionsmiljøet. Det oversættes til snesevis af servere, de har brug for at administrere korrekt. Dette er, så kunder og forbrugere aldrig bliver lukket ud af deres yndlingsprodukter og software.
Når de ikke beskæftiger sig med serverproblemer, sørger operationsteamet for at implementere ny kode i dette produktionsmiljø. Normalt går tingene ikke glat, og der skal laves lidt tinkering for at koden passer ordentligt ind i miljøet. Dette er grunden til, at kodeudrulning normalt er planlagt til at ske en eller to gange om måneden.
Når koden er implementeret, er det operationsteamets ansvar at sikre, at der ikke er fejl, og at løse dem, hvis der er sådanne. I denne fase kan et operationsteammedlem føle sig lidt frustreret over, at udviklerne lige har kastet en masse kode, og nu skal de håndtere det og dets mange problemer.
Folk spurgte sig selv, hvordan de skulle placere disse to hold i samme rum og lade dem arbejde bedre sammen. Hvordan får vi dem til at lære at tænke ens og nedbryde misforståelser i hinandens miljøer og dele deres ansvar? Det er her, DevOps-ideen skete.
Indtast DevOps-teamet
Den første store forudsætning for, at ethvert DevOps-team kan arbejde ordentligt, er et lille skift i tankegangen. De ville arbejde sammen for at automatisere infrastruktur, automatisere arbejdsgange og måle applikationspræstationer sammen. Dette er for at forbedre den samlede produktivitet og effektivitet i hele udviklingscyklussen.
Et DevOps-team begynder først at fokusere på automatisering fra kodetest til arbejdsgange og infrastruktur. Deres arbejdsgang vil ændre sig. Udviklerne skriver ikke en stor pose kode og afleverer den derefter mere til driftsteamet. De vil skrive små bits kode, og disse bits implementeres samme dag eller den næste.
De vil rette alle bugs sammen. Hvis koden er skrevet i små stykker, kan den bruges ofte. Dette vil forbedre produktiviteten og effektiviteten i hele afdelingen.
En ting er klart: Et DevOps-team er bedre rustet til at imødekomme markedets behov og levere produkter i større skala. I stedet for at oprette software og konfigurere infrastruktur manuelt fungerer de i henhold til en konfigurationsadministrationskode, der beskriver, hvordan alt skal bygges. En større ændring, som et DevOps-team bliver nødt til at arbejde med, er implementering og vedtagelse af en disciplin af applikationspræstationsovervågning og -optimering i næsten realtid.
Historien om DevOps
Vi kan kalde DevOps et adopteret barn af Agile System Administration-bevægelsen og også et barnebarn af Enterprise Systems Management-bevægelsen (ESM). ESM blev berømmet i midten af 2000'erne, og siden da opstod der en masse konferencer og bootlejre og fyre, der talte om en bedre udviklingsproces.
Den første Velocity-konference skete i 2008, og det hele handlede om webpræstation og bedste praksis for operationer. Dette fulgte forskellige vigtige eksempler på samarbejdspartnere mellem udvikler og drift af, hvordan en sikrere og hurtig udviklingscyklus kunne indføres. Flere fagfolk begyndte at tænke over dette nye koncept, og hvordan de kunne implementere det i deres arbejdsgang.
I 2009 blev den første konference navngivet DevOpsdays fandt sted i Belgien. En smidig praktiker og projektleder, Patrick Debois, grundlagde konferencen. I 2012 havde vi den første State of DevOps-rapport, udtænkt og lanceret af alanna brun fra Marionet. Mere fulgte, og DevOps-vedtagelsen begyndte en rigtig ting.
Værktøjer, der er nødvendige for at implementere DevOps
DevOps-metoden kan ikke anvendes uden et sæt værktøjer, der hjælper med at automatisere og overvåge den tværfunktionelle arbejdsgang samt hjælpe den endelige levering af software. På “DevOps-sprog” kaldes disse værktøjer “værktøjskæder. ” Der er syv hovedkategorier af værktøjskæder derude:
- Kodeudviklingsværktøjer
- Bygge værktøjer til kontinuerlig integration af ny kode og til opretholdelse af byggestatus (f.eks Jenkins, Gitlab, Bitbucket)
- Testværktøjer
- Emballage værktøjer
- Slip automatiseringsværktøjer
- Konfiguration af værktøjer, der hjælper med konfiguration og styring af infrastruktur (sådanne værktøjer er terraform, Ansible, Marionet)
- Overvågningsværktøjer, der hjælper med at spore applikationsydelse og slutbrugeroplevelse.
Samlet set er DevOps et sæt praksis og metode, der fremmer samarbejde mellem udviklere og operationer. Dette hjælper med at innovere hurtigere, være mere lydhør over for enhver forretnings- og markedsbehov, til at samarbejde bedre og frigive hyppigere funktioner og ny kode. DevOps starter med en ny tankegang, en helt ny flok værktøjer og noget færdighedspolering i midten.
Fotokredit: Funktionen foto er taget af Dette er Engineering RAEng.
kilde: Len bas, Dr. Ingo Weberog Dr. Liming Zhu (DevOps: En softwarearkitters perspektiv)
