Exemples de plans de déploiement (aperçu)

Cet article présente les schémas pour lesquels les plans de déploiement sont couramment utilisés. Chacun décrit les groupes de déploiement et les actions qui leur sont associées, afin que vous puissiez construire l’équivalent sur la toile.

Pour savoir comment élaborer un plan, voir Créer un plan de déploiement.

Déploie un élément qui dépend des données produites par un autre élément

C’est la raison la plus courante pour utiliser un forfait.

Espace de travail

Une équipe commerciale conserve sa solution analytique dans un seul espace de travail git-connected qui contient quatre éléments :

Pourquoi l’ordre de déploiement seul ne suffit pas

Fabric utilise la lignée des objets pour détecter que la vue de l’entrepôt fait référence à une table de la maison du lac, il déploie donc la maison du lac avant l’entrepôt.

Lineage ne montre pas que le tableau doit être rempli avant que la vue soit valide. Le tableau n’est pas fourni avec la définition de l’élément. Les deux carnets le produisent au moment de l’exécution :

Déployez cet espace de travail sans plan et le déploiement échoue. Chaque élément est correctement copié, mais la vue de l’entrepôt est définie sur une table que personne n’a encore créée, et le déploiement signale que le nom de l’objet est invalide. La cible reste partiellement déployée.

Il n’y a rien de mal avec les objets. Ce qui manque, c’est l’instruction pour faire fonctionner les notebooks entre le déploiement de la cabane et celle de l’entrepôt. Cette instruction est le plan.

Le plan

Le plan prévoit deux groupes de déploiement, un pour la maison du lac et un pour l’entrepôt. Le groupe Lakehouse exécute les deux notebooks en tant qu’actions post-déploiement :

Une fois le lakehouse déployé, Hydrate_TopCustomers écrit les lignes source. Ensuite Publish_TopCustomers crée dbo.top_customers et attend que le point de terminaison d’analytique SQL expose la table. Le groupe de la maison du lac ne termine qu’après la fin des deux actions. Fabric peut alors déployer l’entrepôt et créer sa vue.

Les carnets sont des actions dans le groupe de la maison du lac, pas des groupes de déploiement séparés. Publish_TopCustomers Cela dépend de Hydrate_TopCustomers, et le groupe d’entrepôt dépend du groupe Lakehouse complété.

Voici le même plan sur la toile :

Comprendre la structure du fichier plan.yml

On construit un plan sur la toile. Lorsque l’espace de travail est connecté à Git, le plan est stocké sous forme de fichier plan.yml dans le dossier de l’élément du plan de déploiement, il est donc examiné et versionné comme n’importe quel autre élément :

$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

Le fichier a la structure suivante :

Quelques points à noter dans cette définition :

• Un groupe nomme un élément. logicalId est l’identifiant logique de l’élément, le même identifiant utilisé par Git, donc le plan reste valide au fur et à mesure que l’élément se déplace entre les espaces de travail.
• L’ordre du groupe s’exprime par dependsOn, et non par la position dans le fichier. Réorganiser les groupes dans le fichier ne change rien.
• L’ordre d’action s’exprime également par dependsOn. Run Publish_TopCustomers ne démarre qu’après la fin de Run Hydrate_TopCustomers
• postActions s’exécute après le déploiement de l’élément du groupe. À utiliser preActions pour un travail qui doit d’abord avoir lieu, comme un contrôle de validation.

Rafraîchir le contenu après son déploiement

Un déploiement met à jour les définitions des éléments. Il ne fait rien, donc un modèle sémantique ou un rapport reflète la nouvelle définition mais pas de nouvelles données.

Attachez ce plan à un déploiement en pipeline de déploiement afin que la promotion à une étape laisse la cible prête à l’utilisation plutôt que d’avoir besoin d’un rafraîchissement manuel.

Validez avant que quoi que ce soit ne soit déployé

Une action de pré-déploiement s’exécute avant que l’objet de son groupe ne soit déployé, donc vous pouvez en utiliser une comme porte.

Une action ne peut exécuter qu’un élément déjà déployé, donc la vérification elle-même est déployée par un groupe précédent :

Si la vérification échoue, le déploiement s’arrête et rien qui dépend de ce groupe ne se déploie. Utilisez cela pour confirmer que les connexions se résolvent, qu’une capacité requise fonctionne, ou qu’un système source est disponible avant le début d’une version.

Commander des œuvres que la lignée ne peut pas voir

Deux éléments peuvent être complètement indépendants en termes de lignée, et nécessitent toujours un ordre. Un plan, c’est la façon dont tu exprimes cela.

Comme la dépendance passe par une connexion plutôt que par une référence d'objet, Fabric ne peut pas en déduire. Le plan détermine l’ordre.

Contenu connexe

• Qu’est-ce qu’un plan de déploiement ?
• Créer un plan de déploiement
• Actions du plan de déploiement
• Résoudre les problèmes liés aux plans de déploiement