Deployment Pipelines

Promover contenido entre workspaces sin abrir Desktop

Una Deployment Pipeline es una herramienta nativa del Service que conecta tres workspaces — uno por cada etapa del ciclo de vida — y permite promover el contenido de una etapa a la siguiente con un par de clics, manteniendo las conexiones, las identidades de dataset y los permisos limpios.

Requiere capacidad Premium per User (PPU), Premium o Fabric. No está disponible en Pro standalone.

Cada etapa, su workspace y su propósito

Reglas básicas

• Un workspace solo puede estar asociado a una pipeline a la vez
• Los nombres internos de los artefactos se mantienen al promocionar (las URLs sobreviven)
• Los permisos del workspace NO se copian; cada etapa tiene los suyos
• La conexión a orígenes y los parámetros sí pueden cambiar entre etapas — esa es la función de las reglas

El secreto para que cada etapa apunte al origen correcto

Al promocionar de Dev a Test, no quieres que el dataset siga apuntando al SQL de Dev. Las reglas de dataset permiten reescribir, en la etapa destino, los parámetros y orígenes que tocan.

Tipos de reglas

• Data source rules: "si la conexión es sql-dev.contoso.com, en Test cámbiala a sql-test.contoso.com"
• Parameter rules: reescribe el valor de parámetros M (típicamente usados para entornos)
• Connection string rules en dataflows

Patrón limpio recomendado

En Power Query, define parámetros ServerName y DatabaseName. Tu query usa Sql.Database( ServerName, DatabaseName ). Después en la pipeline, una regla por etapa reescribe cada parámetro. Mantenible y auditable.

// Power Query parametrizado
let
    Source = Sql.Database( ServerName, DatabaseName ),
    Ventas = Source{[Schema = "dbo", Item = "Ventas"]}[Data]
in
    Ventas

Diff visual entre etapas

La pipeline marca cada artefacto con un indicador:

• 🟢 Igual: Dev y Test tienen el mismo contenido
• 🟡 Diferente: hay cambios pendientes de promoción (badge "Different")
• 🆕 New: el artefacto solo existe en la etapa origen
• ❌ Missing: existe en destino pero no en origen (típico tras un delete)

Cómo desplegar

1. Selecciona los artefactos que quieres mover (todos o un subconjunto)
2. Botón Deploy hacia la siguiente etapa
3. Power BI verifica las reglas y aplica los cambios
4. Notas de deployment opcionales (¡úsalas para registrar qué y por qué!)

Backward deployment

También puedes promocionar "hacia atrás" (de Test a Dev, por ejemplo) si quieres recuperar un estado anterior. Útil pero peligroso: piensa siempre si lo que quieres no es un Git pull.

Dos herramientas que se complementan

• Git integration (Fabric): conecta un workspace a un repo Azure DevOps / GitHub. Versiona los artefactos como TMDL / PBIP. Permite branching, pull requests, code review.
• Deployment pipelines: orquesta la promoción entre workspaces ya conectados con sus reglas.

Workflow profesional combinado

1. Cada developer trabaja en una rama feature, modifica el contenido en Desktop con formato PBIP
2. Pull request al main → revisión de código (DAX, modelo, performance)
3. Merge → CI/CD despliega al workspace Dev
4. Pipeline de Power BI promociona Dev → Test → Prod con reglas
5. Cada release queda etiquetada en Git y en la pipeline

Lo que diferencia un equipo maduro

• Parametriza siempre conexiones y nombres de base de datos — incluso si arrancas con un único entorno
• Cada pipeline cubre una iniciativa o dominio, no "toda la organización"
• Despliegues siempre acompañados de notas con tickets / motivos
• Revisión obligatoria antes de promover a Prod: refresh exitoso en Test, RLS validado, performance probada
• Restringe quién puede promover a Prod: solo Member/Admin de Prod, idealmente solo el CoE
• No promociones a Prod un viernes a las 17:00. Nunca. 🙏

Errores frecuentes

• Mezclar Dev/Test/Prod en el mismo workspace y usar carpetas para "separar" — no es lo mismo
• Hardcodear conexiones en M sin parámetros — al promocionar todo apunta al Dev
• Olvidar configurar credenciales y refresh schedules en Test/Prod después del primer despliegue
• No promocionar dataset y informe juntos — el informe queda apuntando al dataset Dev