În acest articol doresc să îmi asum provocarea de a explica și defini ceea ce înseamnă DevOps. Aceste opinii sunt adunate din experiența mea și inspirate de ideile lui Adam Jacob (CTO of Chef). Direcțiile trasate de Adam reprezintă ideile de lucru pe care le utilizăm în proiecte. Am intenția să evidențiez MythBusting în DevOps atât ca disciplină cât și ca mod de a construi împreună o cultură și un mod de a gândi în organizațiile noastre.
Mișcarea DevOps pune accentul pe comunicarea, colaborarea și fuziunea între Software Developpers și IT Operations. Aceasta a rațiunea principal pentru care DevOps a apărut în industria software. Comunicarea, colaborarea și integrarea în cadrul dezvoltării de software ușurează mult munca oamenilor și poate fi realizată în mai multe feluri.
Adoptarea DevOps generează o serie de beneficii importante, oamenii din companiile care practică DevOps devin mai productivi și își cresc șansele de a avea un loc de muncă mai atractiv. Pasiunea pentru a învăța și aplica tehnologii noi și interesante aduce valoare muncii lor, le oferă satisfacție la locul de muncă și contribuie la un proces fără obstacole politice externe. Cultura tool-urilor și automatizarea pot umple golul existent dintre cele două silozuri, iar prin noul flow dezvoltarea de software va beneficia de:
Din punct de vedere cronologic, cuvântul #DevOps a apărut în anul 2009 și a stat în spatele mai multor discuții despre Agile, Operations Management (Systems Thinking & Dynamics), Theory of Constraints, LEAN și IT Service management. În altă ordine de idei, nu ar trebui să considerăm anul 2009 atât de important deoarece multă lume practica DevOps și înainte. Foarte mulți dintre cei care dezvoltau software, conduceau proiecte înainte de 2009, se ghidau pe aceleași principii care caracterizează DevOps acum. Presupun că cei care evanghelizează și răspândesc acum cultura DevOps practicau așa ceva cu mult înainte.
În următoarele paragrafe voi încerca să prezint DevOps din două perspective: disciplină și rol. În acest mod voi explica de ce ar trebui adoptată cultura DevOps în compania dumneavoastră. Prezentând punctele-cheie ale adoptării culturii DevOps, voi oferi tuturor o viziune de ansamblu dar și pașii de urmat pentru aderarea la DevOps.
Aceste idei nu ar trebui să-i vizeze exclusiv pe aceia care fac testing, development sau sysadmin, ci ar putea reprezenta un reper și pentru project manager-i, scrum masters, business analiști și pentru toți acei care fac parte din întregul proces de dezvoltare al software-ului.
În definirea DevOps ca disciplină ar trebui să luăm în considerare cât de UNIC este acest cuvânt pentru fiecare persoană. De la om la om, proiect la proiect sau companie la companie, abordarea este diferită și unică. Asemenea Continuous Delivery, nu există o rețetă specifică de a face DevOps. Nu contează în ce organizație lucrează, în ce poziție sau pe ce tehnologii, practicienii construiesc un flux de lucru care se bazează tehnologic pe automatizare și social pe colaborare.
Mulți oameni din IT văd în DevOps niște salvamari sau pompieri care vin și îi salvează în momentele critice printr-un re-deploy aducând sistemul în stare perfect stabilă.
Înainte de a aduce DevOps în compania dumneavoastră este recomandat să revedeți cultura, procesele, metricile, infrastructura și scalabilitatea echipei dumneavoastră și a organizației.
Cu toate că cei care fac DevOps sunt văzuți ca niște salvatori este de dorit evitarea unor situații de genul : "BIG release day", "let's roll back not forward", "call the DevOps he broke something". "The build is broken". Ei înclină spre un proces continuu și cursiv de îmbunătățire a dezvoltării de software.
Alcătuirea echipelor autonome de DevOps este un lucru destul de frecvent în companiile care au început să angajeze DevOps. Sugestia mea este evitarea acestei abordări în cadrul industriei software deoarece DevOps se referă la a crea și împărți responsabilități în cadrul echipei. Integrarea abilităților operaționale în echipele de dezvoltare va reduce conflictele și va îmbunătăți modul de livrare la client. Apar de asemenea situații când e posibilă existența unei echipe autonome de DevOps specializată în livrarea unor tool-uri sau construirea unui private cloud.
Pentru a putea practica DevOps trebuie să conștientizezi necesitatea unui mediu de lucru propice pentru toți cei implicați. Acest mediu poate fi bine definit de următorii termeni intercorelați:
Sentimentul de securitate: A te simți în deplină siguranță fizică, a avea garanția securității informației, dar și a capacității de a acționa fără teama unor consecințe nedorite.
Cunoștințe: Se spune că un indicator al progresului social este cunoașterea. A avea informația potrivită la momentul potrivit poate îmbunătăți software-ul, influența proiectul sau chiar compania. Pe lângă cunoștințele tehnice, importante sunt și cele de business.
Satisfacția: Munca de DevOps nu te va face fericit în fiecare zi, dar îți aduce meritul muncii bine făcute și implicit mulțumirea de a construi ceva durabil.
Termenul DevOps este de asemenea asociat cu tool-uri, aspect care se datorează probabil faptului că primii care au adoptat DevOps aveau ca backgroup, Configuration Management sau Linux Engineer. Pentru a-și face munca cât mai bine, ei foloseau tool-uri cum ar fi: Chef, Puppet, Jenkins, Atlassian Stack, Ansible, Xen or Redhat. Companiile care produc aceste tool-uri au făcut și încă fac foarte multe pentru cultura DevOps. Dar, din acest motiv, DevOps nu trebuie să fie confundat cu ele.
La un summit organizat de una din companiile mai sus menționate am aflat că ei evanghelizează DevOps în toate colțurile lumii. În acest fel, ajută companiile să facă DevOps și să implementeze Continuous Delivery, dar nu doar cu tool-urile produse de ei. Chiar dacă tool-ul lor este cel primordial, reușesc să introducă cu succes și alte tool-uri. Ideea principală ar fi ca răspândirea DevOps să aibă ca țintă principală setarea unei gândiri propice pentru membrii companiilor respective.
Nu este total greșit să spunem că DevOps reprezintă în mare măsură tool-uri. Un DevOps trebuie să fie în afară de un specialist în folosirea tool-urilor și un om sociabil și orientat spre comunicare. DevOps asemenea lui Continuous Delivery nu ar trebui să fie reprezentați de tool-uri, ci de procese și de timpul în care aceste ne pot da un feedback.
Eșecul este un subiect sensibil și de aceea foarte multă lume îl evită. În ceea ce privește atitudinea în fața eșecului, am selectat un fragment edificator în acest sens, din discursul președintelui Americii, Theodore Roosevelt, susținut la Paris, în anul 1910 - Man in the Arena:
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again"
Privind din perspectiva lui T Roosevelt, nu este bine doar să privești din exterior, să examinezi, ci este necesar să te implici, să investești timp și pasiune. Una din cele mai importante calități ale unei persoane care practică sau adoptă cultura DevOps este puterea de a accepta eșecul, dar și de a lupta cu noile tehnologii. Doar în felul acesta vei reuși să pui pe picioare un pipeline de Continuous Delivery Blue/Green. Construim acest pipeline investind timp, munca, tool-uri și bani, dar oare care este rezultat așteptat de la pipeline-ul unui proiect? Ce beneficii ar trebui să ne aducă folosirea acestui pipeline? Cel mai semnificativ rezultat pe care poate să îl transmită este momentul când un build a căzut - si să arate cât mai specific unde anume codul nostru trebuie corectat pentru a nu ajunge în producție cât mai curat. În dezvoltarea software este foarte important să găsești cât mai multe scenarii care să arate vulnerabilitățile codului și să îl reparăm în DEV și QA. Așadar, este indicat să ne lovim de eșec cât mai repede și conștient decât să ne surprindă la momentul nepotrivit.
Practicanții de DevOps trebuie să fie conștienți că tool-urile și procesele folosite, trebuie să constituie un ciclu de pași mărunți care ne vor da un feedback cât mai rapid.
Feedbackul ca parte esențială a muncii de zi cu zi, trebuie să fie primit la timp și în mod consecvent. Dacă aceste condiții nu sunt îndeplinite, vom pierde destul de mult timp pentru a afla iterația care a provocat eroare. Un feedback pozitiv și/sau constructiv dat la timp va aduce ducă valoare produsului. echipei și respectiv fiecărui individ în parte. În afară plusului de valoare pe care îl poate da un feedback corespunzător - companiile, proiectele și echipele pot lucra mai agile, lean și se pot concentra pe inovații în fiecare zi.
Intenția din spatele acestui articol a fost definirea conceptului DevOps. Aș vrea să folosesc o definiție dată de Adam Jacob pe care o consider cel mai aproape de adevăr: "A cultural and professional movement, focus on how we build and operate high velocity "projects", born from the experiences of the practitioners". Adam Jacob consideră că pentru a te considera DevOps, nu este necesar să fii DevOps ca disciplină, profesie sau rol, dar trebuie să cunoști, să practici și să răspândești beneficiile culturii Devops. Iar munca în echipă, punerea în balanță a părerilor tuturor membrilor echipei - indiferent de aria lor de expertiză, duce la cel mai bun rezultat. Atenția se concentrează în principal asupra construirii și livrării unor proiecte software de dimensiuni mari și o calitate ridicată.