Pipeline CI/CD Microsoft Fabric avec GitHub
Partie 4: Protection des branches, déploiement et test de bout en bout
Cette dernière partie sécurise les branches critiques du dépôt, déclenche le premier déploiement automatique vers Microsoft Fabric, puis valide le pipeline en simulant le flux complet d’un développeur jusqu’à un déploiement contrôlé en production.
Étape 7. Protéger les branches critiques
La protection des branches empêche toute modification non validée sur les branches stratégiques. Toute évolution de main ou de release/* doit alors passer par une Pull Request avec un pipeline CI vert.
Protéger la branche main
- Aller dans Settings puis Branches du dépôt GitHub.
- Cliquer sur Add branch ruleset.
- Cibler la branche
main. - Activer les règles : Pull Request obligatoire avant merge, status checks requis (workflow CI), interdiction de force push.
- Cliquer sur Create pour enregistrer la règle.
Protéger les branches release/**
Refaire la même procédure en ciblant release/** avec les mêmes règles. L’objectif est qu’aucun déploiement PROD ne puisse être déclenché par un push direct non revu.
Limitation à connaître : ces règles ne sont pleinement appliquées que sur les dépôts publics ou sur certains plans GitHub payants. Sur un dépôt privé en plan Free, les règles sont enregistrées mais ne sont pas appliquées en pratique.
Étape 8. Committer et pousser les fichiers
Une fois la structure remplie et les workflows en place, c’est le push initial qui déclenche le premier pipeline CD DEV.
# vérifier l'état du dépôt local
git status
# ajouter, committer puis pousser
git add .
git commit -m "Mise en place du pipeline CI/CD Fabric"
git push origin main
Attention : si la protection de la branche main est active et appliquée, le push direct est rejeté. Dans ce cas, créez une branche de travail, ouvrez une Pull Request et mergez après validation du CI.
Dans l’onglet Actions du dépôt, le workflow CD DEV doit se déclencher automatiquement et passer au vert. Le notebook de démonstration est alors déployé dans le workspace Fabric DEV.
Étape 9. Tester le pipeline de bout en bout
Le test final simule le flux complet d’un développeur : modification d’un notebook sur une branche de travail, Pull Request, CI, merge, déploiement DEV automatique, puis déclenchement d’un déploiement PROD via une branche release/*.
Créer la branche de travail
Sur le dépôt GitHub, ouvrez le sélecteur de branche, saisissez feature/demo-notebook puis cliquez sur Create branch: feature/demo-notebook from main.
Modifier le notebook et committer
Sur la branche feature/demo-notebook, ouvrez fabric/notebooks/demo.ipynb et modifiez une cellule, par exemple :
print('Hello from Kwanzeo')
print('Déployé automatiquement via GitHub Actions')
Validez avec Commit changes.
Ouvrir la Pull Request
GitHub propose automatiquement une bannière Compare and pull request. Cliquez dessus, vérifiez que la base est main et la branche comparée feature/demo-notebook, remplissez le titre et la description puis créez la PR. Le pipeline CI se déclenche immédiatement.
Observer le pipeline CI
Sur la page de la Pull Request, faites défiler jusqu’à la section Checks. Le job test apparaît en cours d’exécution. Cliquez sur Details pour voir les logs en temps réel et attendez que les étapes passent au vert. En cas d’échec, lisez les logs, corrigez le fichier sur la même branche et committez à nouveau : la CI relance automatiquement sur le nouveau commit.
Merger la Pull Request
Une fois les checks verts, cliquez sur Merge pull request, confirmez, puis supprimez la branche feature qui a rempli son rôle.
Observer le déploiement DEV
Le merge sur main déclenche immédiatement le workflow cd-dev.yml. Dans l’onglet Actions, vérifiez que le workflow CD DEV passe au vert. Ouvrez ensuite votre workspace Fabric DEV : le notebook reflète la modification.
Comportement attendu : après l’exécution du pipeline CD DEV, le notebook peut apparaître dans Fabric avec le statut Uncommitted. Le déploiement via API REST est indépendant de la synchronisation Git native de Fabric, qui détecte alors une différence avec la branche associée. Cela n’affecte ni l’exécution du notebook ni le pipeline.
Déclencher le déploiement PROD
Le déploiement PROD ne se déclenche jamais automatiquement depuis main. Il nécessite la création et le push d’une branche release/*.
git checkout main
git pull origin main
git checkout -b release/v1.0.0
git push origin release/v1.0.0
Le push de cette branche déclenche le workflow cd-prod.yml. Dans l’onglet Actions, vérifiez qu’il passe au vert. Ouvrez ensuite le workspace Fabric PROD : le notebook y est déployé indépendamment du workspace DEV.
Conclusion
Le pipeline CI/CD Microsoft Fabric basé sur GitHub Actions est désormais opérationnel : code versionné, validé, déployé automatiquement en DEV et de manière contrôlée en PROD. Cette fondation peut être enrichie selon vos besoins, par exemple avec d’autres types d’artefacts Fabric, plus d’environnements, ou des étapes de validation avancées.
Poursuivre la lecture
Les différentes parties du tutoriel
Retrouvez les quatre parties de ce tutoriel sur la mise en place d’un pipeline CI/CD entre GitHub et Microsoft Fabric, depuis la préparation initiale jusqu’au test de bout en bout.