ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 44
Abonament PDF

Care sunt provocările în scenarii Dev/Test/DevOps şi cum ne poate ajuta Microsoft Azure

Mihai Tătăran
Microsoft MVP , Co-organizator @ ITCamp, GM @ Avaelgo
PROGRAMARE

Î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.

Diviziunea între echipele de dezvoltare / testare pe de o parte, și cele de infrastructură pe de altă parte. 

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:

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.

Costul mediilor de testare

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.

Constrângeri de business

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.

Soluții folosind Cloud

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.

Pierderi mai puține

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.

Cum ne ajută Microsoft Azure

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.

Azure Automation 

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.

Concluzii 

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:

LANSAREA NUMĂRULUI 87

Prezentări articole și
Panel: Project management

Marți, 24 Septembrie, ora 18:00
Impact Hub, București

Înregistrează-te

Facebook Meetup

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects