Mediile de deployment si ciclul de viata al unui release software (SRLC)
In industria IT&C, produsele software sunt aduse la viata in urma mai multor procese, cicluri si etape destul de bine stabilite la nivel general, care pot fi insa particularizate de la caz la caz. Nicio aplicatie nu apare din neant, la modul simplist: acuma am codat, vedem daca porneste si imediat e livrata clientilor.
In practica acest lucru e imposibil, toate aceste procese fiind de durata, implicand multe resurse, de timp, bani si munca. In continuare vom vedea cum se pune in miscare un produs software, prin ce etape trece acesta pana ajunge la clientul final si care sunt mediile de deployment (implementare) folosite dupa diferitele necesitati (development, testare etc.).
Ciclul de viata al unui release software (Software release life cycle)
Munca si dezvoltarea produselor in IT se bazeaza, dupa cum am mai vazut, pe diferite procese si cicluri care se pun in aplicare de fiecare data cand e nevoie. Sunt extrem de putine lucruri/ actiuni care se realizeaza la modul simplist, o data si gata; cele mai multe sunt definite ca niste procese cu etape bine definite. In trecut am mai discutat despre SDLC (Software development life cycle) si STLC (Software testing life cycle).
Si partea de lansare propriu-zisa a unei aplicatii, denumita in mod uzual release, este de fapt un proces asemanator cu SDLC sau STLC, numit Software release life cycle (SRLC). Acesta constituie acea suma de pasi prin care un produs software (aplicatie de mobile, website etc.) este pus in functiune si devine un lucru util din punct de vedere tehnic si cu valoare comerciala.
Acest ciclu de viata este extrem de important deoarece pe el se bazeaza modul de lucru a numeroase echipe si companii de IT atunci cand planuiesc pe termen mediu sau lung sa lanseze un produs software pentru clienti sau o versiune mai noua si mai imbunatatita a unei aplicatii deja existente.
Principalele avantaje ale SRLC sunt acelea ca ofera o perspectiva mai ampla de lucru asupra modului de release prin care o aplicatie prinde viata si ajunge la client, si previne eventualele probleme de la o etapa la alta. Mai precis, daca se descopera o eroare, ea poate fi prevenita in etapele initiale, pana sa ajunga la clientul final, acesta din urma bucurandu-se de cea mai buna si mai stabila versiune posibila.
Dezavantajul care decurge din natura acestui ciclu de release cu multe etape este tocmai durata acestuia. Nimic nu se face peste noapte, intr-un mod grabit, ci asezat si analitic, acordandu-se atentie la fiecare pas, ceea ce necesita destul de mult timp.
Etapele principale ale unui software release
Un software release se bazeaza, dupa cum am afirmat anterior, pe mai multe etape. De mentionat inca din acest punct ca numarul acestor etape si denumirile lor pot sa difere mai mult sau mai putin de la un caz la altul, de la o echipa de lucru la alta, de la o companie de IT la alta, nefiind neaparat ceva super rigid, ci adaptabil, precum metodologiile de lucru (Agile).
In continuare vom vedea care sunt etapele generale ale SRLC, si ce sa intampla in fiecare dintre ele.
1. Pre-alpha
Prima etapa a ciclului de viata al unui release software este denumita generic ”pre-alpha”, ca urmare a faptului ca precede etapa urmatoare, cea de alpha (ajungem imediat si acolo).
Aceasta etapa de pre-alpha este caracterizata de toate acele activitati incipente care au loc cand se incepe lucrul pe un produs/ versiune nou(a), si anume: elaborarea de documentatii tehnice, stabilirea in scris a cerintelor tehnice (requirements) ale produsului, elaborarea schitelor de design, codarea propriu-zisa realizata de developeri, uneori chiar si partea de unit testing.
Practic, zona de pre-alpha reprezinta santierul initial al proiectului, etapa cand se pun bazele acelui produs sau versiuni, pana cand se ajunge la o formula cat de cat inchegata si organica intre diferitele sale componente.
2. Alpha
A doua etapa, dupa cum am anticipat anterior, este cea de Alpha. In aceasta etapa produsul software la care s-a muncit initial in pre-alpha prinde un contur bine delimitat si incepe sa fie folosit ca atare. Aici inca suntem intr-un mediu intern al echipei/ companiei, in-house, unde doar cei care lucreaza la acel produs au acces, nu si clientii.
O diferenta extrem de importanta care se manifesta acum, in etapa de Alpha, este ca de acum incepe procesul de testare propriu-zis pe acea aplicatie sau versiune mai noua. Practic, acuma se incepe folosirea acesteia de catre testeri cu scopul de a identifica cat mai din timp eventualele bug-uri critice, astfel incat sa fie fixate de programatori. Corectarea acestora este esentiala, deoarece sunt prevenite de a ajunge in etapele urmatoare, unde deja incep sa fie implicati si utilizatorii finali.
3. Beta
Dupa ce am trecut de primele 2 etape de constructie si initiere a produsului software, urmatoarea etapa care urmeaza de regula in acest ciclu este Beta. In aceasta etapa, se continua testarea si corectarea eventualelor bug-uri care nu au fost descoperite in Alpha, astfel incat calitatea finala a produsului sa fie cat mai mare si sa satisfaca cerintele clientului.
Ceea ce deosebeste de regula etapa Beta de Alpha este ca din acest moment, pe langa echipele de development care lucreaza in continuare la acest produs, au acces la el si anumiti clienti. Atentie, nu toti clientii, ci doar o parte dintre ei.
Mai precis, anumiti customeri fie se ofera voluntari sa incerce, fie sunt ofertati sa ia parte la programul de Beta al acelei aplicatii si sa il incerce in real-life, asumandu-si eventualele defecte pe care le gasesc, cu scopul de a fi identificate si corectate. Acest lucru se mai cheama si Beta testing, o testare care implica partial si ajutorul userilor finali, care folosesc aplicatia cat mai aproape de realitate, simuland diferite scenarii de unde pot rezulta (sa nu) bug-uri.
4. Release Candidate
Dupa ce se incheie etapa de Beta unde in continuare s-a lucrat la produs, dar a inceput sa fie folosit si de catre anumiti useri non-tehnici, se ajunge la stagiul de Release Candidate. Practic, aceasta este o etapa intermediara, exact punctul de dinaintea lansarii in productie pentru toti potentialii clienti si utilizatori ai produsului software respectiv.
Se considera ca daca acea aplicatie sau versiune a ajuns in etapa de Release Candidate (RC), atunci se afla intr-un stadiu tehnic foarte bun, au fost implementate toate feature-urile necesare, si suspusa unui tir riguros de testare in toate etapele precedente (unit testing in pre-alpha, alpha si beta testing de catre QAs si beta users), si nu prezinta bug-uri semnificative care pot impacta critic alti clienti.
Produsul continua sa fie monitorizat pentru a nu aparea alte probleme pe parcurs, si se pregatesc de etapa urmatoare, cea care incununeaza acest ciclu de release software.
5. GA / Release to Production
Dupa un lung drum cu multe etape in care s-au investit resurse considerabile de timp, bani si munca, ajungem la marea lansare. Produsul nostru software ajunge in etapa de General Availability, unde absolut toata lumea care doreste poate accesa produsul cel nou sau versiunea mai noua. Aceasta etapa poate fi la randul ei sub-impartita in mai multe etape, totul depinzand de natura proiectului, a modului de lucru din compania respectiva etc.
Practic, acuma vorbim de un release to Production (RTP), de o lansare oficiala in mediul de productie, unde doar versiunile cele mai stabile, bine dezvoltate si testate isi au locul, astfel incat utilizatorii sa se bucure de cea mai buna calitate. Tot din acest punct, produsul are valoare comerciala, putand fi vandut si aducand venituri dezvoltatorului.
Mediile de deployment pentru development si testare
O componenta extrem de utila de cunoscut in zona software atunci cand sunt concepute si dezvoltate noi produse este reprezentata de mediile de implementare, sau deployment environments.
Concret, acestea sunt niste spatii virtuale in care sunt deployate, adica puse ”in miscare”, sunt lansate live pentru functionare si utilizare diferite versiuni ale aplicatiilor dezvoltate, pentru a putea executa anumite sarcini, in functie de necesitatile proiectului. Aceste medii de deployment corespund aproximativ si cu etapele unui release software, in totul depinde de natura proiectului si de mediul de lucru.
Aceste medii de lucru ajuta extrem de mult cand vine vorba de a vedea stabilitatea unei versiuni si a o testa intr-un mod cat mai relist si eficient, pentru a i se descoperi bug-urile critice. Necesitatile proiectului se pliaza si ele pe diferitele medii de deployment ale unei aplicatii, fie ca vorbim de partea de development, cand se dezvolta si implementeaza concret functionalitati noi, fie ca vorbim de testarea intr-o anumita faza a proiectului. Sa vedem la nivel general care sunt aceste medii.
1. Development environment
Primul mediu unde se poate implementa prima data versiunea unei aplicatii este mediul de dezvoltare (Development environment). Acesta este locul unde programatorii au libertatea sa lucreze la implementarea noilor functionalitati, sa incerce live diferite lucruri si sa vada daca functioneaza conform cerintelor tehnice.
Practic, mediul de dezvoltare este locul unde o aplicatie este construita pas cu pas, si este implementata pentru prima data, pentru a o vedea cum se comporta initial. Acesta este un mediu restrans, in-house, de regula doar developerii au acces la el, functionand ca un sandbox de lucru in timp real.
2. Stage / Staging environment
Al doilea mediu principal de deployment folosit in dezvoltarea produselor software este cel de Stage, sau Staging environment. Acesta reprezinta o copie 1-la-1, cat mai fidela, a mediului de Productie, unde aplicatia va fi implementatat live pentru viitori utilizatori.
Astfel, in Stage/ Staging, produsul nostru este lansat pentru a putea fi in principal testat cat mai mult si mai eficient, pentru a il putea vedea ”pe viu” cum se comporta si ce poate face la nivel practic. De regula in acest mediu se relizeaza ciclurile de testare, pentru a nu impacta mediul de lucru al programatorilor si nici pe cel de productie unde au acces majoritatea clientilor.
De multe ori fazele de release se intrepatrund cu mediile de deployment. Astfel, poate uneori este nevoie sa ”testam un Release Candidate pe Staging”. Ce inseamna asta mai exact? Versiunea cea mai stabila a produsului software, care a fost dezvoltat si testat riguros si care are titlul de Release Candidate este deployat (implementata live) in mediul de Stage/ Staging, pentru a putea fi testat si aici.
In acest context acel RC poate fi observat cat mai bine, deoarece mediul de Staging asta trebuie sa faca, sa simuleze cat mai precis mediul de productie, de la servere si pana la baze de date, astfel incat sa fie preintampinate eventualele probleme pentru clienti.
Uneori exista un mediu de deployment separat pentru testare (Testing environment) intre cel de development si cel de Stage, insa nu e o regula, aceste medii fiind si ele adaptate in functie de specificul echipei si al companiei.
3. Production environment
Al treilea si cel mai important mediu de deployment care se foloseste de catre toate companiile din IT este mediul de Productie (Production environment). Aceste este cel mai important deoarece in acest mediu este implementata live aplicatia finala, la care au acces toti utilizatorii si care genereaza venituri pentru compania respectiva.
Acest mediu este si cel mai stabil, dar trebuie sa fie si cel mai sigur din punct de vedere al securitatii informatice, pentru a nu periclita datele si actiunile clientilor. Ca un best practice, se recomanda pe cat posibil evitarea testarii in productie, tocmai pentru a nu exista riscul de impactare a utilizatorilor finali.
Concluzii
In incheiere, trebuie reamintit faptul ca dezvoltarea, lansarea si implementarea produselor software se bazeaza pe procese si cicluri cu etape bine definite la nivel conceptual. Un release software prezinta mai multe etape care se parcurg succesiv si din care rezulta lansarea unei aplicatii sau versiuni mai noi.
De asemenea, in functie de necesitatile proiectului vis-a-vis de dezvoltare sau testare se folosesc trei medii de deployment la nivel general, Development/ Stage/ Production. Chiar daca reprezinta notiuni putin mai avansate, este bine sa le cunoastem chiar si la inceputul carierei in testare sau programare, pentru ca inevitabil ne vom lovi de ele in task-urile de zi cu zi din IT.
Surse consultate si suplimentare
Detalii despre Software Release life cycle gasesti 👉 aici, 👉 aici si 👉 aici.
Detalii despre deployment environments gasesti 👉 aici, 👉 aici si 👉 aici.
Sursa imaginii despre deployment environments + un articol despre subiect de la Jira.
