În ziua de azi, majoritatea companiilor de dezvoltare software se confruntă cu o serie de provocări atunci când trebuie să asigure într-un mod coerent medii sau infrastructuri pentru scenarii de test, demo, staging, pre-producție și așa mai departe.
De obicei, cu cât organizația este mai mare cu atât observăm un grad mai ridicat de specializare, și evident echipe mari și separate de dezvoltare, de testare pe de o parte sau de infrastructură și administrare de sistem pe de altă parte. Iată un scenariu aproximativ (și exagerat în mod intenționat pentru a sublinia problema) care este destul de des întâlnit:
Echipa de dezvoltare cere un mediu / o infrastructură pentru a testa o versiune nouă a unei soluții. Poate fi pentru test, pentru staging, pre-production, etc.
Echipa de infrastructură primește cererea, probabil sub forma unui ticket sau service request prin unealta internă de gestionat astfel de cereri. Cererea este direcţionată automat sau parţial automat către persoana care se ocupă cu rezolvarea ei.
Mediul de test este creat și echipa de dezvoltare este notificată.
Echipa de dezvoltare constată că mediul nu este conform cu așteptările sale. Poate lipsesc mașini, poate nu sunt configurate cum trebuie, etc. .
Se reia cererea, cu toți pașii, până mediul este conform cu ceea ce dorește echipa de dezvoltare.
Se folosește mediul respectiv: echipa de QA execută testele, se face un demo la client, etc. .
Pe de o parte echipa de dezvoltatori consideră (pe bună dreptate) că durează foarte mult până li se pune la dispoziție un mediu de testare- am întâlnit cazuri când dura 3-4 zile- , iar pe de altă parte echipa de infrastructură este nemulțumită pentru că trebuie să asigure mentenanța unor medii care nu mai sunt necesare fără a ști care sunt acelea.
A avea zeci de mașini virtuale care nu sunt utilizate presupune un cost inutil. Uneori avem tendința de a crede că odată realizată investiția inițială în infrastrcutura fizică (servere, rețea, etc.), nu vom avea alte costuri cu mașinile virtuale deservite de aceasta, neglijând costurile de operare / mentenanță, costul cu energia și costul de oportunitate: faptul că pe un server stau degeaba niște mașini virtuale înseamnă că nu pot sta unele de care chiar e nevoie.
O altă situație mult mai frecventă este cea a unor medii de testare utilizate periodic pentru un interval limitat de timp, dar create și care rulează tot timpul. Pe scurt: e nevoie de medii de testare care să fie disponibile non-stop? Facem testare în weekend? Facem în timpul zilei și în timpul nopții? Cu niște proceduri foarte simple și puțină automatizare (a se citi scripting), e foarte simplu să ajungem la costuri de 40-50% sau mai mici din cele care presupun rularea non-stop a acestor medii.
Tot mai multe companii dezvoltă soluții în modelul SaaS (Software as a Service), ori pentru produsele proprii, ori pentru beneficiarii lor.
Livrarea versiunilor noi de software în modelul SaaS a modificat complet indicatorii de succes care trebuie urmăriți, unul dintre cei care au devenit foarte importanți fiind "time to market" sau intervalul de timp de livrare către client, scurs de la momentul t0 când clientul a cerut o nouă cerință. De asemenea, poate în strânsă legătură cu "time to market", se observă o modificare a ritmului în care apar versiuni noi. Dacă în modelul tradițional de licențiere software on premises apăreau versiuni noi odată la șase luni sau mai rar, acum este foarte des întâlnită o frecvență de release o dată la două săptămâni sau chiar mai puțin.
În aceste condiții devine evident de ce a aștepta 3-4 zile pentru crearea unei infrastructuri de test este uneori chiar imposibil.
Odată cu apariția serviciilor de tip Cloud și în special a celor publice foarte relevante (Microsoft Azure, Amazon), rezultă posibilități noi de creare a unor infrastructuri sau medii temporare, în special datorită unor atribute ale Cloud-ului.
Self-service
Toate serviciile de tip Public Cloud se pot activa într-o manieră de autoservire. Este perfect normal ca echipa de dezvoltatori să creeze propriile mașini virtuale (și tot ce e nevoie în jurul acestora) pentru mediile lor temporare. Eventual cu ajutorul echipei de infrastructură, care poate să definească și apoi să forțeze niște constrângeri și politici care să țină costurile sub control. Însă nu mai este nevoie de know-how-ul specific administratorilor de sistem pentru a crea medii temporare.
Elasticitatea
Cloud-ul prin definiție este elastic. Adică este foarte ușor să scalăm, să adaugăm sau să scădem mașini virtuale care compun un mediu de test, și care cu siguranță sunt identice cu cele existente deja.
Rapiditatea
Crearea (provisioning) de mașini virtuale durează foarte puțin. De exemplu în Microsoft Azure, crearea unui VM durează mai puțin de 10 minute, crearea a 10 VMs durează tot 10 minute, iar crearea a 100 de VMs la fel. E foarte greu să creezi într-o infrastructură locală zeci de mașini virtuale identice în câteva minute de fiecare dată când e nevoie.
Azure îți dă posibilitatea de a controla foarte bine costurile asociate unor mașini virtuale sau a unor medii. Există mai multe mecanisme, printre care Azure Automation și Azure DevTest labs prin care pur și simplu mașinile virtuale se închid la anumite ore (ceea ce reduce costul de rulare al mașinilor la 0), sau prin politici care limitează crearea de mașini virtuale de anumite dimensiuni (ceea ce limitează costul de rulare).
Reutilizarea
Este foarte simplu în Azure să creezi o mașină virtuală sau un mediu complex și apoi să îl recreezi de câte ori ai nevoie într-un mod garantat identic. Aceasta în special cu ajutorul Azure Resource Manager și modelul de templates, practic fișiere JSON care descriu mediul pe care ni-l dorim în final în loc de o serie de comenzi procedurale care pleacă dintr-o stare și prin pași succesivi ne dau în cele din urmă un rezultat. Acest mecanism de template-uri se înscrie foarte bine în paradigma Infrastructure as Code, alături de PowerShell DSC (Desired State Configuration), prin care personalul care creează infrastructură lucrează cu ea așa cum programatorii lucrează cu codul sursă, sau cu alte cuvinte prin care niște nespecialiști în infrastructură (programatorii) pot să creeze infrastructuri complexe.
Atunci când vorbim despre Dev/Test cu Azure, mai întâi trebuie menționate uneltele și tehnologiile care ne ajută în tot procesul de dezvoltare, Continuous Delivery și Continuous Integration. Anume, Microsoft ne pune la dispoziție Team Foundation Server (TFS) - o soluție on premises sau Visual Studio Team Services (VSTS, fostul Visual Studio Online), care este o versiune simplificată a TFS livrată pe modelul SaaS.
Utlimele updates ale VSTS ne-au adus câteva îmbunătățiri majore în special în relația cu Azure.
Build
Realizarea de build-uri a unei soluții administrate cu VSTS a devenit din ce în ce mai simplă de-a lungul anilor. Recent, VSTS ne dă posibilitatea de a realiza build în Cloud, pe mașini (agenți) disponibile pentru acest lucru undeva în Azure. Acest lucru presupune pur și simplu realizarea unei conexiuni între VSTS și o subscripție de Azure (de exemplu una inclusă în licențele MSDN), iar build-urile comandate se vor realiza pe infrastructura din Azure. Practic aceasta ne scutește de necesitatea unor mașini specializate în propria infrastructură pentru a realiza build-uri.
În figura alăturată putem observa definiția unor pași de realizat la Build. De exemplu: Build efectiv, urmat de copierea unor fișiere (output-ul de la build) undeva în Cloud, și ultimul pas rularea unor teste automate (care presupune că soluția noastră conține un proiect de testare care să conțină unit tests).
Release
Cu ajutorul VSTS putem realiza release-uri, declanșate de exemplu de apariția unui nou build sau la cerere, utilizând tot mașini (agenți) din Azure. Practic, eliminăm necesitatea unor mașini locale pentru a depune acolo ultimele versiuni de aplicație necesare pentru QA / testare sau pentru realizarea unui demo la client.
În figura alăturată sunt prezentați câțiva pași posibili: deployment efectiv într-un Azure Web App, apoi rularea automată a unor teste (de exemplu load tests), și în fine realizarea unui deployment cu ajutorul Azure Resource Manager, pe baza unui template JSON.
TFS și Release Manager
VSTS este totuși un serviciu relativ limitat pentru scenarii complexe de continuous delivery. De aceea, versiunea on premises cu TFS reprezintă o soluție foarte bună.
Alături de TFS se poate utiliza Release Manager, un produs separat din lista de unelte Microsoft pentru Dev/Test, care ne ajută în special pentru a defini workflow-uri de Build, Test, Release, etc.; a defini medii de test complexe, și nu în ultimul rând a defini medii de test cu ajutorul Azure. Practic, putem defini: mediul "Dev" care presupune realizarea unor build-uri și rularea unor unit tests, să fie local pe o mașină din biroul nostru, iar mediul "Staging" să fie construit cu ajutorul unor VMs din Azure.
Este un serviciu care ne ajută să definim scripturi PowerShell și intervale regulate de timp sau condiții care trebuie îndeplinite pentru rularea automată a acestora.
Automation este extrem de util atunci când avem nevoie de mașini de test sau de medii oricât de complexe (VMs, subnets, load balancers, etc.) care să pornească automat atunci când este nevoie de ele și să se oprească singure după ce nu mai sunt necesare. Ca exemplu, se poate implementa următorul scenariu:
La ora 10:00 se pornește mediul de test.
La ora 18:00, și numai după ce toată activitatea din acel mediu a încetat (de pildă dacă avem server web, acesta să nu proceseze request-uri active, sau dacă nu se mai rulează teste automate), se închide mediul de test.
Acest serviciu vine ca o mănușă peste modelul de preț al lui Azure: mașinile virtuale se plătesc per minut de rulare. Prin urmare în exemplul de mai sus, cu VMs rulând între 10 și 18 doar în zilele săptămânii scădem costurile cu infrastructura aceasta temporară la mai puțin de 25% decât dacă VMs ar rula non-stop.
Dev Test Labs
Ultimul dar nu cel din urmă serviciu Azure care merită menționat pentru scenariile Dev/Test este, după cum îi și spune numele, Dev Test Labs.
Încă un serviciu aflat în preview își propune:
Crearea rapidă de medii temporare (test, staging, etc.) folosind VMs.
Folosind template-uri JSON cu ajutorul Azure Resource Manager, template-uri utile pentru reutilizare și pentru specificarea cât mai simplă (în special pentru programatori) a unei infrastructuri complexe.
Pe VM-urile create se pot adăuga extrem de simplu Artefacte. Acestea pot fi: agenți, unelte, programe, etc. sau chiar și niște comenzi împachetate sub forma unor scripturi, care să fie pe VM-ul respectiv după crearea acestuia. De exemplu, avem nevoie de o mașină virtuala Windows Server 2012 R2, cu Fiddler, Git, Visual Studio Test agent instalate pe ea. Pur și simplu selectăm acele artefacte din listă, și VM-ul nostru le va avea după instalare.
Minimalizarea de costuri prin diverse politici cum ar fi: numărul maxim de VMs per utilizator, numărul maxim de VMs per laborator (o entitate care trebuie definită explicit), sau tipuri de mașini virtuale care pot fi create. De exemplu, utilizatorii să nu poată crea (din greșeală să spunem) VMs cu mai mult de patru procesoare.
Microsoft Azure în combinație cu Visual Studio Team Services sau Team Foundation Server și Release Management, ne asigură posibilitatea de a crea medii de test / staging / pre-production rapid, la costuri mici si controlate. Și, mai ales, fără a fi nevoie de cunoștințe avansate de infrastructură, prin urmare rezolvând diviziunea între echipele de dezvoltare și de infrastructură prin simplul fapt că echipa de dezvoltare poate să devină responsabilă de crearea, rularea și oprirea mediilor acestea temporare, cu ajutorul administratorilor de sistem doar în ceea ce privește realizarea de template-uri respectiv stabilirea de cote și politici pentru un control bun al costurilor.
Pentru mai multe informații, vizitați:
de Ovidiu Mățan
de Cristina Juc
de Ioana Luțaș
de Ovidiu Mățan
