Intégration et livraison continues dans Azure Data Factory

S'APPLIQUE À : Azure Data Factory Azure Synapse Analytics

L’intégration continue consiste à tester automatiquement et, dès que possible, chaque modification apportée à votre code base. La livraison continue fait suite au test effectué pendant l’intégration continue, et envoie (push) les modifications à un système de préproduction ou de production.

Dans Azure Data Factory, l’intégration et la livraison continues (CI/CD) signifie déplacer des pipelines Data Factory d’un environnement (développement, test, production) vers un autre. Azure Data Factory utilise des modèles Azure Resource Manager pour stocker la configuration de vos différentes entités Data Factory (par exemple, pipelines, jeux de données et flux de données). Deux méthodes sont recommandées pour promouvoir une fabrique de données dans un autre environnement :

• Déploiement automatisé grâce à l'intégration de Data Factory avec Azure Pipelines
• Chargez manuellement un modèle Resource Manager à l’aide de l’intégration de l’expérience utilisateur Data Factory à Azure Resource Manager.

Cycle de vie d’intégration et de livraison continues

L'aperçu suivant montre le cycle de vie CI/CD dans une usine de données Azure configurée avec Azure Repos Git. Pour plus d’informations sur la configuration d’un référentiel Git, consultez Contrôle de source dans Azure Data Factory.

1. Une fabrique de données de développement est créée et configurée avec Azure Repos Git. Tous les développeurs doivent avoir l’autorisation de créer des ressources Data Factory telles que des pipelines et des jeux de données.

2. Un développeur crée une branche de fonctionnalité pour apporter une modification. Les commits signés ne sont pas pris en charge dans Data Factory. Il débogue les exécutions de son pipeline avec ses modifications les plus récentes. Pour plus d’informations sur le débogage d’une exécution de pipeline, consultez Développement itératif et débogage avec Azure Data Factory.

3. Une fois satisfait de ses modifications, le développeur crée une pull request de sa branche de fonctionnalité vers la branche principale ou de collaboration pour que ces modifications soient examinées par des pairs.

4. Une fois la demande de tirage (pull) approuvée et les modifications fusionnées dans la branche primaire, les modifications sont publiées dans la fabrique de développement.

5. Lorsque l’équipe est prête à déployer les modifications apportées à une fabrique de test ou UAT (Test d’acceptation utilisateur), l’équipe accède à sa version Azure Pipelines et déploie la version souhaitée de la fabrique de développement sur UAT. Ce déploiement s’effectue dans le cadre d’une tâche Azure Pipelines et utilise Resource Manager paramètres de modèle pour appliquer la configuration appropriée.

6. Une fois les modifications vérifiées dans la fabrique de test, opérez le déploiement vers la fabrique de production en utilisant la tâche suivante de la mise en production de pipelines.

L’image suivante met en lumière les différentes étapes de ce cycle de vie.

Meilleures pratiques pour CI/CD

Si vous utilisez une intégration Git avec votre fabrique de données, et disposez d’un pipeline CI/CD qui déplace vos modifications du développement aux tests, puis en production, nous vous recommandons les bonnes pratiques suivantes :

• Intégration Git. Configurez uniquement votre fabrique de données de développement avec l’intégration Git. Les modifications au niveau des tests et de la production sont déployées via CI/CD et ne nécessitent pas d’intégration Git.

• Script de pré-déploiement et de post-déploiement. Avant l’étape de déploiement Resource Manager dans CI/CD, vous devez effectuer certaines tâches, telles que l’arrêt et le redémarrage des déclencheurs et l’exécution du nettoyage. Nous vous recommandons d’utiliser des scripts PowerShell avant et après la tâche de déploiement. Pour plus d’informations, consultez Mettre à jour des déclencheurs actifs. L’équipe Data Factory a fourni un script à utiliser, qui se trouve en bas de cette page.

  Note

  Utilisez le PrePostDeploymentScript.Ver2.ps1 si vous souhaitez désactiver/désactiver uniquement les déclencheurs qui ont été modifiés au lieu d’activer/désactiver tous les déclencheurs pendant CI/CD.

  Avertissement

  Veillez à utiliser PowerShell Core dans la tâche ADO pour exécuter le script

  Avertissement

  Si vous n’utilisez pas les dernières versions de PowerShell et du module Data Factory, vous pourriez rencontrer des erreurs de désérialisation lors de l’exécution des commandes.

• Runtimes d’intégration et partage. Les runtimes d’intégration ne changent pas souvent et sont similaires dans toutes les phases de CI/CD. Data Factory s’attend donc à ce que vous ayez le même nom, type et sous-type d’exécution d’intégration à toutes les étapes du CI/CD. Si vous voulez partager les runtimes d’intégration dans toutes les phases, envisagez d’utiliser une fabrique ternaire qui contiendra uniquement les runtimes d’intégration partagés. Vous pouvez utiliser cette fabrique partagée dans tous vos environnements en tant que type de runtime d’intégration lié.

  Note

  Le partage du runtime d’intégration est disponible uniquement pour les runtimes d’intégration auto-hébergés. les runtimes d'intégration Azure-SSIS ne prennent pas en charge le partage.

• Déploiement du point de terminaison privé managé. Si un point de terminaison privé existe déjà dans une fabrique et que vous essayez de déployer un modèle ARM qui contient un point de terminaison privé portant le même nom mais dont les propriétés sont modifiées, le déploiement échoue. En d’autres termes, vous pouvez déployer avec succès un point de terminaison privé, à condition qu’il ait les mêmes propriétés que celui qui existe déjà dans la fabrique. Si une propriété est différente d’un environnement à un autre, vous pouvez la remplacer en paramétrant cette propriété et en fournissant la valeur correspondante pendant le déploiement.

• Key Vault. Lorsque vous utilisez des services liés dont les informations de connexion sont stockées dans Azure Key Vault, gardez des coffres séparés pour différents environnements. Vous pouvez également configurer des niveaux d’autorisation distincts pour chaque coffre de clés. Par exemple, vous ne souhaitez peut-être pas que les membres de votre équipe disposent d’autorisations sur les secrets de production. Si vous suivez cette approche, gardez les mêmes noms secrets sur toutes les étapes. Si vous conservez les mêmes noms de secrets, vous n'avez pas besoin de paramétrer chaque chaîne de connexion entre les environnements CI/CD, car la seule chose qui change est le nom du coffre de clés, qui est un paramètre distinct.

• Nommage des ressources. En raison des contraintes du modèle ARM, des problèmes de déploiement peuvent survenir si vos ressources contiennent des espaces dans le nom. L'équipe Azure Data Factory recommande d'utiliser des caractères « _ » ou « - » au lieu d'espaces pour les ressources. Par exemple, « Pipeline_1 » est un nom préférable à « Pipeline 1 ».

• Modification du dépôt. Azure Data Factory (ADF) gère automatiquement le contenu du dépôt Git. Modifier ou ajouter manuellement des fichiers ou dossiers sans lien dans n’importe quel dossier de données du dépôt ADF Git pourrait provoquer des erreurs de chargement des ressources. Par exemple, la présence de fichiers .bak peut provoquer une erreur ADF CI/CD, donc retirez-les pour charger ADF.

• Indicateurs de contrôle d’exposition et de fonctionnalité. En équipe, il arrive que vous fusionniez des changements, mais vous ne voulez pas qu’ils s’exécutent dans des environnements élevés comme la production (PROD) et l’assurance qualité (QA). Pour gérer un tel scénario, l’équipe ADF recommande le concept DevOps utilisant les indicateurs de fonctionnalité. Dans ADF, vous pouvez combiner les paramètres globaux et l’activité IfCondition pour masquer des ensembles de logique en fonction de ces indicateurs d’environnement.

  Pour apprendre à configurer un drapeau de fonctionnalité, consultez le tutoriel vidéo suivant :

Fonctionnalités non prises en charge

• Par conception, Data Factory ne supporte pas la sélection de commits ni la publication sélective des ressources. La publication inclut toutes les modifications apportées dans l’usine de données.

  • Les entités Data Factory dépendent les unes des autres. Par exemple, les déclencheurs dépendent des pipelines et les pipelines dépendent des jeux de données et d’autres pipelines. La publication sélective d’un sous-ensemble de ressources peut engendrer des comportements inattendus et des erreurs.
  • Dans les rares cas où vous avez besoin d’une publication sélective, envisagez d’utiliser un correctif logiciel. Pour plus d’informations, consultez Environnement de production de correctif logiciel.

• L'équipe d'Azure Data Factory ne recommande pas d'attribuer des contrôles Azure RBAC à des entités individuelles (par exemple, pipelines et jeux de données) dans une data factory. Par exemple, si un développeur a accès à un pipeline ou à un jeu de données, il doit être en mesure d’accéder à tous les pipelines ou jeux de données de la fabrique de données. Si vous estimez que vous devez implémenter de nombreux rôles Azure dans une fabrique de données, envisagez de déployer une deuxième fabrique de données.

• Vous ne pouvez pas publier à partir de branches privées.

• Vous ne pouvez actuellement pas héberger de projets sur Bitbucket.

• Vous ne pouvez pas actuellement exporter et importer des alertes et des métriques comme paramètres.

• Depuis le 1er novembre 2021, les modèles ARM partiels de votre branche de publication ne sont plus pris en charge. Si votre projet utilisait cette fonctionnalité, passez à un mécanisme pris en charge pour les déploiements par l’utilisation ARMTemplateForFactory.json de fichiers or linkedTemplates .

  

Contenu connexe

• Améliorations du déploiement continu
• Automatisez l'intégration continue en utilisant les versions d’Azure Pipelines
• Promouvoir manuellement un modèle de gestion des ressources pour chaque environnement
• Utiliser des paramètres personnalisés avec un modèle Resource Manager
• modèles de gestionnaire de ressources liées
• Utilisation d’un environnement de production de correctif logiciel
• Exemple de script de pré-déploiement et de post-déploiement