Struttura a tre stage: il ciclo di vita del contenuto
Le deployment pipeline di Microsoft Fabric organizzano il rilascio del contenuto analitico attraverso stage sequenziali. La configurazione predefinita ne prevede tre — Development, Test, Production — ma la pipeline è personalizzabile da 2 a 10 stage a seconda della complessità del processo di rilascio.
Ogni stage viene assegnato a un workspace distinto. È un vincolo forte: un workspace può essere assegnato a un solo stage di una sola pipeline. Per assegnare un workspace occorre essere admin del workspace e disporre di una capacità Fabric (F SKU o trial); i workspace con capacità Pro-only non supportano tutti gli item Fabric.
| Stage | Workspace tipico | Chi accede | Capacità consigliata |
|---|---|---|---|
| Development | Sales [Dev] |
data engineer, sviluppatori | F SKU piccola |
| Test | Sales [Test] |
QA, business validator | F SKU media |
| Production | Sales [Prod] |
utenti finali, app | F SKU dimensionata al carico |
Primo deploy vs deploy successivi
La distinzione è un classico d’esame:
- Primo deploy: gli item non esistono nello stage di destinazione, quindi vengono creati ex novo. Ricevono nuovi ID e il legame di “parentela” (pairing) con l’item sorgente viene stabilito in quel momento.
- Deploy successivi: gli item già accoppiati vengono aggiornati sul posto, conservando i propri ID, URL e permessi. Questo è cruciale perché report condivisi, link nei preferiti degli utenti e app pubblicate non si rompono a ogni rilascio.
Il pairing avviene per tipo di item + nome. Se rinomini un item nello stage sorgente dopo il primo deploy, il pairing si spezza e il deploy successivo creerà un duplicato invece di aggiornare. La deselezione di un item durante un deploy selettivo lo lascia semplicemente invariato a destinazione.
Nota importante: la pipeline distribuisce definizioni e metadati, non i dati. Un Lakehouse o un Warehouse viene creato vuoto nello stage di destinazione; le tabelle vanno popolate dalle pipeline di ingestion dell’ambiente stesso.
Deployment rule: far puntare i modelli alle sorgenti giuste
Senza intervento, un semantic model deployato in Production continuerebbe a leggere dal Lakehouse di Development. Le deployment rule risolvono esattamente questo.
Regola d’oro da ricordare: le rule si configurano sullo stage di DESTINAZIONE, non su quello sorgente. La rule su Test descrive come devono apparire gli item una volta arrivati in Test.
I tipi principali:
- Data source rule — sostituisce la connessione del semantic model. Punta il modello dal Lakehouse/Warehouse di Dev a quello omologo di Test o Production. Con Direct Lake si ridireziona verso il SQL analytics endpoint del Lakehouse/Warehouse di destinazione.
- Parameter rule — sovrascrive il valore di un parametro definito nel semantic model (tipicamente parametri Power Query come
ServerName,DatabaseName,Environment). È l’approccio più flessibile e scalabile. - Default rule — applica un valore a tutte le sorgenti/parametri che corrispondono, utile su modelli numerosi e omogenei.
Le rule sono persistenti: si impostano una volta e valgono per tutti i deploy successivi. Se un item viene rimosso e ricreato, però, la rule associata va riconfigurata.
Altre configurazioni disponibili sullo stage di destinazione: le regole di autobinding (che riagganciano automaticamente gli item dipendenti alle controparti dello stesso stage) e le variable library, alternativa moderna e centralizzata alle rule per gestire valori ambiente-specifici su più item.
Deployment pipeline oppure Git integration?
Sono strumenti complementari, non alternativi. Un errore frequente è presentarli come una scelta esclusiva.
| Esigenza | Strumento |
|---|---|
| Versionamento, branch, code review, PR | Git integration |
| Collaborazione fra più sviluppatori sullo stesso contenuto | Git integration |
| Storico delle modifiche e rollback a un commit | Git integration |
| Promozione controllata Dev → Test → Prod | Deployment pipeline |
| Sostituzione delle sorgenti per ambiente | Deployment pipeline (rule) |
| Confronto visivo fra due stage prima del rilascio | Deployment pipeline |
Lo schema tipico in produzione: il workspace di Development è connesso a Git (branch main o feature branch), mentre la promozione verso Test e Production avviene con la deployment pipeline. In alternativa, chi preferisce un flusso interamente Git-based collega ogni workspace a un branch diverso e usa le pull request per la promozione — approccio valido ma che rinuncia alle deployment rule.
L’automazione è disponibile tramite le Fabric REST API (Deploy Stage Content) e le azioni Azure DevOps / GitHub Actions, per innescare deploy dentro una pipeline CI/CD più ampia.
Trappole tipiche d’esame
- Scenario: dopo il deploy in Production il semantic model legge ancora dal Lakehouse di Development. → Configura una data source rule sullo stage Production (destinazione), non su Development.
- Scenario: serve mantenere stabili gli URL dei report già condivisi con gli utenti. → Usa la deployment pipeline per i deploy successivi: gli item accoppiati vengono aggiornati conservando ID e URL. Ricrearli manualmente o rinominarli spezza il pairing.
- Scenario: il team chiede code review e possibilità di rollback a una versione precedente. → Serve Git integration, non la deployment pipeline: le pipeline non versionano né offrono storico dei commit.
- Scenario: dopo il deploy il Warehouse in Test risulta vuoto. → Comportamento atteso: la pipeline promuove metadati e definizioni, non i dati. Occorre eseguire l’ingestion nell’ambiente di Test.
- Scenario: un workspace già assegnato a una pipeline deve entrare in una seconda pipeline. → Non è possibile: serve prima rimuoverlo (unassign), perché un workspace appartiene a un solo stage di una sola pipeline.