Hej, Habr! Jeg præsenterer for jer oversættelsen af artiklen forfatter Steve Mezak.
Afhængig af dit synspunkt vil DevOps fejre sin niende eller tiende årsdag i år. I 2016 blev det i RightScales rapport om tilstanden for cloud-teknologi bemærket, at 70 procent af små og mellemstore virksomheder tager DevOps-metoder til sig. Hver indikator, der indgår i denne vurdering, er siden steget. Mens DevOps forbereder sig på at indgå i sit andet årti, ville det være spændende at tage en tur ned ad memory lane og se tilbage på DevOps' rødder — og endda oprindelsen af selve navnet.
Før 2007: Den Ideelle Hændelseskæde
Før 2007 var en række omstændigheder i sidste ende med til at skabe det, vi i dag kender som DevOps.
Lean Production har allerede bevist sig som en best practice. Også kendt som Toyota Production System, sigter lean production mod at optimere processer på produktionsgulvet. (Forresten blev Toyotas ledelse oprindeligt inspireret af de originale samlebåndsmetoder præsenteret af Ford Motor Company). Løbende Forbedring — er et mantra for lean production. I praksis vurderes følgende veje løbende:
- At holde niveauet af råmaterialer og færdige produkter på et minimum. Lean production betyder det mindste mulige af råmaterialer til produktion af varer og det mindste antal færdige produkter, der venter på distribution ved ordrer eller forsendelse.
- Minimering af ordre-køer. Det er ideelt, hvis de modtagne ordrer straks overgår til færdigt status. En nøglemetrik for lean production vil altid være tiden fra ordremodtagelse til levering.
- Maksimering af effektivitet i produktionsprocessen. Omstrukturering af processer og forbedret automatisering kombineres med det formål at producere varer så hurtigt som muligt. Hvert produktionsområde på hele vejen (skæring, svejsning, montering, testning osv.) vurderes for ineffektivitet.
I IT-verdenen har traditionelle metoder baseret på vandfaldsmodellen for softwareudvikling allerede givet plads til hurtige iterative metoder, såsom AgileHastigheden var et kampråb, selvom kvaliteten nogle gange blev forringet i jagten på hurtig udvikling og implementering. På samme måde har cloud computing, især Infrastructure-as-a-Service (IaaS) og Platform-as-a-Service (PaaS) etableret sig som modne løsninger i IT-processer og infrastruktur.
Endelig er der for nylig begyndt at dukke værktøjssæt til Continous Integration (CI) op. Idéen om CI-værktøjer blev født og præsenteret af Grady Booch allerede i 1991 i hans Booch-metode.
2007-2008: En skuffet belgier
Den belgiske rådgiver, projektleder og Agile-praktiker Patrick Debois tog imod en udnævnelse fra det belgiske regeringsministerium for at hjælpe med migration af datacentre. Især arbejdede han med certifikation og parathedsvurdering. Hans opgaver krævede, at han koordinerede handlinger og byggede relationer mellem softwareudviklingsgrupper og driftsteams servere, databaser og netværk. Hans skuffelse over manglen på sammenhæng og de vægge, der adskilte udviklings- og driftsmetoder, gav ham en følelse af irritation. Stræben efter forbedring førte snart Debois til handling.
I 2008 på en Agile-konference i Toronto tilbød Andrew Shafer at moderere et særligt uformelt møde om emnet "Agile-infrastruktur". Og kun én person kom for at diskutere emnet: Patrick Debois. Deres diskussion og idéudveksling fremmede konceptet med Agile-systemadministration. Samme år etablerede Debois og Shafer en moderat vellykket gruppe for Agile Systems Administrator på Google.
2009: Sagen om samarbejde mellem Dev og Ops
På O’Reilly Velocity-konferencen præsenterede to ansatte fra Flickr, senior vice president for tekniske operationer John Allspaw og teknisk direktør Paul Hammond, den nu berømte præsentation «10 implementeringer om dagen: samarbejde mellem Dev og Ops hos Flickr».
Præsentationen var dramatisk, hvor Allspaw og Hammond spillede et kompliceret samspil mellem repræsentanter fra Development og Operations under implementeringen af software sammen med søgningen efter skyldige og gensidige beskyldninger i ånden "Det er ikke min kode, det er alt sammen dine computere!" Deres præsentation bekræftede, at den eneste fornuftige løsning er, at udviklings- og implementeringsaktiviteterne skal være glatte, gennemsigtige og fuldt integrerede. Med tiden er denne præsentation blevet legendarisk og betragtes nu som en grundlæggende milepæl, da der i IT-branchen opstod et behov for en metodologi, der i dag er kendt som DevOps.
2010: DevOps i USA
Med stigende antal støtter blev DevOpsDays-konferencen første gang afholdt i USA i Mountain View (Kalifornien) umiddelbart efter den årlige Velocity-konference. Lad os flytte os til 2018: der er planlagt over 30 DevOpsDays-konferencer, herunder flere i USA.
2013: Projekt "Phoenix"
For mange af os var et andet bemærkelsesværdigt øjeblik i DevOps-historien udgivelsen af bogen "Projekt 'Phoenix'" af Gene Kim, Kevin Behr og George Spafford. Denne roman fortæller historien om en IT-manager, der befinder sig i en håbløs situation: han får til opgave at redde et kritisk vigtigt e-handelsprojekt, der er gået galt. Den mystiske mentor til manageren — et bestyrelsesmedlem, der er begejstret for lean-metoder — giver hovedpersonen nye måder at tænke IT og softwareudvikling på, hvilket forudser DevOps-konceptet. For øvrigt inspirerede "Projekt 'Phoenix'" os til at skrive bogen "Overgå til outsourcing, ellers..." om en lignende historie fra erhvervslivet, hvor en softwarevicepræsident bruger DevOps i udviklingen af et nyt stort produkt på outsourcing.
DevOps for fremtiden
Det er værd at beskrive DevOps som en rejse eller måske en stræben snarere end som en endelig destination. DevOps, ligesom lean produktion, stræber efter konstant forbedring, øget produktivitet og effektivitet og endda konstant implementering. Automatiserede værktøjer til at understøtte DevOps fortsætter med at udvikle sig.
Der er blevet opnået meget siden skabelsen af DevOps i det sidste årti, og vi forventer at se endnu mere i 2018 og i fremtiden.
Kilde: habr.com
