Szia Habr! Figyelmébe ajánlom a cikk fordítását szerző: Steve Mezak.
Az Ön nézőpontjától függően a DevOps idén ünnepli fennállásának kilencedik vagy tizedik évfordulóját. 2016-ban a RightScales State of the Cloud jelentése megjegyezte, hogy a kis- és középvállalkozások 70 százaléka alkalmazza a DevOps gyakorlatokat. Azóta minden mutató, amely ezt a pontszámot alkotja, nőtt. Miközben a DevOps a második évtizedébe készül, nagyszerű lenne egy sétát tenni a múltban, és visszatérni a DevOps eredetéhez – sőt magának a névnek az eredetéhez.
2007 előtt: Az események tökéletes láncolata
2007 előtt egy sor körülmény szülte azt, amit ma DevOps néven ismerünk.
Sovány már bevált gyakorlatnak bizonyult. Más néven Toyota gyártási rendszer, A Lean Manufacturing a folyamatok optimalizálására törekszik a gyártási területen. (A Toyota vezetését egyébként kezdetben a Ford Motor Company által bevezetett eredeti futószalagos módszerek ihlették). Folyamatos fejlesztés a karcsú gyártás mantrája. A gyakorlatban a következő utakat folyamatosan értékelik:
- A nyersanyagok és késztermékek készletszintjének minimális szinten tartása. A karcsú gyártás azt jelenti, hogy minimális mennyiségű nyersanyag áll rendelkezésre az áruk előállításához, valamint minimális mennyiségű késztermék, amely megrendelésre vagy kiszállításra vár.
- A rendelési sor minimalizálása. Ideális esetben a beérkezett rendelések azonnal a kész állapotba kerülnek. A karcsú gyártás kulcsfontosságú mérőszáma mindig a megrendelés beérkezésétől a kiszállításig eltelt idő.
- A gyártási folyamat hatékonyságának maximalizálása. A folyamatok újratervezése és a továbbfejlesztett automatizálás egyesül annak érdekében, hogy a lehető leggyorsabban előállítsák az árukat. A teljes pálya mentén minden gyártási területet (vágás, hegesztés, összeszerelés, tesztelés stb.) hatástalanság szempontjából értékelnek.
Az informatikai világban a szoftverfejlesztés vízesés modelljének hagyományos módszerei már átadták helyét a gyors iteratív módszereknek, mint pl. Agilis. A gyorsaság volt a gyülekező, még akkor is, ha a minőség néha szenvedett a gyors fejlesztés és bevetés miatt. Hasonló módon, különösen a számítási felhő Infrastruktúra szolgáltatásként (IaaS) és Platform-as-a-Service (PaaS) kiforrott megoldásként bizonyultak az IT-folyamatok és infrastruktúra területén.
Végül, a közelmúltban elkezdtek megjelenni az eszköztárak Folyamatos integráció (CI). A CI-eszközök ötletét Gradi Booch született meg és mutatta be 1991-ben Booch-módszerében.
2007-2008: Csalódott belga
Patrick Debois belga tanácsadó, az Agile projekt- és gyakorlatmenedzser megbízást fogadott el egy belga kormánytól, hogy segítsen az adatközpontok áttelepítésében. Különösen a tanúsításban és a készenléti vizsgálatban vett részt. Feladatai megkövetelték tőle, hogy koordinálja és kapcsolatokat építsen ki a szoftverfejlesztő csapatok, valamint a szerver-, adatbázis- és hálózatüzemeltetési csapatok között. A kohézió hiánya, a fejlesztési és működési módszereket elválasztó falak miatti csalódottsága keserűvé tette. Desbois fejlődési vágya hamarosan tettekre késztette.
A 2008-as torontói Agile konferencián Andrew Schaefer egy speciálisan szervezett informális találkozó moderálását javasolta a téma megvitatására.Agilis infrastruktúra"És csak egy ember jött el, hogy megvitassák a témát: Patrick DeBois. Megbeszélésük és eszmecseréjük továbbfejlesztette az Agilis rendszeradminisztráció koncepcióját. Ugyanebben az évben DeBois és Schaefer létrehozta a közepesen sikeres Agile Systems Administrator csoportot a Google-nál.
2009: A Dev és az Ops együttműködésének esete
Az O'Reilly Velocity konferencián a Flickr két alkalmazottja, John Allspaw műszaki műveletekért felelős alelnök és Paul Hammond műszaki igazgató tartotta a ma már híres előadást. „Napi 10 telepítés: Fejlesztői és műveleti együttműködés a Flickrnél”.
A prezentáció drámai volt, Allspaw és Hammond újrajátszotta a fejlesztési és üzemeltetési képviselők közötti bonyolult interakciókat a szoftvertelepítési folyamat során, ujjal mutogatással és vádakkal kiegészítve a következőképpen: „Ez nem az én kódom, hanem az Ön számítógépe!” Előadásuk megerősítette, hogy az egyetlen ésszerű lehetőség az, hogy a szoftverfejlesztési és -telepítési tevékenységek zökkenőmentesek, átláthatóak és teljesen integráltak legyenek. Idővel ez a bemutató legendássá vált, és ma már történelmi mérföldkőnek tekintik, amikor az IT-ipar elkezdte követelni a ma DevOps néven ismert módszertant.
2010: DevOps az Amerikai Egyesült Államokban
A DevOpsDays konferencia első alkalommal került megrendezésre az Egyesült Államokban, a kaliforniai Mountain View-ban, közvetlenül az éves Velocity konferenciát követően. Gyorsan előre 2018-ra, és több mint 30 DevOpsDays konferenciát terveznek, köztük több tucat az Egyesült Államokban.
2013: "Phoenix" projekt
Sokunk számára egy másik figyelemre méltó pillanat a DevOps történetében Gene Kim, Kevin Behr és George Safford „The Phoenix Project” című könyvének kiadása volt. Ez a regény egy informatikai vezető történetét meséli el, aki kétségbeejtő helyzetbe kerül: egy kritikus e-kereskedelmi projekt megmentése a feladat, amely rosszul sült el. A menedzser titokzatos mentora – az igazgatótanács tagja, aki rajong a lean gyártási módszerekért – új utakat javasol a főszereplőnek az informatikai és alkalmazásfejlesztési gondolkodásra, előrevetítve a DevOps koncepcióját. Mellesleg, a „Phoenix Project” inspirált bennünket, hogy megírjuk az „Outsource or else...” című könyvet egy hasonló üzleti történetről, amelyben a szoftver alelnöke DevOps-t használ egy új, nagy kiszervezett termék fejlesztése során.
DevOps a jövő számára
Érdemes a DevOps-ot utazásként, esetleg törekvésként leírni, nem pedig végső úti célként. A DevOps a lean gyártáshoz hasonlóan a folyamatos fejlesztésre, a termelékenység és hatékonyság növelésére, sőt a folyamatos telepítésre törekszik. A DevOps támogatására szolgáló automatizált eszközök folyamatosan fejlődnek.
A DevOps létrejötte óta sok mindent elértünk az elmúlt évtizedben, és 2018-ban és azt követően még többet várunk.
Forrás: will.com