De ce avem nevoie de mai multe medii?
Înainte de a explora Deployment Pipelines, este esențial să înțelegem de ce sunt necesare mai multe medii într-o implementare Power BI. Pentru a ilustra acest aspect, să luăm un scenariu ipotetic:
S-o cunoaștem pe Gabi, un Power BI Developer din echipa de Data Analytics a organizației sale. Echipa sa creat un workspace dedicat rapoartelor de vânzări (Sales), iar Gabi are sarcina de a-și publica rapoartele, modelele semantice și dataflow-urile în acel workspace. Alți membri ai echipei de data analytics au și ei acces de editare în acest workspace.
De asemenea, există câțiva utilizatori de test care folosesc același workspace pentru a examina rapoartele și rezultatele lor. Utilizatorii finali (end users) se conectează la acest mediu prin workspace-ul partajat.
Structura generală arată astfel:

Principala problemă a modului de lucru prezentat anterior constă în faptul că orice modificare făcută de echipa de dezvoltare îi afectează atât pe utilizatorii de test, cât și pe utilizatorii finali, chiar dacă schimbarea nu este încă finalizată. Acest lucru poate genera experiențe frustrante pentru utilizatori și poate afecta încrederea lor în rapoarte.
Pentru a remedia această situație și a păstra o experiență cât mai bună pentru utilizatorii finali, echipa de analiză poate folosi Power BI Apps. Situația actuală, odată cu folosirea unei aplicații (App), arată astfel:

Echipa de Data Analytics a creat un workspace dedicat rapoartelor de vânzări, în care Gabi publică rapoarte, modele semantice și dataflow-uri. Alți membri ai echipei de Data Analytics au, de asemenea, acces de editare în acest workspace. În același spațiu de lucru, câțiva utilizatori de test evaluează rapoartele și rezultatele acestora.
În paralel, utilizatorii finali se conectează la acest mediu printr-o aplicație (App) asociată workspace-ului.
Această configurație folosește un singur workspace atât pentru colaborarea dintre dezvoltatori (Gabi și echipa de Data Analytics), cât și pentru utilizatorii de test. Pentru utilizatorii finali, se folosește o aplicație bazată pe acest workspace. Astfel, deși dezvoltatorii și utilizatorii finali sunt separați, nu există o separare clară între dezvoltatori și utilizatorii de test. Acest lucru devine problematic când dezvoltatorii lucrează la noi funcționalități (nefiind încă pregătite pentru testare), în timp ce utilizatorii de test încearcă deja să evalueze conținutul și se confruntă cu rezultate neclare sau incomplete, ceea ce poate produce confuzie și frustrare.
Pentru a evita astfel de situații, este necesară o separare completă a mediilor de lucru.

Prezentare generală a configurării cu mai multe medii
Această configurare presupune existența unui mediu Test, cu workspace-ul aferent, și a unui mediu Live (numit și Production sau Prod), care are propriul workspace și propria aplicație. Separarea intenționată dintre cele două medii are scopul de a reduce riscul ca modificările neintenționate să afecteze alte medii. Prin izolarea clară a fiecărui mediu, flexibilitatea și ușurința de modificare sunt semnificativ îmbunătățite.
Practica de a folosi mai multe medii este larg recomandată în cadrul sistemelor software. Abordarea recunoaște diferitele roluri ale utilizatorilor dintr-o organizație și evidențiază importanța segmentării mediilor pentru a asigura fiabilitatea procesului de schimbare. În cele din urmă, acest mod de lucru contribuie la adoptarea lină a sistemului software în întreaga organizație.
Implementarea Deployment Pipelines în Power BI
(cunoscută și ca Continuous Integration / Continuous Delivery – CI/CD)
Atunci când sunt stabilite mai multe medii, apare necesitatea unui sistem de identificare a fiecărui mediu, care nu poartă întotdeauna denumiri clasice precum Test, DEV, PROD etc. De asemenea, devine esențială și o abordare sistematică de transfer al conținutului dintr-un mediu în altul (de exemplu, din Dev în Test). Este crucial să poți compara conținutul dintre medii, să detectezi schimbările și să faci o implementare selectivă a acelor modificări. De pildă, poți examina mediile Test și Live pentru a identifica rapoartele modificate.
În plus, poate fi necesară ajustarea conexiunilor în acest proces, cum ar fi asocierea modelului semantic din Test la sursa de date de test și a celui din Live la sursa de date live. Gestionarea mai multor medii implică numeroase cerințe. Practic, devine indispensabil un instrument dedicat pentru a coordona publicarea (deployment) conținutului în multiple medii, iar aici intervine Deployment Pipeline.
Deployment Pipeline din Power BI este o componentă integrată a Power BI Service, destinată să faciliteze administrarea mai multor medii. Funcționalitățile sale permit:
- Definirea și organizarea fiecărui mediu
- Alocarea workspace-urilor mediilor respective
- Compararea conținutului a două medii
- Implementarea schimbărilor
- Menținerea unui istoric de implementare
- Revenirea la o versiune anterioară, dacă e nevoie
- Modificarea conexiunilor în timpul procesului de implementare
și multe altele.
Pentru organizațiile care lucrează cu multiple medii în Power BI, Deployment Pipelines reprezintă un instrument valoros, utilizat în principal de echipa de deployment, care, în general, este o subgrupă a echipei de Data Analytics.
Notă: Deployment Pipeline este o funcționalitate disponibilă în licențele Power BI Premium.
Crearea Deployment Pipelines
Pentru a iniția crearea unui nou Deployment Pipeline, ai la dispoziție două opțiuni: poți utiliza butonul Create Pipeline situat în panoul principal, așa cum se vede în imaginea de mai jos:

Alternativ, se poate crea un pipeline direct din workspace, după cum se vede în exemplul de mai jos:

Odată ce pipeline-ul a fost creat, pasul următor este să stabilești câte medii ar trebui să conțină. Configurația implicită include trei medii, așa cum se poate observa mai jos:

După crearea mediilor dorite, fiecare mediu trebuie asociată cu un workspace specific.

Odată workspace-ul atribuite , vei putea vedea o listă a tuturor artifactelor existente în acel workspace.

Implementarea (deploy) inițială către următorul mediu
În acest moment, utilizatorii pot fie să aloce un nou workspace pentru etapa Test din pipeline, fie să aleagă opțiunea de deploy, prin care Power BI va genera automat un nou workspace pentru etapa Test.

După implementare (deployment), artefactele din mediul Development sunt copiate în mediul Test.

Totuși, este important de reținut că, deși rapoartele pot fi consumate în mediul Development, încercarea de a le accesa în mediul Test va genera erori.



Aceste erori apar deoarece, în timpul implementării (deployment) în următorul mediu, sunt copiate doar metadatele, niciodată datele efective. Drept urmare, modelul semantic din mediul Test rămâne gol și nu poate afișa nicio vizualizare. Prin urmare, imediat după implementarea inițială, pasul următor obligatoriu este să declanșezi un refresh al modelului semantic proaspăt implementat.
Implementarea schimbarilor
Când ambele medii sunt sincronizate, indicatorul se afișează în verde.

Totuși, dacă apar modificări într-una dintre medii, apare un indicator galben, semnalând o diferență clară între definițiile artefactelor.

Mai mult, pentru modelele semantice, ai posibilitatea de a verifica în detaliu diferențele specifice.

Poți apoi decide ce artefacte să copiezi în următoarul mediu și să realizezi procesul de deployment.
Atunci când implementezi conținut dintr-un mediu sursă către un mediu țintă, conținutul sursă suprascrie orice element cu același nume din mediul țintă. Conținutul din mediul țintă care nu există în mediul sursă rămâne neschimbat în mediul țintă.

Important!
La fel ca în cazul implementării inițiale, orice implementare ulterioară copiază exclusiv metadatele și nu include datele efective.
În consecință, în funcție de modificările efectuate, poate fi necesară reîmprospătarea (refresh) modelului semantic în mediul țintă.
| Tip de artefact | Ce a fost adăugat sau modificat | Este necesar refresh? |
|---|---|---|
| Model semantic | Măsură (Measure) | Nu |
| Model semantic | Coloana calculată sau tabel calculat | Da |
| Model semantic | Relație | Da |
| Model semantic | Sursă nouă | Da |
| Raport | Orice | Nu |
Ca bună practică, se recomandă să efectuezi toate modificările în mediul de dezvoltare înainte de a propaga schimbările prin implementare în mediile ulterioare. Pentru a consolida această practică, rapoartele implementate folosind Power BI Deployment Pipelines nu pot fi descărcate ulterior.
Surse de date diferite pentru fiecare mediu
Existenta unor medii distincte poate implica și utilizarea unor surse de date diferite în fiecare workspace – de exemplu, un fișier sau o bază de date pentru dezvoltare, altul pentru testare și, în final, un set de date de producție pentru mediul Production. Configurarea mai multor surse pentru fiecare set de date nu este, în sine, un lucru complicat; provocarea reală constă în faptul că, în timpul implementării prin Deployment Pipelines, informațiile de conexiune sunt replicate, fiind parte integrantă a metadatelor implementate.
Pentru a rezolva această problemă, Power BI Deployment Pipelines include logica de deployment rules (reguli de implementare). Poți seta astfel de reguli pentru dataflows, modelul semantic, datamarts și Paginated Reports. Pentru a accesa această funcționalitate, în interiorul pipeline-ului, selectează mediul țintă și apasă butonul:


Există două modalități de a configura deployment rules:
- Reguli pentru sursa de date (Data source rules)
Din lista surselor de date, selectează numele sursei de date care trebuie actualizată. Folosește una dintre următoarele metode pentru a alege valoarea care va înlocui sursa din etapa sursă:- Selectează din listă
- Selectează „Other” și adaugă manual noua sursă de date. Poți schimba sursa de date doar cu una de același tip.

- Reguli pentru parametri (Parameter rules)
Selectează un parametru din lista de parametri; valoarea curentă este afișată. Editează valoarea cu cea pe care vrei să o aibă efect după fiecare implementare.

Lasă un comentariu