În ultima perioadă suntem bombardați din toate părțile de ideea că trebuie să începem să folosim Continuous Delivery (Livrare Continuă), adică să începem să punem aplicația mai repede în producție și cu frecvență mai mare. Da, într-adevăr, să mergem live cu aplicația în producție de zece ori pe zi e distractiv și cool. Dar atunci de ce am avut nevoie de aşa mulţi ani? Livrarea continuă este menționată încă din primul principiu agil:
Prioritatea noastră este satisfacția clientului prin livrarea rapidă și continuă de software valoros.
Contează pentru că toată lumea face sau pentru că este distractiv și interesant? Nu aceasta este abordarea corectă. În tot ceea ce facem trebuie să ne asigurăm de ceea ce este corect pentru companie, trebuie să înțelegem ce trebuie făcut și poate cel mai important lucru este cum putem să aducem valoare companiei.
Prin acest articol intenționez să prezint de ce este important ca oamenii de business să fie de acord cu livrarea în mod continuu, care sunt diferențele dintre aceasta și alte practici și cum să începem a o realiza. Pe lângă toate cele de mai sus, vor fi observații cu privire la contextul dezvoltatorilor software din outsourcing, mediu care este considerabil diferit.
Uitându-ne la știrile din mediul IT apar tot mai multe instrumente care să faciliteze accesul în etapa numită livrare în mod continuu. Când voi putea să învăț toate aceste instrumente dintre care menționez câteva precum puppet, chef, varant, Go CI? Și mai mult, cine ne va pune la dispoziție timp pentru a le integra în proiectele noastre care sunt deja în urma față de planificarea managerilor noștri.
Eu cred că trebuie să ne întrebăm ce vom câştiga prin a implementa primul dintre principiile agile, iar răspunsul este feedback. Pentru a ne asigura că recunoaştem valoare aşa cum este specificat în primul principiu, trebuie să învățăm ce înțeleg clienții și business-ul prin valoare, exact la fel cum facem și cu atributele de calitate. De fapt, în acest context valoare este calitate și vice-versa. De ce trebuie să recunoaștem valoarea? Deoarece trebuie să ne dăm seama când am reușit să o atingem sau măcar cât mai avem nevoie până o vom atinge.
Dar de ce afirm toate aceste lucruri? Pentru că am văzut o mulțime de prezentări, bloguri, filme în ultima vreme care omit întru totul să menționeze că nu doar tu, gurul tehnic, trebuie să înveți ce presupune livrarea continuă ci și oamenii de business. Dar dincolo ce surprind aceste prezentări, ese important de subliniat că tu, omul tehnic, poți face ceva pentru a schima lucrurile.
Este necesară utilizarea și a practicilor de integrare continuă și deployment continuu pentru a avea success în practica de livrare continuă, dar de foarte multe ori oamenii folosesc termenul continuous delivery când se referă la continuous deployment, iar mai jos vă voi arăta ce înțeleg eu prin acești termeni.
Continuous Integration, Martin Fowler
Integrarea continuă este practică a dezvoltării software în care membrii unei echipe integrează ceea ce livrează des, de obicei fiecare persoană integrează munca proprie cel puțin o dată pe zi - ceea ce conduce la mai multe integrări pe parcursul unei zile.
Continuous Delivery vs. Continuous Deployment, Martin Fowler
Livrarea continuă se referă la ideea că aplicația este în permanent într-o stare în care poate fi pusă în producție. Deployment continuu este de fapt punerea în producție a aplicației la fiecare schimbare de cod, în fiecare zi sau chiar mai des.
Atunci când am citit primul fragment mi-am spus: "Interesant, deployment continuu e mai bun decat livrare continuă!" și acum câțiva ani s-ar putea să fi avut dreptate. Jez Humble a spus la un moment dat că livrarea continuă nu are nevoie de deployment continuu, iar vice-versa nu e neapărat adevărat. Însă acum eu cred că este mai important să fii alături de business, iar utilizarea de deployment continuu doar în mediul de acceptanță nu este suficientă. A acorda businessului dreptul de a pune aplicația în producție este ceea ce înseamnă de fapt livrare continuă. Chiar mai mult, unele companii au diminuat rolul sau chiar îndepărtat întru totul mediul de acceptanță, punând aplicația direct în producție, doar cu o testare minimă din partea developer-ului - ceea ce pentru mine înseamnă că cei doi termeni au fuzionat, motiv pentru care mă simt mai în largul meu să utilizez termenul de livrare continuă.
Și totuși, ce ar putea face un dezvoltator care lucrează într-o firmă de outsourcing? De cele mai multe ori nu are acces la oamenii din business, în cel mai bun caz poate doar acces limitat, pentru că de cele mai multe ori interacționează cu analiști funcționali. Până recent am crezut că este suficient să faci curățenie în curtea proprie și că atunci când cei din jurul tău vor vedea că modificarea aduce o îmbunătățire, atunci se vor schimba și ei, în consecință îmbunătățind întreaga companie. Și nu este chiar greșit, dar ideea are o capcană: aduce cu adevărat valoare dacă eu îl văd ca un beneficiu? Probabil de multe ori nu suntem oameni tehnici, de multe ori am petrecut ore în șir șlefuind într-un diamant o porțiune de cod care deja funcționa. Util pentru business poate ar fi fost ca acel cod să ruleze deja în producție.
Consider că trebuie să întrebăm oamenii din business care sunt valorile pe care ei le urmăresc în luarea deciziilor. De fapt noi facem acest lucru deja atunci când întrebăm despre atributele de calitate. Dacă ai fost la unul din cursurile lui Tom Gilb cu siguranță ești deja convins că primul lucru pe care trebuie să îl faci este să întrebi businessul care sunt primele lor zece valori; și ne vom focaliza asupra soluției care va avea ROI-ul cel mai mare (ROI - return of investment), o vom implementa, după care trecem la următorul, și următorul și tot așa.
Urmând practicile agile, în principal utilizând Scrum și Kanban, suntem obișnuiți cu expresia definiție pentru terminat, în engleză definion of done, pentru user stories. Definiția o folosim pentru ca între membrii echipei și stakeholder-ii proiectului să avem aceeași înțelegere asupra a ce trebuie realizat pentru ca un item de pe backlog să fie cosiderat complet. Îmi aduc aminte că atunci când am început practicarea Scrum credeam că un item complet reprezenta ce trebuia să fac pentru ca un user story să fie acceptat de către Product Owner. După câteva sprinturi am învățat să înțeleg prin terminat tot ce trebuia să fac pentru ca story-ul să ajungă în producție; până la urmă Scrum precizează "la calitatea potențial livrabilă", lucru care atunci când mă uit în trecut însemna de fapt terminat în contextul integrării continue.
Mai târziu, pe lângă eforturile de a practica integrarea continuă, ne-am uitat și la modalități de unificare a deployment-ului aplicațiilor în diferite medii. Era un dezastru total, noi - echipa de dezvoltare nearshoring - eram responsabili pentru deployment-ul și stabilitatea aplicației pe mediul de testare și acceptanță, în timp ce echipa de întreținere era responsabilă de infrastructură și deployment în producție.
Dar, pe măsură ce timpul a trecut, am început să unificăm procedurile de instalare și de împărțire a responsabilităților între echipe; noi, dezvoltatorii, cream artefactele pentru o versiune a aplicației, adică din instrumentul de integrare continuă produceam artefacte care nu depindeau de mediul în care vor fi puse, în timp ce echipa de întreținere se ocupa de instalare în toate mediile, rezolvând în același timp și configurările care depindeau de mediu. Trebuie să recunosc că nu a fost deloc ușor, am avut "câteva" probleme: de exemplu adăugarea unei noi configurări dar, în cele din urmă, am ajuns să lucrăm mai aproape cu echipa de întreținere, unii ar putea chiar zice că am ajuns să lucrăm împreună. Și așa am reușit să împingem înțelesul termenului terminat și mai departe: terminat - ca și instalat în producție, în mâinile utilizatorilor.
Recent am auzit o prezentare a lui Adrian Cockcroft, ex-architect șef la Netflix, în care spunea că pentru ei cod terminat, adică software terminat, e atunci când este retras din producție. Ceea ce înseamnă că responsabilitatea noastră ca implementator nu se termină atunci când am scris codul și acesta a ajuns pe mediul de acceptanță sau chiar producție; ci terminat înseamnă a avea grijă de software pe întreaga lui viață: atunci când îl creăm, atunci când rulează, având grijă să fie în condiții optime de memorie sau CPU, făcând mentenanță, îmbunătățindu-l de fiecare dată când are nevoie, iar la final, atunci când îl retragem din producție într-un mod controlat.
Dacă ne uităm la principile Lean, vom vedea că acestea nu sunt deloc diferite față de ce am prezentat mai sus: utilizarea de iterații, cu incremente mici de la ideea de business la client, folosind feedback-ul din utilizarea produsului și adaptându-l, crescând funcționalitatea în mod organic.
La finalul fiecărui ciclu echipa trebuie să livreze un increment, dar trebuie ales cu atenție ce alegem deoarece trebuie să începem cu cel care aduce cea mai multă valoare utilizatorilor. Atunci când este utilizat obținem feedback prin utilizarea unor metrici și învățăm, după care decidem ce urmează să construim. Nu spun că trebuie să astepți câteva săptămâni fără să faci nimic pentru a obține valori realiste în urma măsurătorilor, trebuie să ai munca planificată în avans, dar atunci când gândești funcționalitea trebuie să folosești ceea ce ai învățat de la utilizator. Iar atunci când observi ceva problematic în producție, ceva ce afectează utilizatorii, poți mult mai repede să identifici proactiv, amânând munca mai puțin prioritară și să fixezi problema. Este important să realizăm că expresia de incremente mici nu se referă neapărat la perioada de timp, ci la cantitatea de modificări, cu alte cuvinte trebuie să acorzi atenție la volumul de muncă pe care îl faci în paralel (WIP - work in progress).
Un alt principiu al gândirii line este de a creea calitate în tot ceea ce faci, build quality in. Nu vei putea pune în mâinile businessului butonul cel mare și rosu: "Deploy Now!" fără a avea mecanisme automate de a valida calitatea produsului. Iar pentru aceasta va trebui să înțelegi ce înseamană calitate pentru business. Să nu cazi în capcanele comune: ce ințelegi tu prin calitate nu e neapărat ce businessul înțelege prin ea. Calitatea nu este la fel pentru două produse, chiar și pentru același client. Calitatea costă - așadar identifică pragul la care ea trebuie livrată. Înțelesul calității s-ar putea schimba de-a lungul evoluției sistemului. Așadar mergi la business și întreabă care sunt calitățile pe care și le doresc de la produs, defineștele împreună cu ei într-un mod cuantificabil și construiește mecanisme automate care să verifice că sistemul respectă nivelul pentru fiecare atribut de calitate identificat.
Important în gândirea lină este și eliminarea surplusului, a muncii în zadar, adică identificarea părților care încetinesc sau îngreunează ritmul de muncă sau a părților care nu aduc valoare sistemului. În momentul în care ai un proces pe care îl urmărești și măsurători prin care să obții feedback și cu ajutorul cărora să înveți, vei putea cu ușurință să identifici care parte a sistemului sau procesului te încetinesc sau te limitează. Odată identificată, este evident că nu merită să acționezi în altă parte, orice îmbunătățire în alte locuri are drept cauză acumularea de și mai multă muncă în zona problematică.
Decide cât mai târziu! Pentru a lua decizii bune e nevoie să ai informații detaliate despre domeniul respectiv, ceea ce înseamnă timp, adică bani. În consecință vei dori să amâni momentul luării deciziei până când este cu adevărat critic. Prin aceasta vei reduce riscul de a lucra în zadar, deoarece nu mai este nevoie sau odată cu trecerea timpului informațiile tale asupra problemei s-au modificat. Trebuie însă să avem grijă să nu ajungem la paralizie-prin-decizie, deoarece nu avem suficiente informații pentru a lua o hotărâre.
După cum am menționat în mai multe rânduri până în acest punct, în Lean este important actul învățării, atunci când luăm decizii sau atunci când prioritizăm. Cu alte cuvinte înseamnă că trebuie să ne uitam la trecut și să învățăm atât din greșeli cât și din sucese. Așa că pe lângă măsuratorile pe care le pui pentru aplicație și pentru modul de lucru, organizează mecanisme prin care să asiguri învățarea continuă. Review-ul sprintului, cunoscut și ca demo sau retrospectivele sunt un bun început, deoarece ele asigură feedback pentru produs și respectiv modul de lucru, însă sunt multe altele pe care ai putea să le faci. De exemplu uită-te la eșecurile din producție și organizează post-mortem-uri nu pentru a atribui vina, ci pentru a învăța din greșeli și a nu le repeta. Nu te limita prin a te uita doar în mediul proiectului tău, uită-te la întreaga organizație, la ce se întâmplă în industrie; dar, nu uita: nu face lucrurile doar pentru că și alții le fac, aplică soluții pentru că înțelegi care sunt beneficiile în contextul tău. Pe lângă nevoia de a învăța suntem responsabili și de a transmite și altora ce am învățat.
Ultimul aspect dar nu mai puțin important este că în Lean avem nevoie de o echipă cu putere de decizie. O echipă trebuie condusă, nu micro-manageriată pe parcursul întregului proces de implementare; lasă membrii echipei să se organizeze singuri, ai încredere în ei că vor face tot ceea ce este în puterile lor, iar dacă au nevoie de ajutor îl vor cere. Ca manager al echipei fă un pas în spate și asigură-te că există imaginea de ansamblu iar ceea ce face echipa e în concordanță cu planul, vezi care sunt impedimentele echipei, ajută echipa să le conștientizeze și să le înlăture.
Așadar, livrarea continuă reprezintă producerea de valoare pentru business prin software de calitate în cicluri rapide, cu incremente conținând puține modificări, observând efectele modificărilor și utilizând feedback pentru a îmbunătăți produsul și procesul de creare al acestuia. Sunt un mare fan al dezvoltării condusă de testare, folosesc această tehnică de fiecare dată când ajung să codez, indiferent de limbajul de programare pe care îl folosesc: java, nodejs, xquery pentru development pe Marklogic, javascript pentru dezvoltare pe client, sau chiar bash pentru scripturi de instalare – mă axez inițial pe ce vreau să obțin, cum îl voi utiliza, creez metode de testare după care implementez. Dar TDD e doar primul nivel la care putem obține feedback, utilizând livrarea continuă asigurăm un ciclu acțiune -> răspuns la nivel de business, iar pentru a reuși avem nevoie de colaborare între oamenii de business și oamenii tehnici.
Până în acest punct am descris în principal de ce și cum adoptarea practicii de livrare continuă ajută o organizație, sau în conextul outsourcing-ului, organizația clientului și a aceluia care dezvoltă software prin crearea unui parteneriat centrat pe câștigul ambelor părți. În această secțiune vom analiza principiile și practicile.
În primul și primul rând trebuie să creăm un proces de deployment repetabil, pentru a ne asigura că avem un proces în care să avem încredere. Pentru a obține acest lucru vom începe prin a observa cum o idee de business, o funcționalitate, ajunge la utilizator. Să nu cumva să credem că aceasta se rezumă doar la a alege un story, în a-l implementa și a-l pune în producție. Nu! Trebuie să ne uitam la întregul drum pe care o funcționalitate îl are: din momentul în care ia naștere, cum este definit, prioritizat față de alte funcționalități, cum se alege echipa care îl va implementa, cum se asignează resursele, cum se planifică munca și doar după toate acestea ne uităm la implementare. La început va fi amețitor volumul de informații și haosul care acum va fi aparent. Creează board-uri pentru fiecare stream, în care fiecare pas va reprezenta o coloană, iar cel mai important va fi să urmezi principiile lean și agile.
Atunci când ai harta pe care o funcționalitate o străbate pentru a fi implementată, identifică zonele care încetinesc ritmul de muncă de la un stadiu la altul și, mai mult, înțelege de ce. Acestea sunt punctele în care vei dori să acționezi în primul rând. Pentru a le îmbunătăți încearcă să reduci sau elimină ceea ce nu aduce valoare, iar ceea ce rămâne trebuie automatizat - rezultatul va fi o muncă mai rapidă și mai de încredere.
Pentru că vom dori să folosim cicluri rapide, prin care să obținem seturi de modificări mai mici, atunci când ceva se strică, vom putea cu ușurință să vedem ce s-a modificat de când funcționa totul corect. Pentru a obține aceast lucru va trebui să versionam totul, nu doar codul, ci și configurările, cerințele funcționale, scripturile de instalare, API-urile, și orice altceva ne-am putea gândi; chiar mai mult, ar fi util să putem să relaționăm modificările între ele.
Dacă o activitate este dureroasă, atunci cu atât trebuie făcută mai des. Am putea începe cu procedura de deployment, dar nu se limitează doar la aceasta. Gândește-te la problemele ce pot apărea în producție, poți organiza exerciții pentru a repeta procedura de recuperare în diferite scenarii de failure, în acest mod vei putea fi pregătit pentru momentul în care o situație reală va apărea, mai mult, cu timpul vei avea mai multe cunoștințe despre procedură și o vei putea automatiza. După cum cei de la Netflix au făcut cu Chaos Monkey, care oprește aleatoriu noduri în producție și monitorizează stabilitatea sistemului, și mai târziu cu întreaga Symian Army, care oprește instanțe la diferite nivele ale infrastructurii.
Cu toate cele menționate mai sus, nu poti spune "gata, am terminat!". Pentru că toate fac parte dintr-o muncă continuă și trebuie să vezi cum poți îmbunătăți fiecare pas.
Noi suntem doar oamenii tehnici, ce am putea face noi? O dată ce ne-am asigurat că suntem aliniați cu cei din business, că ne orientăm eforturile pe lucrurile care aduc cu adevărat valoare, e nevoie și să creăm suportul pentru tot ce e menționat mai sus. Cu alte cuvinte vom implementa un deployment pipeline.
Un deployment pipeline este spargerea procesului de construire în mai mulți pași independenți. În urma fiecărui nou pas creștem încrederea în noua versiune, de obicei cu costul trecerii timpului. Pașii de la început vor găsi majoritatea problemelor, conducând la feedback rapid, iar pașii ulteriori vor folosi tehnici de sondare.
Nu vom reuși niciodată să dovedim că un soft nu are bug-uri, dar putem încerca să prindem cât mai multe dintre ele.
Recomandarea mea este să începeți prin a identifica pipeline-ul pe care îl aveți momentan. Sunt sigur că există unul, încercați să îl vizualizați - folosind kanban boards; vedeți unde se acumulează munca, identificați cum este prioritizată munca în aceste locuri, ce tipuri de muncă sunt practicate.
Asigurați-vă că dețineți tot ce poate avea trasabilitate: cod, configurări, scripturi de asamblare și instalare, sau chiar artefactele care sunt produse în procesul de asamblare și împachetare.
În momentul în care ai toate cele de mai sus, un următor pas ar fi standardizarea deployment-ului: adică compilarea și asamblarea artefactelor o singură dată, după care instalarea lor în oricare dintre medii se face cu aceleași scripturi sau mecanisme. Ceea ce înseamnă că artefactele vor fi independente de mediul de rulare, configurările sunt și ele trasabile, iar construirea și instalarea este automatizată și identică în oricare dintre medii: dev, test, acceptanță, pre-producție și chiar și producție. Acestea ajută deoarece la fiecare pas creștem nivelul de încredere în noua versiune care acum se trece prin pipeline. Ceea ce am putea numi generic: deployment pipeline instance.
În paralel putem să ne asigurăm că avem pași automați care să crească nivelul de încredere în calitatea versiunii; și că pașii manuali sunt pe cât posibil spre capătul pipeline-ului. Ai putea începe prin a încerca testarea de acceptanță automată sau testare de integrare a API-urilor expuse și chiar mai multe unit teste. Nu trebuie să acoperi întreaga aplicație de la început, începi cu testele care validează flow-urile critice, după care alte părți cu risc ridicat, încerci să acoperi cât mai mult atât pe verticală cât și pe orizontală în funcție de gradul de risc.
Pe lângă aceasta ar fi bine să nu uitam de Continuous Integration, care este prima poartă pe care un build trebuie să o treacă, aici putem crește acoperirea cu unit teste, analiza statică dar cel mai important e să avem marje pe care build-ul trebuie să le treacă.
După toate acestea te poți ocupa ca deployment pipeline-ul să fie automatizat: în momentul în care un nou set de modificări este comis în version control, întreaga instanță este pornită, iar în momentul în care un pas a trecut automat vom trece la următorul. După cum am sublinat în mai multe rânduri trebuie identificat ce ne îngreunează procesul pentru a-l putea ameliora. De fapt, munca ta pe pipeline nu se termină niciodată, atunci când ceva pică, vezi care este cauza și dacă ai fi putut să o prinzi mai repede. Adaugă noi pași în pipeline atunci când este nevoie.
De asemenea, să nu cumva să îți imaginezi că vei opri toate proiectele din business timp de 6 luni și să lucrezi doar pe acest nou și interesant proiect tehnic. Compania ta trebuie să supraviețuiască, nu există butonul de pauză. Pipeline-ul trebuie construit împreună cu proiectele existente din business, iar la fiecare pas nou adăugat trebuie să se vadă valoarea imediată și să se includă costul în bugetul proiectelor.
În ISDC avem IDAM, ISDC Defined Agile Model, suntem un grup de oameni care încearcă să ajute ISDC-ul în calitatea ei de companie precum și echipele de development din ISDC să fie mai bune în ceea ce fac prin urmarea principiilor agile. În urmă cu ceva timp ne-am uitat la cum practicarea livrării continue ar putea ajuta proiectele și pe clienții noștri. Pe lângă recomandările pe care le-am avut, am creat și o imagine, o hartă a practicilor pe care le-am identificat la momentul respectiv. Nu este varianta ideală, nici ce mai bună, de fapt nici măcar o recomandare, ci mai degrabă e un meniu ca la restaurant, din care fiecare trebuie să ne alegem ce avem nevoie în funcție de riscurile pe care le avem, adică ce ne ajută pe noi.
Unii proabil cred că ceea ce am relatat în acest articol e doar o poveste frumoasă. Eu însă consider că pentru a putea aduce cu adevărat valoare businessului și nu doar frumusețe tehnică, trebuie să fim conștienți de toate acestea.
Cu toate acestea, nici un sfat teoretic nu se compară cu experiența practică. Datorită posibilelor diferențe de percepție, promit că voi reveni în unul din numerele următoare pentru a prezenta un caz practic de trecere a unui proiect la continuous delivery. Voi avea ocazia de a expune uneltele folosite și beneficiile obținute și, nu în ultimul rând, care sunt practicile recent descoperite sau lecțiile învățate.
de Ovidiu Mățan
de Dan Suciu
de Ovidiu Mățan
de Sorina Mone
de Ovidiu Mățan
