Le deployment pipeline sono lo strumento nativo di Microsoft Fabric per gestire il ciclo di vita del contenuto (ALM) e implementare pratiche di CI/CD promuovendo gli item attraverso ambienti isolati, senza esportare o ricreare manualmente report, semantic model, lakehouse, notebook o data pipeline.
Struttura a stage
Una pipeline è composta da una sequenza di stage, ognuno collegato a un workspace distinto assegnato a una capacity Fabric. La configurazione tipica prevede tre stage:
- Development — dove i team costruiscono e iterano sugli artefatti.
- Test — dove si eseguono validazioni, QA e collaudo con dati rappresentativi.
- Production — l’ambiente consumato dagli utenti finali.
Gli stage sono personalizzabili: puoi rinominarli, ridurli o aggiungerne (fino a dieci) per modellare scenari con più anelli di validazione. Per operare servono il ruolo Admin sul workspace e capacity assegnata a entrambi i workspace coinvolti.
Confronto e promozione selettiva
Prima di ogni promozione, la pipeline mostra il confronto tra stage adiacenti, evidenziando gli item New, Different o Same. Questo diff ti permette di capire esattamente cosa cambierà prima di agire. Da qui puoi scegliere tra:
- Deploy all — promuove l’intero contenuto dello stage sorgente.
- Deployment selettivo — spunti solo gli item da promuovere (utile per rilasciare un singolo report o semantic model senza trascinare modifiche non ancora pronte).
Durante la promozione Fabric applica l’auto-binding: le dipendenze vengono ricollegate automaticamente agli item corrispondenti nello stage di destinazione (ad esempio un report si rebinda al semantic model del workspace di Test, non a quello di Dev).
Deployment rules e parametri
Il problema centrale è che ogni ambiente deve puntare a risorse diverse: il lakehouse di Dev, il server SQL di Test, il warehouse di Prod. Le deployment rules risolvono questo disaccoppiando configurazione e contenuto, così non devi mai modificare a mano l’item dopo la promozione.
Data source rules e parameter rules
- Data source rules — rimappano la sorgente dati di un semantic model o dataflow (es. dal server di sviluppo a quello di produzione) al momento del deployment.
- Parameter rules — sostituiscono il valore dei parametri definiti nell’item (connection string, nome database, endpoint, path del lakehouse) con il valore corretto per quell’ambiente.
Definire i parametri già in fase di modellazione (in Power Query, nel semantic model o come parametri di una data pipeline) è la scelta architetturale corretta: rende le rules pulite e riutilizzabili invece di dipendere da stringhe hard-coded.
Dove si configurano le rules — il punto critico
Le deployment rules si impostano sullo stage di destinazione, non su quello sorgente, e restano persistenti tra i deployment. Una regola definita su Production dice: “qualunque cosa arrivi in questo stage, la sorgente/parametro deve essere questo valore”. Così, anche promuovendo direttamente da Dev, la connessione di sviluppo non finisce mai in Production. Le rules entrano in vigore al deployment successivo alla loro creazione, non retroattivamente.
Relazione con Git integration
Le deployment pipeline gestiscono la promozione tra ambienti; la Git integration gestisce il source control (versioning, branch, code review). In uno scenario CI/CD maturo i due meccanismi convivono: Git come single source of truth del workspace di Development, deployment pipeline per far avanzare il contenuto verso Test e Production in modo controllato e ripetibile.
Trappole tipiche d’esame
- Scenario: vuoi impedire che la connessione al database di Dev raggiunga Production → Risposta: configura una data source / parameter rule sullo stage di destinazione (Production); le rules si impostano sul target, mai sul sorgente.
- Scenario: devi rilasciare solo un report senza promuovere le altre modifiche presenti in Dev → Risposta: usa il deployment selettivo scegliendo l’item nel confronto tra stage, non “Deploy all”.
- Scenario: hai creato una deployment rule ma l’ambiente punta ancora alla vecchia sorgente → Risposta: le rules si applicano solo al deployment successivo alla loro definizione; esegui una nuova promozione.
- Scenario: la promozione fallisce o gli stage non sono disponibili → Risposta: verifica che ogni workspace collegato sia assegnato a una capacity Fabric e che tu abbia ruolo Admin.
- Scenario: serve versioning con branch e code review, non solo passaggio tra ambienti → Risposta: è compito della Git integration, non delle deployment pipeline (che gestiscono la promozione, non il source control).