Helló, Habr! Örömmel mutatom be az írás fordítását. szerző: Steve Mezak.
Attól függően, hogy honnan nézzük, a DevOps idén a kilencedik vagy tizedik évfordulóját ünnepli. A RightScale 2016-os felhőtartalom jelentésében megállapították, hogy a kis- és középvállalkozások 70%-a alkalmazza a DevOps módszereit. Azóta minden egyes tényező a becslésben növekedett. Miközben a DevOps a második évtizede felé készül, jó lenne sétálni a múlt labirintusában, és visszatérni a DevOps gyökereihez — sőt, magának a névnek az eredetéhez is.
2007 előtt: Az események tökéletes láncolata
2007 előtt a körülmények sorozata végül létrehozta azt, amit ma DevOps-nak hívunk.
Lean gyártás már bizonyítottan a legjobb gyakorlat. Más néven a Toyota gyártási rendszere, a lean gyártás a gyártási folyamatok optimalizálására törekszik. (Egyébként a Toyota vezetősége eredetileg a Ford Motor Company által bemutatott eredeti gyártósori módszereken alapult.) Folyamatos fejlesztés — ez a lean gyártás mantrája. A gyakorlatban folyamatosan értékelik a következő utakat:
- A nyersanyagok és késztermékek készleteinek minimális szinten tartása. A lean gyártás a lehető legkisebb mennyiségű nyersanyagot igényel a termékek előállításához, valamint a lehető legkisebb mennyiségű készterméket, amely várja a rendeléseket vagy a kiszállítást.
- A rendelési sorok minimalizálása. Ideális, ha a beérkező rendelések azonnal befejezett állapotba kerülnek. A lean gyártás kulcsmutatója mindig az az idő lesz, ami a rendelés beérkezésétől a kiszállításig telik.
- A gyártási folyamatok hatékonyságának maximalizálása. A folyamatok átszervezése és a javított automatizálás egyesül a lehető leggyorsabb termelés érdekében. A gyártás minden szakaszát (vágás, hegesztés, összeszerelés, tesztelés stb.) hatékonyság szempontjából értékelik.
Az IT világában a hagyományos vízesés modell szoftverfejlesztési módszerei már átadták helyüket a gyors iteratív módszereknek, mint például Agile. A sebesség harci kiáltás volt, még ha a minőség néha a gyors fejlesztés és telepítés érdekében romlott is. Hasonlóképp az, ahogyan a felhőalapú számítások, különösen Infrastruktúra mint Szolgáltatás (IaaS) és Platform mint Szolgáltatás (PaaS) érett megoldásokként bizonyították magukat az IT folyamatokban és infrastruktúrában.
Végül, nemrégiben megjelentek az eszközkészletek a folyamatos integrációnak (CI). A CI eszközök meglátása Grady Booch által született meg és került bemutatásra 1991-ben a Booch Módszerében.
2007-2008: Csalódott belga
Patrick Debois, belga tanácsadó, projektmenedzser és Agile szakértő, megbízást kapott a belga kormánytól, hogy segítsen az adatközpontok migrálásában. Különösen a tanúsítás és az alkalmasság ellenőrzésével foglalkozott. A feladatok megkövetelték tőle, hogy összehangolja a szoftverfejlesztési és üzemeltetési csapatok tevékenységét, szerverekadatbázisok és hálózatok. Csalódottsága a fejlesztési és üzemeltetési módszerek közötti hiányzó kohézió miatt érzett keserűségét keltette. A jobb iránti törekvése hamarosan cselekvésre ösztönözte Deboist.
2008-ban a torontói Agile konferencián Andrew Schaefer javasolta, hogy moderáljon egy különleges informális találkozót a "Agile infrastruktúra" témában. Csak egy ember jött el a témáról való beszélgetésre: Patrick Debois. Diskurzusuk és ötleteik cseréje elősegítette az Agile rendszergazdálkodás koncepciójának előrehaladását. Ebben az évben Debois és Schaefer létrehozott egy mérsékelten sikeres Agile Systems Administrator csoportot a Google-ben.
2009: A Dev és Ops együttműködés ügye
Az O'Reilly Velocity konferencián a Flickr két munkatársa, John Allspaw műszaki műveletekért felelős alelnök és Paul Hammond műszaki igazgató, bemutatták a mára híressé vált előadásukat, „Napi 10 telepítés: Dev és Ops együttműködés a Flickr-en”.
A prezentáció drámai stílusban zajlott, Allspough és Hammond bonyolult interakciót játszottak el a fejlesztési és üzemeltetési képviselők között a szoftverek telepítése során, miközben a hibák keresésével és kölcsönös vádaskodással foglalkoztak, mint például: „Ez nem az én kódom, ez mind a te gépeid!” A prezentációjuk megerősítette, hogy az egyetlen ésszerű kivezető út az, ha a szoftverfejlesztés és telepítés folyamata zökkenőmentes, átlátható és teljes mértékben integrált. Idővel ez a prezentáció legendássá vált, és most már történelmileg alapvető mérföldkőként tekintenek rá, amikor az IT iparban felmerült az olyan módszertan iránti igény, amelyet ma DevOps néven ismernek.
2010: DevOps az Egyesült Államokban
A támogatók számának növekedésével a DevOpsDays konferenciát először az Egyesült Államokban, Mountain View-ban (Kalifornia) rendezték meg, közvetlenül a Velocity éves konferenciáját követően. Ugorjunk 2018-ba: több mint 30 DevOpsDays konferencia van tervezve, köztük tucatnyi az Egyesült Államokban.
2013: A Phoenix projekt
Sokunk számára a DevOps történetében egy másik figyelemre méltó pillanat volt a "Phoenix Project" című könyv megjelenése Gene Kim, Kevin Behr és George Spafford szerzőktől. Ez a regény egy IT-menedzser történetét meséli el, aki kétségbeejtő helyzetbe kerül: meg kell mentenie egy kritikus fontosságú e-kereskedelmi fejlesztési projektet, ami rosszul sült el. A menedzser titokzatos mentora — a tanács tagja, aki a lean módszerek iránt rajong — új módszereket javasol a főszereplőnek az IT és az alkalmazásfejlesztés megértésére, előrevetítve a DevOps fogalmát. Egyébként a "Phoenix Project" inspirált minket, hogy megírjuk a "Menj át az outsourcingra, különben..." című könyvet, amely egy hasonló üzleti történetet mesél el, amikor a szoftverért felelős alelnök DevOps-t használ egy új nagy termék fejlesztése során az outsourcing során.
DevOps a jövőért
A DevOps-t inkább utazásként vagy talán törekvésként érdemes leírni, semmint végcélként. A DevOps, hasonlóan a lean gyártáshoz, a folyamatos fejlődésre, a termelékenység és hatékonyság növelésére, valamint a folyamatos telepítésre törekszik. A DevOps támogatására szolgáló automatizált eszközök folyamatosan fejlődnek.
Sok mindent elértünk a DevOps létrejötte óta az elmúlt évtizedben, és 2018-ban, valamint a jövőben is még többet várunk.
Forrás: habr.com
