Salut, Habr! Vă prezint traducerea articolului „Originile DevOps: Ce înseamnă un nume?“ autor Steve Mezak.

În funcție de perspectiva ta, DevOps va sărbători a noua sau a zecea aniversare în acest an. În 2016, raportul companiei RightScale despre starea norilor a menționat că 70% din micile și mediile afaceri adoptă metodele DevOps. Fiecare indicator care contribuie la această evaluare a crescut de atunci. Pe măsură ce DevOps se pregătește să intre în al doilea său deceniu, ar fi minunat să facem o plimbare prin cotloanele trecutului și să revenim la origins DevOps – și chiar la originea acestui nume.

Până în 2007: O serie perfectă de evenimente

Până în 2007, o serie de circumstanțe au dus în cele din urmă la nașterea a ceea ce astăzi este cunoscut sub numele de DevOps.

Producția Lean s-a dovedit deja a fi cea mai bună practică. De asemenea, cunoscut sub denumirea de sistemul de producție Toyota, producția Lean își propune să optimizeze procesele din fabrica de producție. (Apropo, conducerea Toyota a fost inițial inspirată de metodele originale de asamblare prezentate de Ford Motor Company). Îmbunătățirea continuă — este un motto pentru producția Lean. În practică, se evaluează constant următoarele abordări:

1. Menținerea nivelului stocurilor de materii prime și produse finite la minim. Producția Lean implică o cantitate minimă de materii prime pentru fabricarea de bunuri și o cantitate minimă de produse finite care așteaptă distribuirea comenzilor sau expedierea.
2. Minimizarea timpilor de așteptare pentru comenzi. Este ideal ca comenzile primite să treacă imediat în stadiul de finalizate. O metrică cheie pentru producția Lean va fi întotdeauna timpul de la primirea comenzii până la livrare.
3. Maximizarea eficienței procesului de producție. Reorganizarea proceselor și automatizarea îmbunătățită lucrează împreună pentru a produce bunuri cât mai rapid posibil. Fiecare etapă de producție pe tot parcursul procesului (tăiere, sudare, asamblare, testare etc.) este evaluată pentru ineficiență.

În lumea IT, metodele tradiționale ale modelului în cascadă pentru dezvoltarea software-ului au cedat locul celor rapide și iterative, cum ar fi Agile. Viteza a fost un strigăt de luptă, chiar dacă calitatea scădea uneori în căutarea unei dezvoltări și desfășurări rapide. Așa cum se întâmplă și cu computația în cloud, în special Infrastructura ca Serviciu (IaaS) și Platforma ca Serviciu (PaaS) s-au dovedit soluții mature în procesele și infrastructura IT.

În cele din urmă, recent au început să apară seturi de instrumente pentru Continuous Integration (CI). Conceptul de instrumente CI a fost creat și prezentat de Grady Booch încă din 1991 în Metoda lui Booch.

2007-2008: Belgianul dezamăgit

Consultantul belgian, manager de proiecte și practician Agile, Patrick Debois a fost responsabilizat de guvernul belgian pentru a ajuta la migrarea centrelor de date. În special, s-a ocupat cu certificarea și verificarea pregătirii. Sarcinile îi cereau să alinieze acțiunile și să construiască relații între echipele de dezvoltare software și grupurile de operațiuni servere, baze de date și rețele. Decepția sa față de lipsa de coeziune și pereții care separau metodele de dezvoltare și operațiuni i-a insuflat frustrare. Aspirația către mai bine l-a determinat pe Debois să acționeze.
În 2008, la conferința Agile din Toronto, Andrew Shafer a propus să modereze o întâlnire informală pentru a discuta despre tema "Infrastructura Agile". Și doar o singură persoană a venit să discute subiectul: Patrick Debois. Discuția lor și schimbul de idei au avansat conceptul de administrare a sistemelor într-un mod Agile. În acel an, Debois și Shafer au creat un grup moderat de Administratori de Sisteme Agile pe Google.

2009: Cazul colaborării între Dev și Ops

La conferința O’Reilly Velocity, doi angajați Flickr, vicepreședintele senior pentru operațiuni tehnice Jon Allspaw și directorul tehnic Paul Hammond, au prezentat celebra prezentare „10 desfășurări pe zi: colaborarea Dev și Ops la Flickr”.

Prezentarea a fost în stilul unei drame, Olspow și Hammond au interpretat o interacțiune complexă între reprezentanții Development și Operations în timpul desfășurării software-ului, împreună cu căutarea vinovaților și acuzații reciproce în stilul „Nu este codul meu, sunt computerele tale!” Prezentarea lor a confirmat că singura soluție rațională este ca activitatea de dezvoltare și desfășurare a software-ului să fie fluidă, transparentă și complet integrată. De-a lungul timpului, această prezentare a devenit legendară și este acum considerată istoric un reper fundamental, când în industria IT a apărut cererea pentru metodologia cunoscută astăzi sub numele de DevOps.

2010: DevOps în Statele Unite ale Americii

Odată cu creșterea numărului de susținători, conferința DevOpsDays a fost organizată pentru prima dată în Statele Unite ale Americii, în Mountain View (California), imediat după conferința anuală Velocity. Să ne mutăm în 2018: sunt programate peste 30 de conferințe DevOpsDays, inclusiv zeci în Statele Unite.

2013: Proiectul „Phoenix”

Pentru mulți dintre noi, un moment notabil în istoria DevOps a fost publicarea cărții „Proiectul ‟Phoenix‟” de Gene Kim, Kevin Behr și George Spafford. Acest roman spune povestea unui manager IT, care se află într-o situație fără ieșire: i s-a încredințat misiunea de a salva un proiect critic de dezvoltare a comerțului electronic care a mers prost. Mentorul misterios al managerului — un membru al consiliului de administrație, pasionat de metodele lean — îi sugerează protagonistului modalități noi de a înțelege IT-ul și dezvoltarea aplicațiilor, anticipând conceptul DevOps. Apropo, „Proiectul ‟Phoenix‟” ne-a inspirat să scriem cartea „Treci la externalizare, altfel…” despre o poveste similară din afaceri, când vicepreședintele de software folosește DevOps în procesul de dezvoltare a unui nou produs important în externalizare.

DevOps pentru viitor

Este mai bine să descriem DevOps mai degrabă ca un călător sau poate o aspirație, decât ca un punct final. DevOps, ca și producția lean, tinde spre îmbunătățire continuă, creșterea productivității și eficienței și chiar desfășurări continue. Instrumentele automatizate pentru suportul DevOps continuă să evolueze.

S-au realizat multe lucruri de la crearea DevOps în ultima decadă, iar noi ne așteptăm să vedem și mai multe în 2018 și în viitor.

Sursa: habr.com