Originea DevOps: ce este numele?

Bună, Habr! Vă prezint atenției o traducere a articolului „Originile DevOps: ce este într-un nume?” de Steve Mezak.

În funcție de punctul tău de vedere, DevOps își va sărbători anul acesta a noua sau a zecea aniversare. În 2016, raportul RightScales State of the Cloud a remarcat că 70% dintre IMM-uri adoptă practici DevOps. Fiecare indicator care alcătuiește acest scor a crescut de atunci. Pe măsură ce DevOps se pregătește să intre în al doilea deceniu, ar fi grozav să faceți o plimbare pe culoar și să vă întoarceți la originile DevOps – și chiar la originile numelui în sine.

Înainte de 2007: Un lanț perfect de evenimente

Înainte de 2007, o serie de circumstanțe au dat naștere în cele din urmă a ceea ce este cunoscut astăzi ca DevOps.

A se sprijini sa dovedit deja a fi cea mai bună practică. De asemenea cunoscut ca si Sistem de producție Toyota, Lean Manufacturing se străduiește să optimizeze procesele de la nivelul producției. (Apropo, conducerea Toyota a fost inspirată inițial de metodele originale ale liniei de asamblare introduse de Ford Motor Company). Imbunatatire continua este mantra pentru lean manufacturing. În practică, următoarele căi sunt evaluate în mod constant:

  1. Menținerea nivelurilor de stoc de materii prime și produse finite la minimum. Lean manufacturing înseamnă o cantitate minimă de stoc de materii prime pentru a produce mărfuri și o cantitate minimă de produse finite care așteaptă să fie comandate sau expediate.
  2. Minimizarea cozii de comandă. În mod ideal, comenzile primite trec imediat la starea finalizată. Valoarea cheie pentru manufacturarea slabă va fi întotdeauna timpul de la primirea comenzii până la livrare.
  3. Maximizarea eficienței procesului de producție. Reproiectarea proceselor și automatizarea îmbunătățită se combină pentru a produce bunuri cât mai repede posibil. Fiecare zonă de producție de-a lungul întregii trasee (tăiere, sudare, asamblare, testare etc.) este evaluată pentru ineficiență.

În lumea IT, metodele tradiționale ale modelului cascadă de dezvoltare a software-ului au făcut deja loc unor metode iterative rapide, cum ar fi Agilitate. Viteza a fost strigătul de raliu, chiar dacă calitatea a avut de suferit uneori în urmărirea dezvoltării și implementării rapide. În același mod, cloud computing, în special Infrastructură-ca-serviciu (IaaS) și Platforma-as-a-Service (PaaS) s-au dovedit a fi soluții mature în procesele și infrastructura IT.

În cele din urmă, seturile de instrumente au început să apară recent pentru Integrare continuă (CI). Ideea instrumentelor CI a luat naștere și a fost prezentată de Gradi Booch în 1991, în Metoda lui Booch.

2007-2008: Belgian dezamăgit

Consultantul belgian, managerul de proiect și practică Agile Patrick Debois a acceptat o numire de la un minister al guvernului belgian pentru a ajuta la migrarea centrului de date. În special, a fost implicat în certificare și testare de pregătire. Responsabilitățile sale i-au cerut să coordoneze și să construiască relații între echipele de dezvoltare software și echipele de operațiuni de server, baze de date și rețea. Frustrarea lui din cauza lipsei de coeziune și a zidurilor care despart metodele de dezvoltare și operare l-au lăsat amar. Dorința lui Desbois de a se perfecționa l-a condus curând la acțiune.
La conferința Agile din 2008 de la Toronto, Andrew Schaefer a propus moderarea unei întâlniri informale special aranjate pentru a discuta subiectul „Infrastructură agilă„Și o singură persoană a venit să discute acest subiect: Patrick DeBois. Discuția lor și schimbul de idei au avansat conceptul de administrare a sistemelor Agile. În același an, DeBois și Schaefer au creat grupul de Administratori de Sisteme Agile de succes moderat la Google.

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

La conferința O'Reilly Velocity, doi angajați Flickr, vicepreședintele senior al operațiunilor tehnice John Allspaw și CTO Paul Hammond, au susținut prezentarea acum faimoasă. „10 implementări pe zi: colaborare între dezvoltatori și operațiuni la Flickr”.

Prezentarea a fost o dramă, Allspaw și Hammond reacționând interacțiunile complexe dintre reprezentanții de dezvoltare și operațiuni în timpul procesului de implementare a software-ului, complet cu arătare cu degetul și recriminări de tipul „Nu este codul meu, sunt toate computerele tale!” Prezentarea lor a confirmat că singura opțiune sensibilă este ca activitățile de dezvoltare și implementare de software să fie fără întreruperi, transparente și complet integrate. De-a lungul timpului, această prezentare a devenit legendară și este acum văzută istoric ca o piatră de hotar fundamentală atunci când industria IT a început să solicite metodologia cunoscută astăzi ca DevOps.

2010: DevOps în Statele Unite ale Americii

Cu un public tot mai mare, conferința DevOpsDays a avut loc pentru prima dată în Statele Unite la Mountain View, California, imediat după conferința anuală Velocity. Avanză rapid până în 2018 și sunt programate peste 30 de conferințe DevOpsDays, inclusiv zeci în Statele Unite.

2013: Proiectul „Phoenix”

Pentru mulți dintre noi, un alt moment demn de remarcat din istoria DevOps a fost publicarea cărții „The Phoenix Project” de Gene Kim, Kevin Behr și George Safford. Acest roman spune povestea unui manager IT care se află într-o situație disperată: el are sarcina de a salva un proiect critic de comerț electronic care a mers prost. Mentorul misterios al managerului - un membru al consiliului de administrație pasionat de metodele lean manufacturing - sugerează noi modalități personajului principal de a gândi despre IT și dezvoltarea aplicațiilor, anticipând conceptul DevOps. Apropo, „The Phoenix Project” ne-a inspirat să scriem cartea „Outsource or else...” despre o poveste similară de afaceri în care un VP de software folosește DevOps în timpul dezvoltării unui nou produs major externalizat.

DevOps pentru viitor

Merită să descrii DevOps ca o călătorie, sau poate o aspirație, mai degrabă decât o destinație finală. DevOps, la fel ca producția slabă, se străduiește pentru îmbunătățirea continuă, productivitate și eficiență sporite și chiar implementare continuă. Instrumentele automate pentru a sprijini DevOps continuă să evolueze.

S-au realizat multe de la înființarea DevOps în ultimul deceniu și ne așteptăm să vedem și mai multe în 2018 și ulterior.

Sursa: www.habr.com

Adauga un comentariu