Badoiu Mihail - IISC

Înțelegerea DevOps și reducerea decalajului

dintre integrarea continuă si livrarea
continua

1. Introducere
Ca parte a transformării Agile din ultimii ani, am văzut organizații IT adoptând principii de
integrare continuă în ciclul lor de livrare a software-ului, ceea ce a îmbunătățit eficiența
echipelor de dezvoltare. Cu timpul s-a realizat că această optimizare ca parte a integrării
continue - singură - nu ajută la eficientizarea întregului ciclu de viață al livrării sau nu
conduce la eficiența organizației. Cu excepția cazului în care toate componentele unui
ciclu de viață de livrare a software-ului funcționează ca o mașină bine unsă, eficiența
organizării pentru a optimiza ciclul de viață al livrării nu poate fi îndeplinită. Aceasta este
problema pe care DevOps încearcă să o soluționeze. Această lucrare încearcă să
acopere toate aspectele DevOps aplicabile diferitelor faze ale SDLC (Software
Development Life Cycle) și vorbește în mod specific despre necesitatile afacerii,
modalități de a trece de la integrarea continuă la livrarea continuă și beneficiile sale.

Fig 1 Fluxul build-urilor de dezvoltare

Modul în care întreprinderile livrează software trece printr-un val de schimbări pe măsură
ce mediul în care operează se schimbă - nevoile pieței se schimbă continuu, tehnologia
se schimbă rapid, există o presiune mai mare pentru a se adapta la nevoile pieței și a
livra rapid. Întreprinderile nu-și mai pot permite să facă un client să aștepte timp de 6 luni
sau 1 an pentru apariția unei versiuni și apoi să solicite feedback de la client cu privire la
modul în care se comportă software-ul. Clienții așteaptă un angajament continuu, astfel
încât să poată oferi feedback continuu. Pentru a face față provocărilor actuale,

1
Badoiu Mihail - IISC

întreprinderile trebuie să fie agile în toate fazele ciclului de viață al dezvoltării software-
ului.

De-a lungul anilor, organizațiile au adoptat multe optimizări de proces în practicile lor de
dezvoltare software (transformare agilă). Cu toate acestea, în această întreagă evoluție
- accentul a fost pus în principal pe dezvoltarea de software, lăsând partea operațională
a livrării de software rămase în urmă în această cursă de optimizare. Ca urmare, de-a
lungul anilor, ceea ce sa întâmplat este că echipele de dezvoltare software sunt capabile
să ofere un ritm mult mai rapid decât cel în care echipele de operațiuni pot absorbi build-
urile produsului. Se spune pe bună dreptate că puterea lanțului este la fel de puternică
ca cea mai slabă verigă din lanț - așa este și cazul livrării de software, adică orice
optimizări se face în ciclul de livrare a software-ului - dacă o fază nu este capabilă să țină
pasul - întreaga livrarea va fi întârziată.

DevOps este un set de practici care încearcă la baza lucrurilor să reducă decalajul dintre
operațiuni si dezvoltare [5], dar în același timp nu se limitează la această dezvoltare și
transferul operațiunilor acoperă în schimb toate aspectele care ajută la o viteză rapidă,
optimizată și de înaltă calitate livrarea de software. DevOps este un set de principii către
livrarea de software, unde accentul cheie este pe viteza de livrare, testarea continuă în
producție, cum ar fi mediul înconjurător, să fie în stare de expediere în orice zi, feedback
continuu, capacitatea de a reacționa la schimbarea mai rapidă, echipele care lucrează
pentru a realiza un obiectiv în loc de o sarcină (nu mai există limite de echipă care
provoacă o întârziere [1]. DevOps extinde principiile agile pentru întreaga conductă de
livrare a software-ului. Deși principiile DevOps se aplică întregului SDLC (Software
Development Life Cycle), dar motivatorul cheie sau zona de focalizare care a declanșat
toate acestea - se asigură că echipa de operațiuni poate rula împreună cu echipe de
dezvoltare.

2. DevOps aplicat diferitelor faze de livrare software

A. Planificare continuă
Planurile de afaceri trebuie să fie agile (și au fost într-o anumită măsură), adică capabile
să se adapteze rapid la condițiile de piață în schimbare. Trebuie întotdeauna sa existe un
punct de control intermediar în plan pentru a reevalua situația și a modifica / ajusta
planurile după cum este necesar pe baza feedback-ului pieței. Este dificil pentru echipele
Dev / Test să se adapteze la schimbările rapide din mediile de afaceri. DevOps vă permite
să faceți acest lucru având întotdeauna un backlog de produs prioritar, un canal continuu
de feedback cu clienții și capacitatea de a prioritiza tot timpul restanța de produs, luând
2
Badoiu Mihail - IISC

în considerare direct unghiul de afaceri. Există un proces continuu de planificare a

porțiunilor mici - executare - obținere de feedback - reacție la feedback și ajustare a
planului dacă este necesar și ciclul continuă.

B. Integrare continuă
Integrarea continuă se referă, practic, la integrarea timpurie, nu se păstrează modificările
localizate în spațiul de lucru mult timp, în schimb se discuta modificările cu echipa și se
valideaza modul în care codul se comportă continuu. Nu numai partajarea în cadrul
echipelor de componente, ci integrarea dincolo de limitele componentelor, la nivelul
integrării produsului. În plus, această etapă a optimizării procesului se referă la realizarea
automatizării, astfel încât imediat ce dezvoltatorul oferă schimbarea, sistemele de
construcție detectează acest lucru (poate fi chiar un eveniment programat la sfârșitul zilei)
și declanșează o construcție, efectuează teste de ‘sanity’ și postează build-ul într-un
depozit (repository) hostat online. Acesta trebuie să fie un proces continuu repetabil pe
tot parcursul ciclului de dezvoltare

C. Implementare continuă
Aceasta este inima DevOps și constituie piesa critică a optimizării generale a livrării de
software. Sondajele au arătat că în majoritatea organizațiilor partea operațiunilor de
livrare contribuie semnificativ la întârzierea livrării de software. Configurarea hardware-
ului pentru a testa build-urile de dezvoltare poate dura timp de zile pana la săptămâni. În
plus, aceste procese de implementare sunt manuale și nu sunt consistente. Principiile
DevOps recomandă automatizarea implementării și furnizării de hardware, iar diferiți
furnizori de cloud joacă un rol crucial în acest domeniu. Abordarea DevOps propune ca
întreaga aprovizionare a infrastructurii să fie menținută ca si cod în depozitul (repository-
ul) de cod sursă - conceptul fiind denumit Infrastructură ca cod (IaC – Infrastructure as
Code) [6].

D. Testare continuă
Condiția preliminară pentru testarea continuă este - Automatizarea fiecarui caz de testare.
Orice proces care trebuie repetat în timp - ar trebui automatizat, există suficiente
tehnologii disponibile pentru a atinge acest obiectiv. Procesul de testare manuală trebuie
evaluat pentru posibilitățile de automatizare și, în majoritatea cazurilor, vor exista
modalități de automatizare a aceluiași lucru. Procesul de livrare a software-ului ar trebui
să poată executa suita de testare pentru fiecare construire de software generată automat,
fără intervenția utilizatorului, orientându-se astfel către scopul final de a putea livra rapid
o versiune de calitate. Întregul principiu al testării continue nu numai că mută procesul de

3
Badoiu Mihail - IISC

testare la începutul ciclului, dar permite, de asemenea, efectuarea testelor pe sisteme de

producție (completate de implementare continuă).

E. Monitorizare continuă
Așa cum s-a discutat în abordările adoptării de mai sus, cu capacitatea de a testa timpuriu
și pe un sistem similar producției, există posibilitatea de a observa diverși parametri de
calitate și, prin urmare, capacitatea de a reacționa la orice surpriză în timp util.

3. Conducta de livrare software folosind DevOps

Figura 2 prezintă conducta de livrare cu diferite abordări de integrare DevOps. Poate fi
comparată cu o conductă de livrare a unei unități de fabricație. Fiecare versiune / lansare
trebuie să treacă prin această conductă automată de faze / fvt / regresie / etapă / faze de
testare a producției pentru a șterge toți parametrii de calitate și dacă această conductă
este automatizată, acest lucru vă va ajuta rapid și lansări consistente.

Fig 2 Integrarea DevOps in actiune

4
Badoiu Mihail - IISC

4. Reducerea decalajului de la integrarea continuă la

livrarea continua
Procesele de integrare continuă au fost aici de ceva vreme și ca parte a transformării din
ultimul deceniu, majoritatea echipelor de proiect au la dispoziție procese care se aliniază
cu integrarea continuă (poate fi parțial sau complet). Secțiunea de mai jos încearcă să
evidențieze care este nevoia companiei acum pentru a trece la CD (livrare continua –
Continuous Deployment) și beneficiile pe care le oferă.

A. Nevoile afacerii
Odată cu creșterea continuă a bazei de clienți și extinderea pe piață, devine esențial ca
procesele de livrare interne ale organizației să fie în conformitate cu așteptările de afaceri
și să fie optimizate în cea mai bună măsură posibilă. Timpul și resursele sunt constrângeri
critice în orice mediu de afaceri. Cu aceste constrângeri date, se așteaptă ca organizatiile
să reacționeze mai rapid la nevoile pieței, cu un nivel ridicat de calitate. Nici o organizație
nu își poate permite să trăiască cu activități manuale, predispuse la erori și repetate în
ciclul de viață al livrării software-ului. Anterior, echipele de proiect identifică această
nevoie precisă a afacerii și adoptă DevOps pentru a-și optimiza procesele, urmând să fie
mai profitabila.
Așa cum s-a explicat mai sus în acest articol, unul dintre domeniile care necesită în
general atenție este faza de testare a SDLC (Software Development Life Cycle),
deoarece această fază depinde de echipa de operațiuni pentru aprovizionarea hardware,
crearea de configurări de testare, menținerea mai multor combinații de produse și sisteme
de operare etc., pentru a da cateva exemple. Cireasa de pe tort este - toate aceste
procese necesită o persoană dedicată pentru a executa manual toate sarcinile de
configurare și configurarea acestor lucruri este întotdeauna imprevizibilă, mai ales din
cauza surprizelor necunoscute. Echipele trebuie să furnizeze manual aceste configurări
de testare, să se recupereze după blocările hardware-ului dedicat la momentele critice
de lansare.
Livrarea continuă încearcă să optimizeze gestionarea infrastructurii și nevoia critică de
a echilibra timpul și resursele. Validarea produselor software implică mai multe intrări
variabile, cum ar fi versiuni ale produselor, sisteme de operare diferite, versiuni diferite
ale software-ului terților etc. Nu este posibil din punct de vedere uman să testăm toate
aceste combinații și nici practic. Echipa folosește diverse metodologii de testare pentru a
optimiza matricea de testare și pentru a păstra hardware dedicat pentru anumite
configurații cheie - DAR acest lucru nu funcționează doar bine. Echipele trebuie să caute

5
Badoiu Mihail - IISC

în mod serios modalități alternative de întreținere a infrastructurii de testare și de reducere

a ciclurilor FVT generale.

B. Reducerea decalajului : studiu de caz

Există două piese cheie pentru a aborda problema de afaceri menționată mai sus - una
fiind instrumentele de automatizare a implementării (de exemplu, IBM uDeploy) și a doua
fiind furnizorul de resurse bazate pe cloud (de exemplu, IBM SmartCloud Orchestrator)
[6]. Echipele de proiect pot identifica diferitele topologii necesare testării și pot crea un
model de implementare corespunzător [4].
Nu numai să se creeze modele de implementare, ci și să se automatizeze pașii necesari
după aceea - instalarea stivei de aplicații pe imaginea furnizată în cloud, completând
datele de testare pe această imagine, declanșând suita de testare automată și împingând
rezultatele către un depozit (repository) central. Echipa trebuie să aleagă cu atenție limba
de automatizare aici (Chef / Puppet / Shell Script / Perl / Python etc.) ținând cont de
acoperirea de platformă necesară.
Odată ce această automatizare este integrată pentru a ajunge la orice configurație de
test, trebuie doar să alegeți variabila de intrare (versiune, sistem de operare etc.). Figura
3 ilustrează modul în care un utilizator selectează pur și simplu versiunea sistemului de
operare, construiește ID-ul și face clic pe implementare, care la rândul său furnizează
imaginea virtuală din cloud cu specificațiile date - totul fără nicio intervenție umană [6].
Această automatizare nu numai că ajută la reducerea ciclurilor FVT (Functional
Verification Test), ci și un alt caz de utilizare foarte important este validarea defectelor de
către dezvoltatori pe rotirile generate. În general, dezvoltatorii sunt capabili să efectueze
validările defectelor mult mai rapid, fără a fi nevoie să aștepte pentru a configura manual
hardware-ul cu cele mai recente pachete de software care au soluția în el. Cu această
automatizare, dezvoltatorii au control deplin - pentru a valida orice defect - trebuie doar
să aleagă configurarea și în câteva clicuri - vor avea o configurare și o funcționare pe
care pot valida defectul în producție, cum ar fi mediul. Nu în ultimul rând - odată terminat,
se elibereaza pur și simplu resursele de calcul - astfel încât să poată fi utilizate de oricine
altcineva.

C. Beneficii

• Economisire de timp: timpul pentru obținerea oricărei configurări de testare este

doar o chestiune de câteva minute de acțiune a utilizatorului, comparativ cu zilele
fără această automatizare.

6
Badoiu Mihail - IISC

• Nu este nevoie de ore dedicate/saptamana: nu mai este necesar să păstrați

hardware dedicat, deoarece după validare resursele cloud pot fi eliberate pentru a
fi utilizate de alții, ducând astfel la o mai bună partajare a resurselor.
• Provizionare de infrastructură fiabilă și scalabilă prin IaC: întrucât totul este
menținut ca si cod - acest cod este stocat în depozitul (repository-ul) de control al
versiunilor - întreaga automatizare este portabilă pentru orice setare (cu modificări
minime). Din moment ce este automatizată, aprovizionarea infrastructurii de
testare este acum configurată în mod constant cu succes de fiecare dată (nu mai
sunt probleme necunoscute ciudate).
• Implementarea devine un proces consecvent repetabil
• Modelul de livrare continuă permite dezvoltatorilor să obțină acces la sisteme de
producție și astfel să facă validarea într-un mediu similar producției
• Economii semnificative de costuri, deoarece echipele pot împărți rezerva de
resurse. Deoarece implementarea este automatizată aproape în cel mai scurt timp,
nu este nevoie să păstrați resursele rezervate - de îndată ce ați terminat testarea,
echipa poate elibera resursele

Fig 3 Aprovizionare automata

5. Aplicabilitate
Problemele fundamentale pe care DevOps încearcă să le abordeze sunt adaptabilitatea
la schimbare, viteza de introducere pe piață și menținerea unei calități ridicate cu costuri
reduse - care sunt probleme de afaceri universale în orice tip de proiect software.

7
Badoiu Mihail - IISC

Principiile DevOps se aplică în mod generic livrării de software și nu sunt legate de niciun
tip specific de produs sau servicii. Ele pot fi aplicate la dezvoltarea de produse complexe
la nivel de întreprindere sau la o mică aplicație web sau chiar la o aplicație mobilă. În plus,
depinde într-adevăr de nevoile proiectului, nevoile organizației, capacitățile organizației,
rentabilitatea investiției, care va determina ce abordări sau principii ale DevOps ar trebui
să adopte sau poate adopta o organizație. Nu este necesar (și nici nu ar putea fi practic)
să se treaca de la starea no-DevOps la starea completă end-to-end DevOps intr-un timp
scurt [3]. Organizațiile sau, de altfel, echipele de proiect ar trebui să analizeze și să
evalueze fluxurile de lucru actuale care sunt la locul lor și să descopere zonele în care
există o posibilitate de optimizare și care vor oferi cel mai mare ROI (Return on
Investment) și vor viza acea fază în mod izolat (ar putea fi doar 1 sau 2) abordări ale
DevOps).

6. Concluzie
Așa cum s-a explicat mai sus în această lucrare, modul în care diferitele principii ale
DevOps, dacă sunt adoptate în ciclul de viață al lansării, pot optimiza într-adevăr
capacitatea organizației de a furniza software. DevOps nu implică doar schimbarea
proceselor, ci și schimbarea culturii. Organizațiile care adoptă principiile DevOps vor avea
cu siguranță un avantaj asupra organizațiilor care nu călăresc acest val de DevOps.
Procesele trebuie să se schimbe în timp, pe măsură ce mediul de piață în care se
opereaza se schimbă continuu. DevOps permite organizației să :
• Reduca timpul de lansare pe piață
• Adapteze la feedback-ul continuu
• Echilibreze eficient costul și calitatea
• Aiba mai multă predictibilitate în versiuni
• Sporeasca eficiența organizației în ansamblu
DevOps doar definește setul de principii, dar organizația adoptă această abordare sau
principiu de „cum și folosind ce tehnologie” si este complet evaluată și decisă de
organizație. Chiar și în cadrul unei singure organizații, diferite echipe ar putea avea
nevoie să adopte diferite tehnologii sau instrumente pentru a adopta abordări DevOps -
ceea ce este absolut ok, întregul scop fiind optimizarea și transformarea continuă.

8
Badoiu Mihail - IISC

Bibliografie

[1] DevOps for Dummies – by Sanjeev Sharma

[2] Adopting the IBM DevOps approach for continuous software delivery,
http://www.ibm.com/developerworks/library/d-adoption-paths/
[3] Managing and deploying virtual system patterns,
http://www01.ibm.com/support/knowledgecenter/SS4KMC_2.3.0/com.ibm.sco.doc_2.3/t
_mana ge_patterns.html
[4] Defining DevOps, https://sdarchitect.wordpress.com/2012/07 /24/understanding-
devops-part-1- defining-devops/
[5] Understanding DevOps – Infrastructure as a Code,
https://sdarchitect.wordpress.com/2012/12 /13/infrastructure-as-code/
[6] DevOps Distilled, The Three underlying principles,
http://www.ibm.com/developerworks/libr ary/se-devops/part1/