Acesta este un articol care vine în continuarea articolului "Care sunt provocările în scenarii Dev/Test/DevOps şi cum ne poate ajuta Microsoft Azure". De data aceasta, vom intra în detalii explicând care sunt provocările atât la nivel organizațional în medii enterprise cât și la nivel tehnologic, și care sunt niște abordări, procese, și soluții coerente posibile pentru realizarea unor medii de Dev/Test eficiente.
Cele mai importante obiective ale unei strategii de Dev/Test pot fi enumerate după cum urmează:
În calea unui proces de dezvoltare software eficient pot sta câteva obstacole, unele de ordin tehnic și altele de tip organizațional.
După cum menționam în articolul referit în Introducere, separarea între echipele de dezvoltare și infrastructura poate duce la fricțiuni. Pe de o parte, echipa de dezvoltare este încetinită din cauză că durează foarte mult crearea unor medii de test/staging, etc. ; iar pe de altă parte ,echipa de infrastructură vede un impact negativ asupra costurilor infrastructurii (de care ea este responsabilă) din cauza faptului că multe astfel de medii rămân neutilizate o lungă perioadă de timp, sau sunt utilizate ineficient (24 ore pe zi, vs. 8-10 ore cât poate fi suficient).
O soluție este în mod evident echiparea echipei de dezvoltare software cu uneltele necesare creării de medii de test, în modul "self service". Atunci, ele nu mai depind de echipa de infrastructură, tot procesul este accelerat. Pe de altă parte, ele devin resposabile și de oprirea sau ștergerea mediilor atunci când nu mai sunt necesare.
Echipa de infrastructură își modifică puțin rolul: de la cei care creează medii de dev / test / staging, etc., se transformă în cei care definesc cum arată mediile respective, folosindu-se de funcționalități cum ar fi Azure Resource Manager și Desired State Configuration (mai multe în paragraful axat pe această chestiune). Astfel, echipa de infrastructură definește template-uri pentru crearea mediilor, care sunt apoi utilizate de către echipa de dezvoltare care de fapt își va crea singură acele medii.
De asemenea, echipa de infrastructură va continua să facă mentenanța și să monitorizeze mediile create în Azure, inclusiv din punct de vedere al costurilor.
Dacă în articolul precedent am arătat cum se poate realiza o soluție foarte simplă de Continuous Integration cu ajutorul Visual Studio Team Services, pentru realizarea de medii dev / test în Azure, acum vom arăta un scenariu mai complex.
Atunci când discutăm despre soluții enterprise, ele sunt mult mai elaborate decât o aplicație web legată la o bază de date. Vorbim despre arhitecturi complexe, care se mapează fizic pe medii la fel de complexe: mai multe layer-e, mașini virtuale (VMs) sau instanțe de Platform as a Service aflate în spatele unui Load Balancer, Load Balancers interne (pentru apeluri între layer-e), mecanisme de tip reliable messaging (Service Bus sau Storage Queues), servicii de caching, rețele locale (Vnets), eventual conectivitate printr-un VPN din biroul firmei la Vnetul din Azure, restricții de securitate (Network Security Groups - NSG), etc.
Din experiența noastră, tocmai această complexitate a mediilor în care trebuie să ruleze soluțiile, deci și cele de dev / test / staging șamd, duce la un proces de dezvoltare extrem de încetinit. Pentru că nu este deloc ușor să creezi repede (a se citi automatizat) și în mod garantat identic astfel de medii la orice oră din zi sau din noapte.
Microsoft Azure vine cu modul său extrem de inteligent de a crea resurse în Cloud: Azure Resource Manager. Practic, noi putem specifica sub forma unui fișier JSON din ce este compus un mediu (adică un Resource Group în termenii Azure), iar ARM este responsabil de crearea tuturor componentelor pe baza acelui JSON.
De exemplu, un mediu de producție pentru un SharePoint Farm nu este un mediu foarte simplu. Realizarea lui componentă cu componentă este un proces care poate presupune multe greșeli, însă realizarea unui template JSON garantează crearea unui mediu identic de fiecare dată când este nevoie. Acestea ar putea fi componentele unei soluții SharePoint în Azure:
Template-ul JSON poate fi vizualizat aici. Fișierele JSON pot ajunge foarte complexe și deci supuse erorilor, tocmai de aceea există o unealta specializată în editarea lor din Visual Studio:
Un proces de CI poate fi redat în schema următoare:
Etapele BUILD și RELEASE din VSTS sunt cele explicate în articolul precedent. Următoarele etape sunt mai interesante pentru soluțiile complexe.
Aceasta e etapa în care din VSTS se declanșează crearea mediului din Azure, și unde se folosește template-ul JSON, fie că vorbim despre mediu Dev, sau Test, sau Staging, șamd. . Rezultatul acestei etape este un Resource Group creat în Azure, care este gata pentru a se instala acolo soluția popriu-zisă.
După ce avem un RG cu toate componentele necesare putem instala soluția, eventual cu tot ce e nevoie să fie configurat pe VMs dpdv prerequisites.
Un mecanism extrem de util este Desired State Configuration (DSC). Cu ajutorul DSC, putem specifica modul în care să arate VMs și nu să rulăm scripturi PowerShell de exemplu, sau orice altceva procedural, care instalează / configurează câte un element la un moment dat. Pur și simplu se specifică starea în care ar trebui să fie fiecare VM din RG-ul nostru, iar acesta își va "reface" starea imediat după pornire sau atunci când dorim noi să declanșăm acest lucru.
Există două modalități de a "reface" starea unui VM pe baza DSC:
Un aspect foarte relevant al utilizării DSC pentru a instala prerequisites pentru VMs: atunci când avem de-a face cu aceleași VMs în mai multe medii: Dev, Test, Staging, Production - și toate aceste prerequisites sunt grupate în fișierele DSC. Practic toată informația legată de ce trebuie să fie instalat și configurat pe fiecare VM pentru ca soluția să poată rula, este grupat în aceste DSC-uri.
O altă nuanță foarte relevantă: de câteva ori am constatat în diverse companii o problema majoră legată de lansarea unei versiuni noi în producție. Anume:
Problema: având în vedere că mediul de producție este la client (extern sau intern), cum ne asigurăm că realizăm un mediu de Staging identic? Evident că în practică acest lucru nu se realizează și se ajunge la a încerca crearea unui mediu de Staging cât mai apropiat de cel de producție. Ceea ce înseamnă că testarea va avea de suferit.
Cu ajutorul mecanismelor de tip DSC, reunite sub denumirea de Infrastructure as Code, se poate proceda altfel: pornind dinspre firma de software care știe cu exactitate care este mediul propice pentru soluție, se livrează clientului atât soluția cât și fișierele DSC necesare pentru a configura VM-urile în mod identic cu mediul Staging. Practic Production va fi identic cu Staging, totul realizându-se foarte simplu din punct de vedere tehnic.
Există provocări de nivel organizațional. Nu întotdeauna este simplă influențarea infrastructurii clientului. Probabil, cheia aici este explicarea în termeni clari de costuri și beneficii, de ce e bine ca el să își creeze infrastructura soluției pornind de la DSC-urile firmei de software, astfel fiind și el sigur că obține un mediu recomandat și suportat, scăzând și la el costurile de mentenanță și accelerând foarte mult punerea în producție a unei versiuni noi.
Atunci când instalăm soluția într-un mediu Dev / Test dorim să notificăm persoanele interesate atunci când operațiunea s-a încheiat: release manager, tester, etc. .Confirmarea poate să fie sub forma unui e-mail în care tester-ul are URL-ul aplicației care trebuie testată și alte informații utile. Exemplu:
Evident, tester-ii lucrează de la birou, iar soluția a fost instalată în Microsoft Azure. Este nevoie ca tester-ii să poată accesa în mod securizat diversele componente ale soluției supuse testării. O opțiune simplă este realizarea unei conexiuni de tip Site to Site între rețeaua locală de la birou si VNET-ul din Azure, tester-ii văzând soluția la IP-uri locale (ca în figura de mai sus), precondiția fiind că toate RG-urile (mediile) din Azure sunt parte ale aceluiași VNET. Schematic, lucrurile arată așa:
Cu ajutorul Azure Resource Manager, JSON templates, și PowerShell Desired State Configuration, putem realiza strategia de Dev/Test pentru soluții oricât de complexe din punct de vedere arhitectural. Iar DSC este util și pentru replicarea setărilor necesare mediilor Dev/Test spre producție. În acest fel, se reduce foarte mult timpul de migrare la o nouă versiune a soluției.
Pentru mai multe informații, vizitați: