Ejemplos de planes de despliegue (vista previa)

Este artículo muestra patrones para los que se utilizan comúnmente los planes de despliegue. Cada uno describe los grupos de despliegue y las acciones que se les asocian, para que puedas construir el equivalente en el lienzo.

Para saber cómo elaborar un plan, véase Crear un plan de despliegue.

Despliega un ítem que depende de datos que otro elemento produzca

Esta es la razón más común para usar un plan.

Área de trabajo

Un equipo de ventas mantiene su solución de análisis en un único espacio de trabajo conectado a Git que contiene cuatro elementos:

Item Tipo Qué hace
Sales_Lakehouse Lakehouse Almacena las tablas de ventas. Está vacío cuando se despliega, porque un despliegue copia definiciones de elementos, no datos.
Hydrate_TopCustomers Notebook Escribe las filas de la fuente en bruto en la casa del lago.
Publish_TopCustomers Notebook Convierte esas filas en la tabla publicada dbo.top_customers .
Sales_Warehouse Almacén Mantiene la vista dbo.vw_top_customers, que dice dbo.top_customers.

Por qué el orden de despliegue por sí solo no es suficiente

Fabric utiliza el linaje de elementos para detectar que la vista del almacén de datos hace referencia a una tabla de lakehouse, por lo que implementa el lakehouse antes que el almacén de datos.

Lineage no muestra que la tabla deba estar poblada antes de que la vista sea válida. La tabla no aparece con la definición del ítem. Los dos cuadernos lo producen en tiempo de ejecución:

Diagrama que muestra el cuaderno Hydrate escribiendo una tabla de origen en el lakehouse, el cuaderno Publish convirtiendo esa tabla en dbo.top_customers y la vista del almacén de datos leyendo esa tabla.

Despliega este espacio de trabajo sin un plan y el despliegue falla. Cada elemento se copia correctamente, pero la vista del almacén de datos se crea sobre una tabla que aún no se ha creado, y el despliegue indica que el nombre del objeto no es válido. El objetivo queda parcialmente desplegado.

No hay nada malo con los objetos. Lo que falta es la instrucción para ejecutar los cuadernos entre desplegar la casa del lago y el almacén. Esa instrucción es el plan.

El plan

El plan cuenta con dos grupos de despliegue, uno para la casa del lago y otro para el almacén. El grupo lakehouse ejecuta ambos cuadernos como acciones posteriores al despliegue:

Grupo de implementación Elemento implementado Acciones posteriores al despliegue Depende de
Sales_Lakehouse Sales_Lakehouse (casa del lago) 1. Ejecute Hydrate_TopCustomers
2. Ejecuta Publish_TopCustomers		 Nada
Ventas_Almacén Sales_Warehouse (almacén) Ninguno Sales_Lakehouse

Después de que se implemente el lakehouse, Hydrate_TopCustomers escribe las filas de origen. Luego Publish_TopCustomers crea dbo.top_customers y espera hasta que el endpoint de analítica SQL expone la tabla. El grupo de la casa del lago termina solo después de que ambas acciones terminen. Fabric puede a continuación desplegar el almacén y crear su vista.

Los cuadernos son acciones del grupo lakehouse, no grupos de despliegue separados. Publish_TopCustomers depende de Hydrate_TopCustomers, y el grupo de almacenes depende del grupo de lakehouse completado.

Aquí está el mismo plano en el lienzo:

Captura de pantalla del plan de despliegue de SalesRelease que muestra el grupo Sales_Lakehouse con Hydrate_TopCustomers y Publish_TopCustomers como acciones posteriores al despliegue en ese orden, seguido del grupo dependiente Sales_Warehouse.

Comprenda la estructura de plan.yml

Construyes un plan sobre el lienzo. Cuando el espacio de trabajo está conectado a Git, el plan se almacena como un plan.yml archivo en la carpeta del elemento del plan de despliegue, por lo que se revisa y versiona como cualquier otro elemento:

$schema: https://developer.microsoft.com/json-schemas/fabric/item/deploymentPlan/definition/plan/1.0.0/schema.json
version: 1.0.0
groups:
  - name: Sales_Lakehouse
    logicalId: 11111111-1111-1111-1111-111111111111
    postActions:
      - name: Run Hydrate_TopCustomers
        job:
          type: Execute
          logicalId: 22222222-2222-2222-2222-222222222222
      - name: Run Publish_TopCustomers
        dependsOn:
          - actionName: Run Hydrate_TopCustomers
        job:
          type: Execute
          logicalId: 33333333-3333-3333-3333-333333333333
  - name: Sales_Warehouse
    logicalId: 44444444-4444-4444-4444-444444444444
    dependsOn:
      - groupName: Sales_Lakehouse

El archivo tiene la siguiente estructura:

Elemento propósito
$schema Identifica el esquema que valida la definición del plan.
version Identifica la versión de definición del plano.
groups Contiene los grupos de despliegue del plan.
name Da a un grupo o acción un nombre único al que las dependencias pueden referenciar.
logicalId Identifica el elemento Fabric en diferentes espacios de trabajo.
dependsOn Declara dependencias de otro grupo o de otra acción mediante su nombre.
preActions y postActions Ejecuta trabajos compatibles antes o después de desplegar el elemento del grupo.
job Identifica el tipo de trabajo, el ID lógico del ítem y los parámetros opcionales para una acción.

Algunas cosas a tener en cuenta en esta definición:

  • Un grupo da nombre a un elemento. logicalId es el ID lógico del elemento, el mismo identificador que usa la integración con Git, por lo que el plan sigue siendo válido mientras el elemento se mueve entre espacios de trabajo.
  • El orden de grupo se expresa con dependsOn, no por posición en el archivo. Reordenar los grupos en el archivo no cambia nada.
  • El orden de acción también se expresa con dependsOn. Run Publish_TopCustomers comienza solo después de que Run Hydrate_TopCustomers finalice.
  • postActions se ejecuta después de que se implemente el elemento del grupo. Úsalo preActions para trabajos que tengan que hacerse primero, como una comprobación de validación.

Sugerencia

Una acción se completa cuando finaliza la ejecución del elemento, no cuando los servicios posteriores se ponen al día. En este ejemplo, la última celda de Publish_TopCustomers espera hasta que el endpoint de análisis SQL de Lakehouse haya catalogado la nueva tabla. Pon ese tipo de comprobación de preparación dentro de la acción, porque el plan no espera por ti.

Actualizar contenido después de que se despliegue

Un despliegue actualiza las definiciones de ítems. No ejecuta nada, así que un modelo semántico o un informe refleja la nueva definición pero no los datos nuevos.

Grupo de implementación Elemento implementado Se ejecuta después de que el objeto se despliegue Depende de
Ventas_Almacén Sales_Warehouse (almacén) Ninguno Nada
Sales_Model Sales_Model (modelo semántico) Ejecuta una canalización de datos para actualizar el modelo Ventas_Almacén

Adjunta este plan a un despliegue de pipeline de despliegue para que promocionar a una etapa deje el objetivo listo para usarse en lugar de necesitar una actualización manual.

Valida antes de que se despliegue nada

Una acción previa al despliegue se ejecuta antes de que el objeto de su grupo se despliegue, así que puedes usar una como puerta.

Una acción solo puede ejecutar un elemento que ya esté desplegado, por lo que la comprobación en sí es desplegada por un grupo anterior:

Grupo de implementación Elemento implementado Se ejecuta antes de que el objeto se despliegue Depende de
Prevuelo Preflight_Checks (cuaderno) Ninguno Nada
First_Real_Item El primer elemento de la publicación Ejecuta Preflight_Checks Prevuelo

Si la comprobación falla, el despliegue se detiene y no se despliega nada que dependa de ese grupo. Úsalo para confirmar que las conexiones funcionan correctamente, que la capacidad necesaria está en ejecución o que hay un sistema de origen disponible antes de que comience un despliegue.

Nota:

Una acción pre-despliegue no puede ejecutar el objeto que despliega su propio grupo, porque ese elemento aún no existe en el objetivo. Despliega el elemento que realiza la comprobación en un grupo anterior, como se muestra aquí.

Ordena obras que la línea de origen no puede ver

Dos elementos pueden ser completamente independientes en cuanto a linaje y aún así necesitan un orden. Un plan es cómo expresas eso.

Grupo de implementación Elemento implementado Depende de
Datos de referencia El elemento que produce datos de referencia Nada
Dominio_Elemento Un elemento que lee datos de referencia a través de una conexión en lugar de una referencia directa Datos de referencia

Como la dependencia pasa por una conexión en lugar de una referencia de elemento, Fabric no puede inferirla. El plan proporciona el orden.

Contenido relacionado

  • Se actualizó por última vez el