Implementar CI/CD en Microsoft Fabric

¿Qué te enseña este módulo?

Este módulo cubre CI/CD en Fabric — cómo gestionar el ciclo de vida de tus items desde development hasta production de forma automatizada y con control de versiones. Los objetivos oficiales:

1. Definir CI/CD y describir cómo se implementa en Fabric.
2. Implementar version control y Git integration.
3. Usar deployment pipelines para automatizar el deployment.
4. Automatizar CI/CD usando las Fabric APIs.

Peso en el examen DP-700

Este módulo es fundamental para el Dominio 1:

Definición

CI/CD = Continuous Integration y Continuous Deployment (o Delivery). Es una práctica de desarrollo y release para versionar los items del workspace de Fabric, mover cambios entre entornos y mantener consistentes las soluciones desplegadas entre workspaces.

Por qué en Fabric

Una solución de Fabric puede incluir muchos tipos de items, data sources y settings específicos del entorno. Un plan de CI/CD te ayuda a:

• Colaborar sin sobrescribirse entre developers.
• Evitar la reconfiguración manual durante el deployment.
• Mantener la consistencia entre dev, test y prod.

Los dos "C"

• CI = Continuous Integration — integrar cambios de código frecuentemente en un repo compartido, con testing automático.
• CD = Continuous Deployment/Delivery — desplegar los cambios verificados a producción o entornos destino de forma automatizada.

Los 2 tools nativos de Fabric

Fabric implementa CI/CD con dos features clave:

1. Git integration — version control para tus workspace items.
2. Deployment pipelines — mover items entre stages (dev → test → prod).

Puedes usar uno, el otro o ambos. Lo veremos en detalle.

Concepto

Los developers commitean frecuentemente a una main branch gestionada por Git, disparando tests automáticos y builds automáticos para la integración. Git trackea los cambios para permitir el fetching y testing automático de los nuevos commits.

Beneficios de CI

• ✅ Detectar conflictos rápido (antes de que se acumulen).
• ✅ Feedback inmediato sobre si el código funciona.
• ✅ Historia clara de qué cambió y cuándo.
• ✅ Múltiples developers trabajando sin pisarse.

En Fabric

• Git integration a nivel workspace.
• Los cambios en los items (notebooks, pipelines, semantic models, etc.) se commitean al repo.
• Otros developers pueden hacer pull de los cambios y trabajar en paralelo en branches distintas.

Concepto

CD = desplegar los cambios verificados a los entornos de producción a través de stages de deployment estructuradas dentro de los deployment pipelines.

Stages típicas

Típicamente separadas en 3 entornos:

• Development (compilar código, iterar).
• Test (ejecutar tests, QA).
• Production (desplegar la aplicación).

Cada stage tiene sus propios jobs y validaciones.

Automated workflows

Los deployment pipelines automatizan todo el proceso de building (compilar), testing (validar) y deploying (desplegar).

Beneficios:

• 🎯 Reduce el riesgo de error humano.
• ⚡ Acelera el desarrollo.
• 🔄 Entrega consistente y fiable a producción.

Pain points sin CI/CD

A) Problemas de integración manual: sin CI/CD, integrar cambios manualmente causa conflictos y errores, y ralentiza el desarrollo.

B) Retrasos en el desarrollo: los deployments manuales son lentos y propensos a errores, retrasando la entrega de nuevas features y updates.

C) Entornos inconsistentes: los distintos entornos (dev, test, prod) pueden tener inconsistencias, causando problemas difíciles de depurar.

D) Falta de visibilidad: sin CI/CD, trackear cambios y entender el estado del codebase es difícil.

Beneficios con Fabric CI/CD

• ✅ Version control de todos los items.
• ✅ Colaboración con el equipo.
• ✅ Rollback fácil si algo falla.
• ✅ Entornos consistentes automáticamente.
• ✅ Visibilidad de qué se desplegó y cuándo.
• ✅ La automatización reduce errores.

¿Qué es?

La Git integration en Fabric conecta tu workspace a un repositorio Git para tener version control de los items, trackear cambios a lo largo del tiempo, contribuir de forma colaborativa al desarrollo y revertir a versiones anteriores si lo necesitas.

Scope: nivel workspace

La integración con el control de versiones es a NIVEL WORKSPACE. Es decir:

• Un workspace ↔ una branch (típicamente).
• Todos los items del workspace se versionan juntos.
• No puedes versionar solo algunos items del workspace.

Los 2 providers

1. GitHub — el estándar open source y muy popular.
2. Azure DevOps — el estándar enterprise de Microsoft.

¿Cuál elegir?

GitHub ✅ cuando ya usas GitHub para otros proyectos, prefieres su UX, o valoras su comunidad grande e integraciones abundantes.

Azure DevOps ✅ cuando el setup enterprise ya está en el ecosistema Microsoft, necesitas integración profunda con Azure Pipelines, o ⭐ quieres lo recomendado para Fabric (menos limitaciones que GitHub actualmente).

Mejoras recientes

Nuevas features 2025-2026:

• Mapeo selectivo de branch por workspace o carpeta — apuntar a una branch específica por workspace.
• Experiencia de diff integrada — comparar los items del workspace con los commits de la branch antes de commitear o hacer pull.
• Mejor gestión de branched workspaces.

Pasos

Paso 1: preparar el repositorio Git — crear un repo en GitHub o Azure DevOps. Es la ubicación central para almacenar y gestionar los items.

Paso 2: conectar el workspace de Fabric al repo — dentro del workspace que quieres conectar → workspace settings → Git integration → establecer la conexión.

Paso 3: seleccionar branch — crear o seleccionar una branch existente del repositorio con la que sincronizar. Fabric sincroniza el contenido entre workspace y Git → mismo contenido.

Git status column

Después de conectar, el workspace muestra una columna Git status indicando el estado de sincronización de los items del workspace frente a los de la remote branch, con iconos de modified, added, deleted y up-to-date.

El icono de source control muestra el número de items que difieren entre workspace y repo.

Autenticación

• Microsoft Entra ID para la autenticación.
• Service principals posibles para automation.
• Personal Access Tokens (PATs) para GitHub cuando aplique.

Los 2 movimientos

A) Workspace → Git (Commit): cuando haces cambios en el workspace, sincronizas con la branch de Git usando la selección Changes en la ventana de Source control. El commit envía tus cambios al repo.

B) Git → Workspace (Update): cuando hay nuevos commits en la branch de Git (tuyos o de otros), sincronizas al workspace usando la selección Updates en la ventana de Source control. El update trae los cambios del repo al workspace.

Cuándo cada uno

• Trabajaste en la Fabric UI → commit para llevarlo al repo.
• Alguien commiteó al repo desde otro sitio → update para traerlo al workspace.
• Trabajaste en un client tool (VS Code, Power BI Desktop) → después del push, update para verlo en el workspace.

Diff view (nuevo)

Feature reciente: la experiencia de diff integrada te permite comparar los items del workspace con los commits de la branch antes de commitear o hacer pull, para revisar los cambios. Muy útil para evitar cambios accidentales.

Por qué branches

Los cambios que haces al workspace afectan a todos sus usuarios. Best practice: trabajar en aislamiento fuera de los shared workspaces.

Las 2 opciones de desarrollo aislado

A) Workspace aislado separado: tu propio workspace conectado a tu propia branch, con desarrollo web-based en la Fabric UI.

B) Client tools: Power BI Desktop para reports y semantic models, VS Code para Notebooks. Desarrollo local + push a Git.

Patrón común

En ambos escenarios: desarrollo de features en una branch dedicada (no main), múltiples developers trabajando en features distintas simultáneamente, y Pull Requests para hacer merge a main.

Diagrama mental

        main branch (protected)
             ↑
             │ Pull Request + Review
             │
     ┌───────┼───────┐
     │       │       │
   feat-A  feat-B  feat-C
     │       │       │
   Dev1    Dev2    Dev3
   (own    (own    (own
    ws)     ws)     ws)

Cada dev trabaja en su feature branch en su workspace personal → PR → merge a main.

La feature estrella

Branch out to new workspace es una feature muy examinable. Permite crear una nueva branch y un nuevo workspace en un solo click.

Cómo funciona

1. Estás en el development workspace conectado a la main branch.
2. Source control → Branch out to new workspace.
3. Nombras la branch.
4. La asocias con un nuevo workspace (se crea, o eliges uno existente).
5. El nuevo workspace sincroniza con la nueva branch.

Resultado

• ✅ Nueva branch en Git.
• ✅ Nuevo workspace en Fabric (aislado).
• ✅ Sync automático entre ambos.
• ✅ Entorno de trabajo dedicado para tu feature.

Workflow completo

1. Estás en Dev workspace (main branch)
   ↓
2. Branch out to new workspace
   ↓
3. Nueva branch "feature/new-report" + nuevo workspace "Dev-Feature"
   ↓
4. Trabajas en Dev-Feature workspace
   ↓
5. Commit changes → van a "feature/new-report" branch
   ↓
6. PR en Git para merge a main
   ↓
7. Merge aprobado → main actualizada
   ↓
8. Dev workspace prompted a sync con new content

Otros comandos de source control

Switch branch: cambia la conexión del workspace actual de una branch a otra del mismo repo. Antes debes commitear o descartar los cambios sin commitear. Fabric ejecuta un Update from Git que puede añadir, actualizar o borrar items.

Check out new branch: cambia de la branch actual a una nueva sin descartar los cambios de la actual. Útil para resolver merge conflicts entre la feature branch y la integration branch.

Ventajas

• ⚡ Rápido: un click en vez de setup manual.
• 🎯 Consistente: branch + workspace siempre sincronizados.
• 👥 Colaboración: cada developer con su entorno.
• 🔒 Aislamiento: no rompes el shared workspace.

Alternativa al web

Además de trabajar en la Fabric UI, puedes usar client tools locales:

• Power BI Desktop — reports y semantic models.
• VS Code — Notebooks (con la extensión Fabric Data Engineering).
• Azure Data Studio / SSMS — Warehouse y SQL Database.

Workflow típico con client tools

1. Conectar el development workspace a la main branch (Git integration).
2. Clonar el repositorio en tu máquina local (git clone).
3. Trabajar en local con tu tool preferido.
4. Push de los cambios al remote repo cuando esté listo para testear.
5. Testear conectando tu branch aislada a un workspace separado.
6. Pull Request en Git para hacer merge a main.
7. Cuando abres el shared workspace de main, se te pide sincronizar desde el repo.

Ventajas de los client tools

• ✅ Tooling familiar (Git CLI, VS Code, etc.).
• ✅ Desarrollo offline posible.
• ✅ Features ricas de IDE (debugging, refactoring, extensiones).
• ✅ Colaboración en equipo vía pull requests.

Cuándo cada approach

Desarrollo web-based ✅ para cambios rápidos y sencillos, equipos menos técnicos o preferencia visual.

Client tools ✅ para desarrollo intensivo (muchos notebooks), preferencia por features de IDE, necesidad de integraciones locales (Docker, testing frameworks) o equipos que vienen del mundo dev.

¿Qué son?

Los deployment pipelines de Fabric son un mecanismo de CI/CD integrado en Fabric que permite desplegar items de Fabric entre distintos entornos (dev, test, prod), automatizar el movimiento de contenido entre stages y testear y validar antes de producción.

Diferencia con Git integration

Git integration = version control (BYO Git). Deployment pipelines = CI/CD integrado que mueve items entre workspaces. Son complementarios — típicamente se usan juntos.

Estructura básica

Development WS  →  Test WS  →  Production WS
     (Stage 1)     (Stage 2)      (Stage 3)

Cada stage está asociada a un workspace. El botón Deploy promueve los items al siguiente stage.

Deployment pipelines vs GitHub Actions/Azure Pipelines

Los deployment pipelines de Fabric ≠ GitHub Actions / Azure Pipelines:

• Los deployment pipelines de Fabric están integrados en Fabric y son específicos para promover items entre workspaces.
• GitHub Actions / Azure Pipelines son plataformas generales de CI/CD que puedes usar para automation externa (desplegar items, correr scripts, etc.).

Puedes usar los dos: los deployment pipelines de Fabric para promover items, y GitHub Actions para disparar pipelines externos, correr tests, etc.

Prerequisites

• Suscripción activa de Microsoft Fabric.
• Acceso Admin a un workspace de Fabric.

Los 2 puntos de entrada

A) Desde el icono de Workspaces: navegación izquierda → icono Workspaces → Deployment pipelines → Create pipeline o + New pipeline.

B) Desde el workspace: parte superior del workspace → Create deployment pipeline.

Setup steps

Step 1: nombre y stages — introducir nombre y descripción, seleccionar Next, definir las stages (por defecto: Development, Test, Production) y seleccionar Create y continue.

Step 2: asignar workspaces — asignar un workspace a cada stage. Se puede asignar cualquier workspace a cualquier stage.

Step 3: desplegar contenido — cuando esté listo, el botón Deploy mueve el contenido al siguiente stage.

Default: 3 stages

Por defecto, el pipeline tiene 3 stages: Development (dev), Test y Production (prod).

🎯 Configurable: 2-10 stages

Puedes personalizar: añadir stages adicionales, renombrar stages y borrar stages. Mínimo 2 stages, máximo 10 stages.

Casos con stages extras

• 5 stages típicos: Dev → QA → UAT → Staging → Prod.
• Simplificado 2 stages: Dev → Prod (para equipos pequeños o proyectos simples).
• Multi-region: Dev → Test → Prod-EU → Prod-US → Prod-APAC.

Cómo asignar

1. Seleccionar el stage vacío.
2. Botón Assign workspace.
3. Seleccionar el workspace deseado.
4. Aparece un checkmark verde.

Reglas de assignment

• Un workspace por stage (puede tener múltiples items, pero un solo WS).
• Un workspace puede estar en un solo pipeline a la vez.
• El workspace puede estar en cualquier stage — no tienen orden requerido.

Workspaces según stages

Best practice: que los nombres de workspace reflejen su rol — MyProject-Dev, MyProject-Test, MyProject-Prod. O con prefijos: [DEV] MyProject, [TEST] MyProject, [PROD] MyProject.

Los 3 modos de deployment. Muy examinable.

Full deployment

Despliega TODO el contenido al stage destino.

Cuándo: la primera vez que despliegas, en un refactor big-bang, o para un sync completo (la fuente es la source of truth).

⚠️ Sobrescribe los paired items del destino.

Selective deployment ⭐

Seleccionas qué contenido desplegar al stage destino. Control fino.

Cuándo: solo quieres promover ciertos items nuevos, haces cambios pequeños incrementales, o quieres mantener sin cambios los items existentes en el destino.

Backward deployment

Despliega contenido de un stage POSTERIOR a uno ANTERIOR del pipeline. Ejemplo: promover contenido de Production a Development (para depurar o para "resetear" dev).

Paired items

Concepto clave: al desplegar contenido, Fabric identifica los items emparejados entre stages (el mismo item que existe en varias stages). Al desplegar:

• Los paired items del destino se sobrescriben.
• Los items nuevos se crean.
• Los items del destino que no están en el origen se mantienen (a menos que especifiques borrarlos).

Review y notes

Antes de desplegar puedes revisar tu deployment (ver qué se va a cambiar) y dejar una nota documentando el porqué del deployment.

El deployment history guarda cada deployment con fecha, usuario, items desplegados y notas. Útil para auditoría y rollback.

Patrón muy examinable: cómo combinar ambas herramientas.

El patrón recomendado

1. Conectar solo el Development workspace a Git.
2. Git integration para version control durante el desarrollo.
3. Deployment pipelines para la promoción a Test y Production.

Beneficio: evita posibles conflictos de sincronización con Git al desplegar contenido a través de múltiples stages.

Workflow completo

┌─────────────────────────────────────────────────┐
│              GIT REPOSITORY                     │
│   ┌───────────┐         ┌────────────┐          │
│   │  feat-A   │         │  feat-B    │          │
│   └─────┬─────┘         └─────┬──────┘          │
│         │  PR                  │  PR            │
│         ↓                      ↓                │
│         ┌──── main branch ─────┐                │
│                    ↕                            │
└────────────────────┼────────────────────────────┘
                     │ Git sync
                     ↓
┌────────────────────────────────────────────────┐
│   Dev workspace (Git connected)                │
└────────────────────────────────────────────────┘
                     │ Deployment pipeline (deploy button)
                     ↓
┌────────────────────────────────────────────────┐
│   Test workspace                                │
└────────────────────────────────────────────────┘
                     │ Deployment pipeline
                     ↓
┌────────────────────────────────────────────────┐
│   Prod workspace                                │
└────────────────────────────────────────────────┘

Steps:

1. Los developers trabajan en feature branches desde sus propios workspaces (branch out).
2. Merge a main vía PRs.
3. El Dev workspace se auto-sincroniza desde main.
4. El botón Deploy promueve Dev → Test.
5. Tras el testing, el botón Deploy promueve Test → Prod.

Otro patrón: solo Git

Alternativa: cada workspace conectado a su propia branch:

• Dev workspace ↔ branch dev
• Test workspace ↔ branch test
• Prod workspace ↔ branch main

La promoción = merge de una branch a otra vía PRs.

Pros: workflow Git-native, sin dependencia de los deployment pipelines de Fabric. Contras: setup más complejo, requiere disciplina de branching.

Cuál elegir

Git + deployment pipelines (recomendado) cuando el equipo es mixto (data engineers + analistas), quieres deployment simple basado en UI, o la solución es mediana o pequeña.

Solo branches de Git cuando el equipo es dev-heavy, tienes CI/CD enterprise con GitHub Actions o Azure Pipelines, o hay múltiples entornos complejos.

¿Qué son?

Las deployment rules son el mecanismo original (introducido en el servicio de Power BI hace años) para la parametrización en los deployment pipelines.

Uso típico: configurar un semantic model con una deployment rule para actualizar la ubicación de su data source al desplegar. Ejemplo: el semantic model en dev conecta a dev-db; al desplegar a test la regla lo cambia a test-db, y al desplegar a prod, a prod-db.

Cómo funcionan

Se definen a nivel stage: la regla dice "cuando despliegues A este stage, cambia X por Y". Hay tipos de reglas de conexión, de parámetros, etc.

Cuándo usar deployment rules

Por compatibilidad con setups existentes que ya las usan, en casos muy específicos que las variable libraries no cubren, o durante una migración progresiva a variable libraries. Para proyectos nuevos → variable libraries siempre.

Feature moderna y súper examinable. Este es EL mecanismo actual para la parametrización.

¿Qué es una variable library?

Una variable library es un tipo de workspace item que puedes crear, donde defines un conjunto de variables. Otros items del workspace (notebooks, pipelines, copy jobs, dataflows) pueden leer los valores de las variables desde la variable library. Esto permite evitar hardcodear settings de configuración que cambian entre entornos.

El problema que resuelven

Sin variable library:

# Notebook hardcoded para dev
database_server = 'devsql.database.windows.net'
database_name = 'ProductSalesDev'

Con variable library:

# Notebook lee variables
database_server = variables.get('database_server')
database_name = variables.get('database_name')

En cada stage, la variable library tiene distintos valores activos → mismo código, distinto comportamiento.

Los 2 beneficios clave

A) Personalizar configuraciones: configurar el valor de la variable según el stage del release pipeline. Un ajuste único del value set activo por stage → se usa automáticamente el valor correcto. Ejemplos: cambiar la conexión de un item según el stage, cambiar a otro cloud data source según el stage, o ajustar la cantidad de datos de una query según el stage.

B) Compartir configuraciones: una forma centralizada de gestionar configuraciones entre items del workspace. Si tienes varios lakehouses con shortcuts al mismo data source → una variable library con ese source como variable. Lo cambias una vez en la variable library, no en cada lakehouse.

Estructura

Una variable library contiene:

• Variables definidas por el usuario con tipos (string, integer, boolean, etc.).
• Value sets — conjuntos alternativos de valores para distintos entornos.
• Active value set — cuál está activo en el workspace actual.

Standard types

Puedes crear variables basadas en tipos estándar:

• String — texto.
• Number — decimal.
• Integer — entero.
• DateTime — fecha y hora.
• GUID — identificador único global.

Reference variable types (¡importantes!)

A) Connection reference variables ⭐

• Parametrizan conexiones para items de ETL.
• Ejemplos: pipelines, shortcuts en un lakehouse.
• Al editar el valor, la UI de Fabric muestra un item picker con las conexiones candidatas.
• Elimina los valores específicos del entorno de la definición del item.

Uso: un pipeline que conecta a una base de datos. En dev usa conn_dev, en prod usa conn_prod. La variable dice cuál usar.

B) Item reference variables ⭐

• Gestionan dependencias entre items de la misma solución.
• Especialmente útiles cuando las dependencias cruzan workspaces.
• Al editar, la UI de Fabric muestra un item picker.

Uso: un notebook del workspace staging necesita escribir output a un lakehouse del workspace presentation. La item reference variable parametriza el lakehouse destino.

Value sets

Value set = conjunto alternativo de valores para un entorno específico.

Variable library "MyLib":

Variables:
  - database_server (String)
  - database_name (String)
  - conn_id (Connection reference)

Value sets:
  - default:
      database_server = "devsql.database.windows.net"
      database_name = "ProductSalesDev"
      conn_id = <dev connection>
  - test:
      database_server = "testsql.database.windows.net"
      database_name = "ProductSalesTest"
      conn_id = <test connection>
  - prod:
      database_server = "prodsql.database.windows.net"
      database_name = "ProductSales"
      conn_id = <prod connection>

Active value set

Un value set se designa como "activo" por workspace → determina qué valores se usan en tiempo de ejecución.

Workflow:

1. Desplegar la variable library al workspace de test.
2. Activar el value set "test" en el workspace de test.
3. Los items del workspace de test usan automáticamente los valores de test.

Diagrama mental

                 Variable Library
                 (mismas variables)
                        ↓
        ┌───────────────┼───────────────┐
        │               │               │
   Dev workspace   Test workspace  Prod workspace
        │               │               │
   Active:         Active:         Active:
   "default"       "test"          "prod"
        │               │               │
   dev values      test values     prod values

Misma library, valores distintos según el active value set.

Por qué usar APIs

Las Fabric REST APIs permiten automatizar procedimientos y procesos de Fabric, mejorando la eficiencia y la productividad.

Ventajas:

• ✅ Automatizar procesos repetitivos con consistencia.
• ✅ Integración fluida con otros sistemas y aplicaciones.
• ✅ Data pipeline eficiente y simplificado.

2 grupos de APIs para CI/CD

A) Deployment pipelines REST APIs: gestionar los deployment pipelines, listar stages, desplegar contenido, etc.

B) Git REST APIs: gestionar la Git integration — commit, update, status.

Operaciones típicas vía API

Deployment pipelines:

• List Deployment Pipeline Stage Items — items soportados del workspace asignado al stage.
• Deploy Stage Content — desplegar los items del stage especificado.
• Ver el deployment history.

Git:

• Commit de los cambios del workspace a la remote branch conectada.
• Update workspace con los commits pusheados a la branch conectada.
• Git status API — ver los items con cambios entrantes y los que no se han commiteado.

Ejemplo mental

Con las REST APIs puedes hacer auto-deploy cuando se hace merge a main, auto-commit tras un data refresh programado, testing automatizado que ejecuta queries y valida resultados, o dashboards custom de estado de deployment.

Autenticación

Las APIs requieren autenticación con Microsoft Entra ID: service principals para automation y user tokens para scripts interactivos. Permisos típicos: Workspace.ReadWrite.All, Item.ReadWrite.All.

¿Qué es?

fabric-cicd = librería Python de Microsoft que simplifica los workflows de CI/CD para Fabric. Es el approach recomendado para la automation moderna.

Instalación

pip install fabric-cicd

Se puede instalar on-demand en pipelines de GitHub Actions o Azure DevOps.

Configuración

Un fichero de config (deploy.yml) define los entornos destino y sus workspaces:

environments:
  test:
    workspace_id: <test-workspace-id>
  prod:
    workspace_id: <prod-workspace-id>

También puedes usar workspace (display name) en vez de workspace_id.

Ejemplo Python mínimo

from azure.identity import EnvironmentCredential
from fabric_cicd import deploy_with_config

# Auth como service principal
credential = EnvironmentCredential()

# Deploy job
deploy_with_config(
    token_credential=credential,
    config_file_path='deploy.yml',
    environment='test'
)

Pasas el parámetro environment → despliega a ese workspace destino.

Features avanzadas

fabric-cicd soporta:

• ✅ Orquestación de deployment integrada.
• ✅ Parametrización.
• ✅ Post-deploy actions (llamar a las Fabric REST APIs tras el deploy).
• ✅ Orphan control — borrar items cuando Git ya no contiene su definición fuente.
• ✅ Variables dinámicas — por ejemplo $sqlendpoint de un lakehouse.

Post-deploy actions

Puedes configurar post-deploy actions que ejecutan scripts después del deploy: crear shortcuts, ejecutar notebooks, refrescar datasets o notificar a Teams/Slack.

¿Qué son?

Bulk Import Item Definitions API y Bulk Export Item Definitions API (preview). Permiten sincronizar múltiples items a escala, hacer import/export de los items del workspace en batch, y trabajar con paquetes JSON de item-definition que puedes persistir, mover e importar.

Cuándo usar bulk APIs vs fabric-cicd

Prefiere fabric-cicd para el deployment CI/CD estándar de Fabric, por sus beneficios integrados: orquestación, parametrización, post-deploy y orphan control.

Prefiere las Bulk APIs para la integración con un Git provider no soportado (ej: GitLab), para backup, clonado o migración cross-tenant, o para scripts custom que necesitan control total.

Trade-offs

Ejemplo: caso GitLab

Si tu equipo usa GitLab (no soportado nativamente por la Git integration de Fabric):

1. Bulk Export API → extraer las definiciones JSON de los items del workspace.
2. Commitear el JSON a GitLab.
3. Cuando quieras desplegar → Bulk Import API con el JSON del commit de GitLab.

Sirve como equivalente de Commit to Git y Update from Git.

Las 2 estrategias principales

Fabric CI/CD soporta ambas:

A) GitFlow

• Modelo de branching estructurado.
• Branches de larga vida: main, develop, release, hotfix.
• Feature branches → merge a develop → merge a release → merge a main.
• Más ceremonial y estructurado.

B) Trunk-based development

• Una única main branch (trunk).
• Feature branches de vida corta.
• Integración continua frecuente.
• Menos overhead.

Cuándo cada uno

GitFlow ✅ con equipos grandes, ciclos de release largos, varias versiones concurrentes en soporte, o entornos enterprise con procesos de aprobación complejos.

Trunk-based ✅ con un enfoque de DevOps moderno, deploys frecuentes (varias veces al día), un equipo disciplinado con feature flags, o ambición de continuous delivery.

Feature branches de vida corta

Best practice independientemente de la estrategia: feature branches de vida corta. Lo ideal son días, no semanas. Borra las feature branches tras los PRs para mantenerlas cortas, y recicla los feature workspaces entre varias feature branches para equipos dedicados.

Proceso de desarrollo (Continuous Integration)

1. Crear el repositorio Git y configurar las branches según la estrategia elegida (GitFlow o trunk-based).
2. Crear una única fuente de verdad en la integration branch con las definiciones de los items.
3. Crear la conexión Git entre el dev workspace y la integration branch.
4. Crear las conexiones Git con la opción Git folder para separar las carpetas de definiciones de items de otros ficheros del workflow.
5. Para soluciones multi-workspace, usar Git folder settings únicos para conectar todos los workspaces a una única branch de Git.
6. Configurar la política de la integration branch para prohibir commits directos y requerir pull requests para hacer merge.
7. Usar las capacidades de branched workspaces para crear y gestionar feature branches y feature workspaces.
8. Borrar las feature branches tras los PRs para mantenerlas cortas.
9. Reciclar los feature workspaces entre varias feature branches para equipos dedicados.
10. Revisar las estructuras de definición de items para entender qué ficheros requiere o soporta cada tipo de item.
11. Para notebooks, habilitar el auto-binding añadiendo notebook-settings.json a su definición.
12. Para items que no soportan auto-binding, escribir post-sync scripts para restablecer las relaciones.

Proceso de release (Continuous Deployment)

1. Configurar el repo Git con variables (ej: workspace IDs, Microsoft Entra IDs).
2. Configurar el repo Git con secrets (ej: credenciales de autenticación del service principal).
3. Usar fabric-cicd y su soporte de deployment basado en configuración.
4. Configurar los nombres de entorno de fabric-cicd para que coincidan con los nombres de los value sets de la variable library, y habilitar así la auto-activación.
5. Usar el soporte de parametrización de fabric-cicd para actualizar los settings específicos de entorno.
6. Cuando sea posible, usar pull requests para configurar procesos de aprobación manual de los deployment jobs.
7. Al usar trunk-based development, crear entornos en el repositorio host para configurar los procesos de aprobación manual.

Parametrización de settings específicos de entorno

1. Determinar qué items contienen settings con valores específicos de entorno (rutas de data source, connection IDs).
2. Crear una variable library y añadir variables para parametrizar esos settings.
3. Actualizar los settings de los items para que lean las variables de la variable library.
4. Usar connection reference variables para parametrizar las conexiones a data sources externos.
5. Usar item reference variables en soluciones multi-workspace para gestionar las dependencias entre items.
6. Extender la variable library creando value sets para los entornos de testing y producción.

Estrategia de orquestación de datos

1. Implementar la arquitectura medallion con items lakehouse como contenedores de almacenamiento (bronze/silver/gold).
2. Implementar la lógica ETL con items como notebooks, pipelines, copy jobs, dataflows y user-defined functions.
3. Exponer un único pipeline o notebook de nivel superior para ejecutar el procesamiento ETL end-to-end.
4. Escribir un post-deploy script para automatizar la ejecución de ese pipeline de nivel superior tras el deployment.
5. Configurar los items de ETL con scheduled jobs vía ficheros .schedules en las definiciones de los items.
6. Gestionar los cambios de schema de las tablas del lakehouse con lógica de gestión de tablas en notebooks.
7. Gestionar los cambios de schema del warehouse con el tooling de SqlPackage y el Data-tier Application Framework.

• Trampa 1: "Git integration y deployment pipelines son lo mismo" ❌ Distintos. Git = version control (BYO Git). Deployment pipelines = CI/CD integrado que mueve items entre workspaces. Se usan juntos.
• Trampa 2: "Puedo cambiar el número de stages después de crear el pipeline" ❌ No. El número de stages es permanente. Piénsalo bien al crearlo.
• Trampa 3: "Solo puedo tener 3 stages en un deployment pipeline" ❌ Puedes tener 2-10 stages. Por defecto son 3, pero son configurables.
• Trampa 4: "El backward deployment siempre funciona" ❌ Solo cuando el stage destino está VACÍO (sin workspace asignado). Si tiene workspace, actualmente no funciona.
• Trampa 5: "Las deployment rules son la mejor forma de parametrización" ❌ Son legacy. Las variable libraries son la capability estratégica de Fabric y la primera opción actual.
• Trampa 6: "La variable library es opcional" ❌ Es muy recomendable. Sin ella hardcodeas todo → mantenimiento de pesadilla.
• Trampa 7: "Un workspace puede estar en múltiples deployment pipelines" ❌ Un workspace en un solo pipeline a la vez.
• Trampa 8: "Puedo mezclar Git providers entre workspaces del mismo pipeline" ❌ En la práctica, mantén un provider consistente (GitHub o Azure DevOps).
• Trampa 9: "GitHub y Azure DevOps son equivalentes en Fabric" ❌ Similares, pero Azure DevOps es el recomendado por tener menos limitaciones actualmente.
• Trampa 10: "El full deployment siempre es mejor" ❌ Puede ser destructivo al sobrescribir los paired items. El selective deployment es más seguro para cambios incrementales.
• Trampa 11: "El value set activo se configura una vez y ya" ✅ Correcto en cierto sentido: configuras el activo por workspace una vez y luego los items lo usan automáticamente. Pero si cambias el value set activo, el comportamiento de los items se actualiza automáticamente.
• Trampa 12: "fabric-cicd es solo para uso avanzado" ❌ Es el approach recomendado por Microsoft para la automation. Perfectamente accesible.
• Trampa 13: "Los nombres de value set pueden ser cualquier cosa" ⚠️ Deben coincidir con los nombres de entorno en fabric-cicd para la auto-activación. Best practice: nombres consistentes (dev, test, prod).
• Trampa 14: "Puedo commitear directamente a main" ❌ Best practice: la política de la integration branch prohíbe los commits directos y requiere PRs.
• Trampa 15: "Las Fabric REST APIs son para casos muy específicos" ❌ Son útiles para muchos escenarios de automation: integraciones CI/CD, monitorización, UIs custom.
• Trampa 16: "Puedo modificar el logicalId libremente" ❌ NUNCA modifiques el logicalId. Es una propiedad interna; modificarlo puede causar comportamientos impredecibles.
• Trampa 17: "Las Bulk APIs son mejores que fabric-cicd" ❌ fabric-cicd es lo preferido para escenarios estándar. Las Bulk APIs, para casos específicos (GitLab, cross-tenant).
• Trampa 18: "El auto-rebinding lo maneja todo automáticamente" ⚠️ Maneja la mayoría de las relaciones entre items. Los casos límite pueden requerir post-sync scripts.
• Trampa 19: "Los feature workspaces son permanentes" ❌ Best practice: de vida corta. Recíclalos entre features y bórralos cuando ya no hagan falta.

Git integration vs Deployment pipelines

Deployment modes

Variable libraries vs Deployment rules

Variable types

Approaches de automation

Branching strategies

Los 4 pilares del CI/CD en Fabric

Deployment pipeline stages

• Módulo Learn: implement-cicd-in-fabric
• CI/CD concepts and best practices: understand-best-practices-fabric-cicd
• Git integration overview: intro-to-git-integration
• Git get started: git-get-started
• Git integration process: git-integration-process
• Branched workspace: branched-workspace
• Granular compare: granular-compare
• Deployment pipelines: intro-to-deployment-pipelines
• Assign workspace to pipeline: assign-pipeline
• Deploy content: deploy-content
• Compare content in stages: compare-pipeline-content
• Variable library overview: variable-library-overview
• Variable types: variable-types
• Item reference variable: item-reference-variable-type
• Value sets: value-sets
• Variable library tutorial: tutorial-variable-library
• Deployment pipelines REST APIs: core/deployment-pipelines
• Git REST APIs: core/git
• fabric-cicd library tutorial: tutorial-fabric-cicd-azure-devops
• Fabric CLI documentation: fabric-command-line-interface
• Manage deployment: manage-deployment
• CI/CD Data Factory pipelines: cicd-pipelines
• Logical ID conflicts: logical-id-conflict-resolution
• Conflict resolution: conflict-resolution
• Eventstream CI/CD: eventstream-cicd