Hei, Habr! Jeg presenterer for deg oversettelsen av artikkelen «Opprinnelsene til DevOps: Hva er i et navn?» forfatter Steve Mezak.

Avhengig av ditt synspunkt, feirer DevOps sitt niende eller tiende jubileum i år. I 2016 ble det i RightScales rapport om tilstanden til skyene rapportert at 70 prosent av små og mellomstore bedrifter tar i bruk DevOps-metoder. Hver indikator som inngikk i denne vurderingen har økt siden den gang. Når DevOps forbereder seg på å gå inn i sitt andre tiår, ville det vært fint å ta en tur gjennom fortiden og gå tilbake til opprinnelsen til DevOps – og til selve opprinnelsen av navnet.

Før 2007: Den perfekte hendelseskjeden

Frem til 2007 førte en serie omstendigheter til det som i dag er kjent som DevOps.

Lean produksjon har allerede vist seg å være beste praksis. Også kjent som Toyotas produksjonssystem, lean produksjon tar sikte på å optimalisere prosessene i produksjonsverkstedet. (Forresten, ledelsen i Toyota var opprinnelig inspirert av de originale samlebåndmetodene presentert av Ford Motor Company). Kontinuerlig forbedring er et mantra for lean produksjon. I praksis vurderes følgende tilnærminger kontinuerlig:

1. Å opprettholde råvare- og ferdigvarelagernivået på et minimum. Lean produksjon betyr et minimalt antall råvarer for produksjon av varer og et minimum antall ferdige produkter som venter på distribusjon etter bestillinger eller forsendelse.
2. Minimering av bestillingskøen. Det er ideelt hvis mottatte bestillinger går umiddelbart til fullført status. En nøkkelmetrik for lean produksjon vil alltid være tiden fra bestilling til levering.
3. Maksimering av effektiviteten i produksjonsprosessen. Reorganisering av prosesser og forbedret automatisering blir kombinert med målet om å produsere varer så raskt som mulig. Hvert punkt i produksjonen gjennom hele prosessen (kutting, sveising, montering, testing, osv.) vurderes for ineffektivitet.

I IT-verdenen har tradisjonelle metoder for vannfallsmodellen for programvareutvikling allerede gitt plass til raske iterative metoder, som Agile. Hastigheten var et stridsrop, selv om kvaliteten noen ganger ble dårligere i jakten på rask utvikling og distribusjon. På lignende måte har skybaserte løsninger, særlig Infrastructure-as-a-Service (IaaS) og Platform-as-a-Service (PaaS) vist seg å være modne løsninger i prosessene og infrastrukturen innen IT.

Endelig har det nylig begynt å dukke opp verktøykasser for Continuous Integration (CI). Begrepet CI-verktøy ble født og introdusert av Grady Booch allerede i 1991 med hans Booch-metode.

2007-2008: Den frustrerte belgieren

Den belgiske konsulenten, prosjektlederen og Agile-praktikeren Patrick Debois fikk i oppdrag av den belgiske regjeringen å bistå med migrasjonen av datasentre. Spesielt jobbet han med sertifisering og beredskapsvurdering. Oppgavene krevde at han koordinerte handlinger og bygde relasjoner mellom programvareutviklingsgrupper og driftsgrupper, serveredatabaser og nettverk. Hans frustrasjon over manglende sammenheng og vegger som skilte utviklings- og driftsmetoder, vekket hans aversjon. Ønsket om forbedring ledet raskt Debois til handling.
I 2008 på Agile-konferansen i Toronto foreslo Andrew Shafer å moderere et spesielt uformelt møte for å diskutere temaet "Agile-infrastruktur". Og bare én person dukket opp for å diskutere emnet: Patrick Debois. Deres diskusjon og idéutveksling drev konseptet med systemadministrasjon ved hjelp av Agile fremover. I samme år opprettet Debois og Shafer en moderat suksessfull gruppe for Agile Systems Administrator på Google.

2009: Saken om samarbeid mellom Dev og Ops

På O'Reilly Velocity-konferansen presenterte to ansatte fra Flickr, senior visepresident for tekniske operasjoner John Allspaw og teknisk direktør Paul Hammond, den nå berømte presentasjonen «10 distribusjoner per dag: samarbeid mellom Dev og Ops i Flickr».

Presentasjonen var i dramastil, og Ollespo og Hammond spilte ut et komplisert samspill mellom representanter fra utvikling og drift i prosessen med programvareutvikling, sammen med å finne syndebukker og gjensidige anklager i ånden av «Det er ikke koden min, det er dataene dine!» Deres presentasjon bekreftet at den eneste fornuftige løsningen er at aktivitetene knyttet til utvikling og utrulling av programvare må være smidige, transparente og helt integrerte. Over tid har denne presentasjonen blitt legendarisk og betraktes nå historisk som en grunnleggende milepæl, da etterspørselen etter en metode kjent i dag som DevOps oppstod i IT-bransjen.

2010: DevOps i USA

Med det økende antallet tilhengere ble DevOpsDays-konferansen første gang holdt i USA i Mountain View (California) umiddelbart etter den årlige Velocity-konferansen. La oss spole frem til 2018: over 30 DevOpsDays-konferanser er planlagt, inkludert dusinvis i USA.

2013: Prosjekt "Fugl Føniks"

For mange av oss var en annen bemerkelsesverdig hendelse i DevOps-historien utgivelsen av boken "Prosjekt 'Fugl Føniks'" av Gene Kim, Kevin Behr og George Spafford. I denne romanen fortelles historien om en IT-leder som havner i en vanskelig situasjon: han får i oppdrag å redde et kritisk e-handel prosjekt som har gått galt. Den mystiske mentoren til lederen — et styremedlem med interesse for prinsippene for smidig produksjon — veileder hovedpersonen til å tenke på IT og applikasjonsutvikling på nye måter, som forutså DevOps-konseptet. For øvrig inspirerte "Prosjekt 'Fugl Føniks'" oss til å skrive boken "Gå til outsourcing, ellers..." om en lignende historie fra virksomheten, der en visepresident for programvare bruker DevOps under utviklingen av et nytt stort produkt i outsourcing.

DevOps for fremtiden

Det er bedre å beskrive DevOps mer som en reise eller kanskje et streben, snarere enn som et endepunkt. DevOps, som smidig produksjon, streber etter kontinuerlig forbedring, økt produktivitet og effektivitet, og til og med kontinuerlig utrulling. Automatiserte verktøy for å støtte DevOps fortsetter å utvikle seg.

Mye har blitt oppnådd siden DevOps ble opprettet for det siste tiåret, og vi forventer å se enda mer i 2018 og fremover.

Kilde: habr.com