Ce reprezinta on-demand feature environments?
Modul general in care se lucreaza in industria IT este in mod fundamental unul bazat pe diferite procese si metodologii, cu etapele lor consacrate si bine fundamentate. Desigur, acestea sunt adaptabile de la o situatie si de la o echipa la alta, insa nucleul teoretic este acelasi de la care se pleaca.
In trecut a mai fost abordata ideea potrivit careia dezvoltarea produselor software presupun utilizarea mai multer etape si medii de development si testare, pentru a putea crea, rafina si corecta acel feature in cel mai calitativ mod cu putinta.
In continuare, vom aborda un subiect tot din aceasta categorie a mediilor speciale cu care se opereaza in IT, si anume on-demand feature environments.
Scurta trecere in revista a mediilor de development si testare
Dupa cum aminteam, in IT pentru a putea dezvolta un produs, trebuie respectate etapele (sau ciclul de viata) unui al release software (Software release life cycle sau SRLC). Acestea sunt in umar de 4 sau 5, in functie de cum e reglementata treaba in compania respectiva, si pornesc de la o etapa de pre-alpha, mergand pana la release-ul acelui produs in Productie, la clientii finali.
Pentru a putea lucra in cele mai bune conditii si a nu asuma riscuri inutile, in fiecare etapa este nevoie sa se foloseasca un anumit mediu de lucru (environment). De regula, developerii au un mediu al lor in care dezvolta acel produs sau functionalitate specifica, iar testerii au un mediu al lor dedicat pentru testarea acestuia, inainte de a-i aproba lansarea in Productie, mediu numit de cele mai multe ori Staging sau Stage.
Pentru detalii mai amanuntite si surse suplimentare pe acest subiect, pe blog am scris articolul despre Mediile de deployment si ciclul de viata al unui release software (SRLC), ce poate fi consultat oricand.
Ce reprezinta on-demand feature environments?
Pentru a putea intelege mai usor ce reprezinta acest tip de mediu, trebuie sa ne reamintim flow-ul clasic al unui produs software. Foarte pe scurt, dupa ce dezvolta ideea, cerintele tehnice si design-ul respectivului produs / feature, se trece la etapa de development.
Aici, programatorii codeaza si pun in practica tot ceea ce se cere prin documentatia tehnica prestabilita, cautand sa asigure deci implementarea tehnica a cerintelor de business. Toate acestea au loc in development environment. Ulterior, dupa ce programatorii termina de codat respectivul feature, se construiesc build-urile de test ale aplicatiei si se face un deploy in mediul de testare, adica in Staging.
Aici intervin inginerii QA care verifica si valideaza ceea ce s-a cerut prin documentatia tehnica initiala, daca s-a implementat si functioneaza cum e de asteptat, daca nu atunci se raporteaza bug-urile si se intoarce la developeri.
In acest flow clasic, mediul de Staging este unul singur, unitar, in care este deployat un singur build / o singura versiune a produsului dezvoltat, care contine inclusiv precedentele functionalitati deja integrate si lansate pentru clienti, in Productie.
Acum, avand aceasta imagine, putem explica mai usor ce reprezinta on-demand feature environments. Aceste „medii la cerere pentru caracteristici”, intr-o traducere mai libera, reprezinta o alternativa la mediul obisnuit de testare Staging pentru QA, o formula mai granularizata in care pentru fiecare feature se creeaza un mediu propriu de testare in cadrul Stage-ului, care contine doar acel feature si atat, fara alte componente deja existente si deployate.
Flow-ul de development si testare folosind on-demand feature environments ar arata in mod ideal astfel. Dupa ce programatorii termina de codat, acel feature este construit intr-un build special al aplicatiei si deployat intr-un mediu de testare individual, unic, in care este lansat strict acel feature pentru a fi testat independent de restul componentelor aplicatiei.
Acest mediu de testare la cerere poate purta si o denumire unica, pentru a fi deosebit de restul mediilor pentru celelalte componente care se afla in lucru. Testerii intervin, testeaza tot ce trebuie testatat, si dupa ce se face merge la acel branch de pe GitHub care contine codul acelui feature, se face deploy in Productie prin procesul de CI / CD, iar acel on-demand feature environmnet este automat sters, facand loc altora noi.
Avantaje si dezavantaje ale on-demand feature environments
In mod cert, on-demand feature environments reprezinta un mod diferit de a aborda testarea unui anumit produs software, fie ca vorbim de o aplicatie intreaga sau un feature specific. Nu mai avem un mediu unitar de testare, ci mai multe instante diferite in cadrul acestuia in care „traieste” fiecare feature dezvoltat in parte. Aceasta abordare prezinta, ca orice alta metodologie sau mod de lucru, avantaje si dezavantaje.
Din perspectiva avantajelor, principalul beneficiu ce se poate observa la folosirea mediilor de testare de tip on-demand feature este acela al rapiditatii cu care se poate livra un anumit feature, ceea ce implicit poate sa reduca anumiti timpi si anumite costuri. Imediat cum modificarile de pe branch-ul programatorului sunt transpuse in GitHub prin git push, se instanteaza automat un mediu on-demand cu numele acelui feature sau cu ID-ul tichetului din Jira si imediat se poate incepe testarea. Dupa ce e validat, este automat merge-uit in branch-ul Master si apoi livrat prin CI / CD in Productie, deci un proces super rapid si automatizat.
Un alt avantaj este aceea ca testarea prin on-demand feature environments poate duce la evitarea anumitor blocaje in testare, mai ales daca acel feature este unul mai special, care nu e destinat sa ajunga la toti userii, ci numai la o parte dintre acestia. Astfel, acel feature poate fi testat asa cum este el, fara a se face disable la alte caracteristici din aplicatie cu care s-ar putea bate cap in cap, si daca exista bug-uri, atunci programatorul il poate livra direct facand un commit pe branch care ajunge astfel automat si in mediul dedicat de testare.
De asemenea, folosindu-se aceste medii de test izolate de-a dreptul, e si mai usor pentru developeri sa experimenteze in timp real, sa vada care optiuni sunt cele mai bune dintr-o gama mai larga pentru a implementa cat mai corect si fiabil o caracteristica de aplicatie noua, si care ulterior sa fie testata fara alte dependinte.
Pe de alta parte, exista si dezavantaje semnificative ale mediilor on-demand feature. Primul si probabil cel mai important este acela ca desi noile functionalitati pot fi testate izolat, mai rapid si fara sa depinda de alte proprietati ale aplicatiei, se evita astfel testarea de integrare a acestui nou feature cu altele existente deja, si se trece de la o perspectiva unitara la cea End-to-end, dar care nu implica si alte flow-uri hibride.
Acest lucru este riscant din perspectiva faptului ca utilizatorii nu vor folosi acel feature izolat, ci in cadrul aplicatiei, si exista deci sanse serioase ca in utilizarea lor de zi cu zi sa foloseasca diferite componente in maniere destul de originale si diferite fata de cum sunt ele gandite si testate in aceste medii la cerere.
Tot ca un dezavantaj vine si faptul ca pentru a putea implementa din punct de vedere tehnic, este necesara o infrastructura de operatiuni si cloud destul de serioasa, care trebuie realizata intr-o maniera cat mai omogena si functionala, pentru a asigura fluiditatea acestui mod de dezvoltare si testare a diferitelor produse software. Si aici vorbim de costuri semnificative, dar putem admite ca se vor compensa partial cu cele economisite de la partea de livrare efectiva, insa acest aspect tine si el de extrem de multi factori, precum activitatea companiei si produsele reale pe care le livreaza.
Daca mediul unitar de Staging are un defect, atunci acel defect se va resfrange asupra tuturor feature-urilor deployate ulterior acolo, iar testarea va fi astfel viciata, constituind un alt deficit major care poate produce riscuri.
De ce ar fi nevoie de acest tip de medii?
Cu siguranta implementarea si folosirea de on-demand feature environments nu este deloc ceva strain, dar reprezinta un subiect foarte interesant ce merita o abordare proprie. Ele reprezinta o alternativa destul de viabila la mediul clasic si unitar de testare Staging, unde absolut toate caracteristicile noi se testeaza la gramada, existand atat beneficii clare, dar si dezavantaje semnificative.
Personal, consider ca cea mai buna abordare se afla in calea de mijloc dintre cele doua modele propuse de mediul de lucru din IT. Nu orice feature nou dezvoltat merita un mediu dedicat de testare, asa cum a avea un singur mediu de testare poate fi uneori deficitar si poate ingreuna procesul de testare al echipei respective.
O abordare mai sigura atat din punct de vedere tehnic, cat si financiar si metodologic ar fi aceea in care exista un mediu unitar de Staging, unul general in care sa se faca deploy la build-urile finale ale aplicatiei si unde sa se execute testele de integrare si End-to-end.
Aici se verifica aplicatia exact in forma finala in care va ajunge la clienti, dar sa existe si posibilitate de a putea crea on-demand feature environments pentru acele functii mai specifice, care nu vor ajunge automat la toti utilizatorii si care eventual trebuie si livrate mai rapid din ratiuni de buisness sau securitate.
Concluzii
In incheiere, on-demand feature environments reprezinta o maniera de lucru putin mai diferita in industria software, fiind o alternativa interesanta si cu certe avantaje (si dezavantaje la pachet) pentru testarea si intelegerea noilor functionalitati ce trebuie sa ajunga cat mai repede la testare si apoi in Productie.
Nu exista neaparat o modalitate 100% corecta care sa reprezinte adevarul absolut in ceea ce priveste dezvoltarea, testarea si ulterior lansarea unui nou produs, acestea se stabilesc la nivel de echipa / companie. Insa este important sa cunoastem cat mai multe modele de lucru si alternative, pentru a fi in stare sa analizam si sa decidem care este solutia cea mai buna, care sa asigure calitatea maxima si un nivel de test coverage cat mai bun.
Surse pe subiect
Ce reprezinta la nivel general on-demand feature environments si care sunt fundamentele sale
Un articol mai tehnic despre implementarea unor astfel de medii dedicate pe features
Despre Feature Flags in development
O analiza a problemelor pe care le au mediilor de testare
Postare pe LinkedIn despre “Environment On Demand” With Modern Infrastructure
Mediile de deployment si ciclul de viata al unui release software (SRLC)
