Contrôle de code source dans Azure Data Factory

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !

Par défaut, l’interface utilisateur d’Azure Data Factory publie directement pour le service de fabrique de données. Cette expérience présente les limites suivantes :

• Le service Data Factory n’inclut pas de référentiel pour stocker les entités JSON de vos modifications. La seule façon d’enregistrer les modifications consiste à utiliser le bouton Publier tout pour publier toutes les modifications directement vers le service de fabrique de données.
• Le service de fabrique de données n’est pas optimisé pour la collaboration ou le contrôle de version.
• Le modèle Azure Resource Manager requis pour déployer Data Factory n’est pas inclus.

Pour améliorer l’expérience de création, Azure Data Factory permet de configurer un dépôt Git avec Azure Repos ou GitHub. Git est un système de contrôle de version qui facilite le suivi des modifications et la collaboration. Cet article explique comment configurer et utiliser un référentiel Git, met en évidence les meilleures pratiques et constitue un guide de résolution des problèmes.

Vous pouvez également référencer l’intégration et la livraison continues (CI/CD) dans Azure Data Factory pour en savoir plus sur le modèle CI/CD plus étendu, dont le contrôle de code source est un aspect critique.

Notes

Nous avons ajouté la prise en charge publique de GitHub sur Azure Gov et Microsoft Azure géré par 21Vianet. Consultez le blog de l'annonce.

Pour en savoir plus sur la façon dont Azure Data Factory s’intègre à git, consultez le didacticiel vidéo de 15 minutes ci-dessous :

Avantages de l’intégration Git

Voici quelques-uns des avantages que l’intégration Git apporte à l’expérience de création :

• Contrôle de code source : lorsque vos charges de travail de fabrique de données sont cruciales, vous pouvez intégrer votre fabrique à Git pour bénéficier de plusieurs avantages de contrôle de code source tels que les suivants :
  • Possibilité de suivre/auditer les modifications.
  • Possibilité d’annuler les modifications qui ont introduit de bogues.
• Enregistrements partiels : lorsque vous créez pour le service de fabrique de données, vous ne pouvez pas enregistrer les modifications en tant que brouillon, et toutes les publications doivent passer par la validation de la fabrique de données. Si vos pipelines ne sont pas finis ou si vous ne souhaitez tout simplement pas perdre de modifications en cas de panne de votre ordinateur, l’intégration à Git permet d’apporter des modifications incrémentielles aux ressources de la fabrique de données, quel qu’en soit l’état. La configuration d’un référentiel Git vous permet d’enregistrer les modifications, et donc de publier uniquement quand vous êtes satisfait des tests effectués sur vos modifications.
• Collaboration et contrôle : si plusieurs membres de votre équipe contribuent à la même fabrique, vous pouvez leur permettre de collaborer via un processus de révision du code. Vous pouvez également configurer votre fabrique de manière à ce que tous les contributeurs n’aient pas des autorisations égales. Certains membres de l’équipe peuvent n’être autorisés qu’à apporter des modifications via Git, tandis que d’autres sont autorisés à publier les modifications dans la fabrique.
• Intégration continue et livraison continue améliorées : si vous déployez sur plusieurs environnements au travers d’un processus de livraison continue, l’intégration à Git facilite certaines actions. Certaines de ces actions sont les suivantes :
  • Configurez votre pipeline de mise en production afin qu’il se déclenche automatiquement dès que des modifications sont apportées à votre fabrique « dev ».
  • Personnalisez les propriétés de votre fabrique disponibles en tant que paramètres dans le modèle Resource Manager. Cela permet de ne conserver que les propriétés requises en tant que paramètres, et de coder en dur tout le reste.
• Meilleures performances : Une fabrique moyenne avec l’intégration Git se charge 10 fois plus rapidement qu’une création pour le service de fabrique de données. Cette amélioration des performances est due au fait que les ressources sont téléchargées via Git.

Notes

La création directe avec le service Data Factory est désactivée dans l’expérience en matière d’interface utilisateur Azure Data Factory quand un dépôt Git est configuré. Les modifications apportées via PowerShell ou un Kit de développement logiciel (SDK) sont publiées directement dans le service Data Factory et ne sont pas entrées dans Git.

Se connecter à un référentiel Git

Il existe quatre façons différentes de connecter un référentiel Git à votre fabrique de données pour Azure Repos et GitHub. Une fois que vous êtes connecté à un référentiel Git, vous pouvez afficher et gérer votre configuration dans le hub de gestion sous Configuration Git dans la section Contrôle de code source.

Méthode de configuration 1 : page d'accueil

Dans la partie supérieure de la page d’accueil Azure Data Factory, sélectionnez Configurer le dépôt de code.

Méthode de configuration 2 : Zone de travail de création

Dans la zone de travail de création de l’expérience en matière d’interface utilisateur Azure Data Factory, sélectionnez le menu déroulant Data Factory, puis Configurer le dépôt de code.

Méthode de configuration 3 : Hub de gestion

Accédez au hub de gestion dans Azure Data Factory Studio. Sélectionnez Configuration Git dans la section Contrôle de code source. Si aucun référentiel n’est connecté, sélectionnez Configurer.

Méthode de configuration 4 : Lors de la création de la fabrique

Lorsque vous créez une fabrique de données dans le Portail Azure, vous pouvez configurer les informations de référentiel Git dans l’onglet Configuration Git.

Remarque

Lors de la configuration de Git dans le Portail Azure, certains paramètres tels que le nom du projet et le nom du référentiel ne figurent pas dans une liste déroulante et doivent donc être entrés manuellement.

Créer avec l’intégration Azure Repos Git

La création visuelle avec l’intégration Azure Repos Git prend en charge le contrôle du code source et la collaboration pour les utiliser sur vos pipelines Data Factory. Vous pouvez associer une fabrique de données à un dépôt d’organisation Azure Repos Git pour le contrôle du code source, la collaboration, la gestion des versions, etc. Une seule organisation Azure Repos Git peut avoir plusieurs dépôts, mais un dépôt Azure Repos Git ne peut être associé qu’à une seule fabrique de données. Si vous n’avez pas de dépôt ni d’organisation Azure Repos, suivez ces instructions pour créer vos ressources.

Notes

Vous pouvez stocker les fichiers de scripts et de données dans un dépôt Azure Repos Git. Toutefois, vous devez charger les fichiers manuellement dans le stockage Azure. Un pipeline de fabrique de données ne charge pas automatiquement les fichiers de scripts ou de données stockés dans un référentiel Azure Repos Git sur le stockage Azure. Des fichiers supplémentaires, tels que des modèles ARM, des scripts ou des fichiers de configuration, peuvent être stockés dans le référentiel en dehors du dossier mappé. Dans ce cas, n’oubliez pas qu’une tâche supplémentaire est nécessaire pour générer/déployer et interagir avec les fichiers stockés en dehors du dossier Azure DevOps mappé.

Paramètres Azure Repos

Le volet de configuration vous explique pas à pas comment configurer les paramètres suivants du référentiel de code :

Setting	Description	Valeur
Type de référentiel	Type du dépôt de code Azure Repos.	Azure DevOps Git ou GitHub
Microsoft Entra ID	Votre nom de locataire Microsoft Entra.	<your tenant name>
Organisation Azure Repos	Nom de votre organisation Azure Repos. Vous trouverez le nom de votre organisation Azure Repos sur https://{organization name}.visualstudio.com. Vous pouvez vous connecter à votre organisation Azure Repos pour accéder à votre profil Visual Studio et visualiser vos dépôts et projets.	<your organization name>
Nom du projet	Nom de votre projet Azure Repos. Vous trouverez le nom de votre projet Azure Repos sur https://{organization name}.visualstudio.com/{project name}.	<your Azure Repos project name>
RepositoryName	Nom de votre dépôt de code Azure Repos. Les projets Azure Repos contiennent des dépôts Git pour gérer votre code source à mesure que votre projet se développe. Vous pouvez créer un nouveau référentiel ou utiliser un référentiel existant déjà présent dans le projet.	<your Azure Repos code repository name>
Branche de collaboration	Votre branche de collaboration Azure Repos utilisée pour la publication. Par défaut, il s’agit de main. Modifiez ce paramètre au cas où vous souhaitez publier des ressources à partir d’une autre branche.	<your collaboration branch name>
Branche Publier	La branche Publier est la branche de votre référentiel dans laquelle les modèles ARM associés à la publication sont stockés et mis à jour. Par défaut, il s’agit de adf_publish.	<your publish branch name>
Dossier racine	Votre dossier racine de votre branche de collaboration Azure Repos.	<your root folder name>
Import existing Data Factory resources to repository (Importer des ressources Data Factory existantes dans le référentiel)	Indique s’il convient d’importer des ressources de fabrique de données existantes à partir du canevas de création de l’expérience utilisateur dans un dépôt Azure Repos Git. Activez la case pour importer vos ressources de fabrique de données dans le référentiel Git associé au format JSON. Cette action exporte chaque ressource individuellement (autrement dit, les services et jeux de données liés sont exportés dans des fichiers JSON distincts). Lorsque cette case n’est pas activée, les ressources existantes ne sont pas importées.	Activée (par défaut)
Branche sur laquelle importer la ressource	Indique dans quelle branche les ressources de la fabrique de données (pipelines, ensembles de données, services liés, etc.) sont importées. Vous pouvez importer des ressources dans l’une des branches suivantes : a. Collaboration b. Créer c. Utiliser l’existant

Notes

Si vous utilisez Microsoft Edge et que vous ne voyez aucune valeur dans la liste déroulante de votre compte Azure DevOps, ajoutez https://*.visualstudio.com à la liste des sites de confiance.

Modification des paramètres de dépôt

Si des ajustements doivent être apportés aux paramètres de votre dépôt Git Azure Repos configuré, vous pouvez choisir Modifier.

Vous pouvez mettre à jour votre branche de publication et décider de désactiver ou non le bouton Publier à partir du studio ADF. Si vous choisissez de désactiver le bouton Publier à partir du studio, il est grisé dans le studio. Cela permet d’éviter de remplacer le dernier déploiement de publication automatisé.

Utiliser un autre locataire Microsoft Entra

Le dépôt Git Azure Repos peut se trouver dans un autre locataire Microsoft Entra. Pour spécifier un autre locataire Microsoft Entra, vous devez avoir des autorisations d’administrateur sur l’abonnement Azure que vous utilisez. Pour plus d’informations, consultez Modifier l’administrateur de l’abonnement.

Important

Pour se connecter à une autre instance Microsoft Entra ID, l’utilisateur connecté doit être membre de cet annuaire Active Directory.

Ajouter votre compte Microsoft personnel

Pour utiliser un compte Microsoft personnel à des fins d'intégration de Git, vous pouvez lier votre référentiel Azure personnel au répertoire Active Directory de votre organisation.

1. Ajoutez votre compte Microsoft personnel au répertoire Active Directory de votre organisation en tant qu’invité. Pour plus d’informations, consultez Ajouter des utilisateurs Microsoft Entra B2B Collaboration dans le portail Azure.

2. Connectez-vous au Portail Azure avec votre compte Microsoft personnel. Basculez ensuite vers le répertoire Active Directory de votre organisation.

3. Accédez à la section Azure DevOps qui affiche désormais votre référentiel personnel. Sélectionnez le référentiel et connectez-vous à Active Directory.

Au terme de cette procédure de configuration, votre référentiel personnel est disponible lorsque vous configurez l’intégration de Git dans l’interface utilisateur de Data Factory.

Pour plus d’informations sur la connexion d’Azure Repos à l’annuaire Active Directory de votre organisation, consultez Connecter votre organisation à Microsoft Entra ID.

Créer avec l’intégration de GitHub

La création avec l’intégration de GitHub prend en charge le contrôle du code source et la collaboration pendant l’utilisation de vos pipelines de fabrique de données. Vous pouvez associer une fabrique de données à un référentiel de compte GitHub pour le contrôle du code source, la collaboration et la gestion des versions. Un seul compte GitHub peut héberger plusieurs référentiels, et chaque référentiel peut être associé à plusieurs fabriques de données. En configurant chaque fabrique de données pour utiliser une branche différente dans le même référentiel, vous pouvez gérer des environnements distincts (tels que le développement, la gestion intermédiaire et la production) tout en gérant leurs configurations indépendamment. Si vous n’avez pas un compte ou un référentiel GitHub, suivez ces instructions pour créer vos ressources.

L’intégration de GitHub à Data Factory prend en charge GitHub public (c'est-à-dire https://github.com ), GitHub Enterprise Cloud et GitHub Enterprise Server. Vous pouvez utiliser des référentiels GitHub publics et privés avec Data Factory à condition de disposer des autorisations de lecture et d'écriture pour ceux-ci dans GitHub. Pour vous connecter à un référentiel public, sélectionnez l’option Utiliser le lien du référentiel, car il n’est pas visible dans le menu déroulant Nom du référentiel. L’intégration du serveur GitHub Enterprise d’ADF fonctionne uniquement avec les versions officiellement prises en charge du serveur GitHub Enterprise.

Pour les référentiels appartenant au compte GitHub de l’organisation, l’administrateur doit autoriser l’application ADF. Pour les dépôts appartenant à un compte d’utilisateur GitHub, un utilisateur avec au moins une autorisation de collaborateur peut autoriser l’application ADF. Cette autorisation ne donne pas à l’application ADF un accès direct à tous les référentiels détenus par le compte/organisation, mais permet uniquement à l’application ADF d’agir au nom de l’utilisateur pour accéder aux référentiels en fonction des autorisations d’accès de ce dernier.

Remarque

Si vous utilisez Microsoft Edge, les versions de GitHub Enterprise inférieures à 2.1.4 ne fonctionneront pas avec celui-ci. GitHub prend officiellement en charge >=3.0, ce qui convient pour ADF. À mesure que GitHub modifie sa version minimale, les versions prises en charge par ADF changent également.

Paramètres GitHub

Remarque

Si vous rencontrez l’erreur Échec de la liste des référentiels GitHub. Vérifiez que le nom du compte est correct et que vous êtes autorisé à effectuer l’action., vérifiez que vous utilisez le nom de propriétaire correct et non l’URL du référentiel GitHub. Par exemple, si l’URL du référentiel est https://github.com/contoso/contoso-ads, le propriétaire est contoso, et non l’URL complète.

Le volet de configuration affiche les paramètres du dépôt GitHub suivants :

Paramètre	Description	Valeur
Type de référentiel	Type du dépôt de code Azure Repos.	GitHub
Utiliser Serveur GitHub Enterprise	Cochez la case pour sélectionner Serveur GitHub Enterprise.	non sélectionné (par défaut)
URL GitHub Enterprise Server	URL racine de GitHub Enterprise (doit être HTTPS pour un serveur local GitHub Enterprise). Par exemple : https://github.mydomain.com. Obligatoire uniquement si l’option Utiliser Serveur GitHub Enterprise est sélectionnée	<your GitHub Enterprise Server URL>
Propriétaire du dépôt GitHub	Organisation ou compte GitHub propriétaire du dépôt. Vous pouvez trouver ce nom dans https://github.com/{owner}/{repository nom}. En naviguant sur cette page, vous êtes invité à entrer les informations d’identification GitHub OAuth sur votre compte ou organisation GitHub. Si vous sélectionnez Utiliser GitHub Enterprise Server, une boîte de dialogue s’affiche pour vous permettre d’entrer votre jeton d’accès.	<your GitHub repository owner name>
Nom du dépôt	Le nom de votre référentiel de code GitHub. Les comptes GitHub contiennent des référentiels Git pour gérer votre code source. Vous pouvez créer un nouveau référentiel ou utiliser un référentiel existant déjà présent dans le compte. Spécifiez le nom de votre référentiel de code GitHub lorsque vous sélectionnez Sélectionner un dépôt.	<your repository name>
Lien de dépôt Git	Le lien de votre référentiel de code GitHub. Spécifiez votre lien de dépôt de code GitHub lorsque vous sélectionnez Utiliser le lien du référentiel.	<your repository link>
Branche de collaboration	Votre branche de collaboration GitHub utilisée pour la publication. Par défaut, il s’agit de l’adresse e-mail principale. Modifiez ce paramètre au cas où vous souhaitez publier des ressources à partir d’une autre branche. Vous pouvez également créer une nouvelle branche de collaboration ici.	<your collaboration branch>
Branche Publier	La branche de votre référentiel dans laquelle les modèles ARM associés à la publication sont stockés et mis à jour.	<your publish branch name>
Dossier racine	Votre dossier racine de votre branche de collaboration GitHub.	<your root folder name>
Import existing resources to repository (Importer des ressources existantes dans le référentiel)	Indique s’il faut importer des ressources de fabrique de données existantes à partir de la zone de travail de création de l’expérience en matière d’interface utilisateur dans un dépôt GitHub. Activez la case pour importer vos ressources de fabrique de données dans le référentiel Git associé au format JSON. Cette action exporte chaque ressource individuellement (autrement dit, les services et jeux de données liés sont exportés dans des fichiers JSON distincts). Lorsque cette case n’est pas activée, les ressources existantes ne sont pas importées.	Activée (par défaut)
Importer la ressource dans cette branche	Indique dans quelle branche les ressources de la fabrique de données (pipelines, ensembles de données, services liés, etc.) sont importées.

Modification des paramètres de dépôt

Si des ajustements doivent être apportés aux paramètres de votre dépôt GitHub configuré, vous pouvez choisir Modifier.

Vous pouvez mettre à jour votre branche de publication et décider de désactiver ou non le bouton Publier à partir du studio ADF. Si vous choisissez de désactiver le bouton Publier à partir du studio, il est grisé dans le studio. Cela permet d’éviter de remplacer le dernier déploiement de publication automatisé.

Organisations GitHub

La connexion à une organisation GitHub nécessite que l’organisation accorde l’autorisation à Azure Data Factory. Un utilisateur disposant d’autorisations d’administrateur sur l’organisation doit effectuer les étapes ci-dessous pour permettre à la fabrique de données de se connecter.

Se connecter à GitHub public ou à GitHub Enterprise Cloud pour la première fois dans Azure Data Factory

Si vous vous connectez à GitHub public ou à GitHub Enterprise Cloud depuis Azure Data Factory pour la première fois, suivez ces étapes pour vous connecter à une organisation GitHub.

1. Dans le volet Configuration git, entrez le nom de l’organisation dans le champ Compte GitHub. Une invite de connexion à GitHub s’affiche.
2. Connectez-vous avec vos informations d’identification d’utilisateur.
3. Vous êtes invité à autoriser Azure Data Factory en tant qu’application appelée AzureDataFactory. Sur cet écran, une option vous permet d’accorder à ADF l’autorisation d’accéder à l’organisation. Si vous ne voyez pas l’option permettant d’accorder une autorisation, demandez à un administrateur d’accorder manuellement l’autorisation par le biais de GitHub.

Une fois ces étapes effectuées, votre fabrique peut se connecter aux référentiels publics et privés au sein de votre organisation. Si vous ne parvenez pas à vous connecter, essayez de vider le cache du navigateur et réessayez.

Déjà connecté à GitHub public ou GitHub Enterprise Cloud à l’aide d’un compte personnel

Si vous êtes déjà connecté à GitHub public ou à GitHub Enterprise Cloud et que vous avez uniquement accordé l’autorisation d’accéder à un compte personnel, suivez les étapes ci-dessous pour accorder des autorisations à une organisation.

1. Accédez à GitHub et ouvrez Paramètres.

   

2. Sélectionnez Applications. Dans l’onglet Authorized OAuth apps (Applications OAuth autorisées), vous devez trouver AzureDataFactory.

   

3. Sélectionnez l’application et accordez-lui l’accès à votre organisation.

   

Une fois ces étapes effectuées, votre fabrique peut se connecter aux référentiels publics et privés au sein de votre organisation.

Se connecter à GitHub Enterprise Server

Si vous vous connectez à GitHub Enterprise Server, vous devez utiliser un jeton d’accès personnel pour l’authentification. Découvrez comment créer un jeton d’accès personnel dans Création d’un jeton d’accès personnel.

Remarque

GitHub Enterprise Server se trouve dans votre environnement privé auto-hébergé. Vous devez donc avoir un contrôle total sur le pare-feu, les stratégies réseau et le VPN lorsque vous utilisez cette authentification. Pour plus d’informations, consultez À propos de GitHub Enterprise Server.

Limitations connues de GitHub

• Vous pouvez stocker les fichiers de scripts et de données dans un référentiel GitHub. Toutefois, vous devez charger les fichiers manuellement dans le stockage Azure. Un pipeline Data Factory ne charge pas automatiquement les fichiers de scripts ou de données stockés dans un référentiel GitHub sur le stockage Azure.

• Les versions de GitHub Enterprise antérieures à 2.14.0 ne fonctionnent pas dans le navigateur Microsoft Edge.

• L’intégration de GitHub aux outils de création visuelle Data Factory ne fonctionne que dans la version généralement disponible de Data Factory.

Connexion à Azure DevOps Server 2022

Si vous vous connectez à Azure DevOps Server 2022, vous devez utiliser un jeton d’accès personnel pour l’authentification. Découvrez comment créer un jeton d’accès personnel ici.

Connectez-vous à Azure DevOps local en indiquant les paramètres Azure DevOps Server URL et Azure DevOps Project Collection

Fournissez le jeton avec une étendue d’accès en lecture/écriture pour le code.

Gestion de versions

Les systèmes de contrôle de version (également appelé contrôle du code source) permettent aux développeurs de collaborer sur le code et de suivre les modifications apportées à la base de code. Le contrôle du code source est un outil essentiel pour les projets impliquant plusieurs développeurs.

Création de branches de fonctionnalités

Chaque dépôt Azure Repos Git associé à une fabrique de données comporte une branche de collaboration. (main est la branche de collaboration par défaut). Les utilisateurs peuvent également créer des branches de fonctionnalités en cliquant sur + Nouvelle branche dans la liste déroulante des branches.

Une fois que le volet Nouvelle branche s’affiche, entrez le nom de votre branche de fonctionnalité, puis sélectionnez une branche à partir de laquelle vous souhaitez baser le travail.

Lorsque vous êtes prêt à fusionner les modifications de votre branche de fonctionnalités dans votre branche de collaboration, cliquez sur la liste déroulante des branches et sélectionnez Créer la demande de tirage (pull request) . Cette action vous dirige vers Azure Repos Git où vous pouvez augmenter les demandes de tirage, procéder à des revues du code et fusionner les modifications dans votre branche de collaboration. (main est la valeur par défaut). Vous êtes uniquement autorisé à publier sur le service Data Factory à partir de votre branche de collaboration.

Configurer les paramètres de publication

Par défaut, la fabrique de données génère les modèles Resource Manager de la fabrique publiée et les enregistre dans une branche nommée adf_publish. Pour configurer une branche de publication personnalisée, ajoutez un fichier publish_config.json au dossier racine dans la branche de collaboration. Lors de la publication, ADF lit ce fichier, recherche le champ publishBranch, puis enregistre tous les modèles Resource Manager dans l’emplacement spécifié. Si la branche n’existe pas, la fabrique de données le crée automatiquement. Voici un exemple de ce à quoi ressemble ce fichier :

{
    "publishBranch": "factory/adf_publish"
}

Azure Data Factory ne peut avoir qu’une seule branche de publication à la fois. Quand vous spécifiez une nouvelle branche de publication, Data Factory ne supprime pas la branche de publication précédente. Si vous souhaitez la supprimer, faites-le manuellement.

Notes

Data Factory lit uniquement le fichier publish_config.json lors du chargement de la fabrique. Si la fabrique est déjà chargée sur le portail, actualisez le navigateur pour que vos modifications prennent effet.

Publier les modifications de code

Après avoir fusionné des modifications dans la branche de collaboration (main est la valeur par défaut), cliquez sur Publier pour publier manuellement les modifications de votre code dans la branche primaire pour le service Data Factory.

Un volet latéral s’ouvre, dans lequel vous confirmez que la branche de publication et les modifications en attente sont correctes. Une fois que vous avez vérifié vos modifications, cliquez sur OK pour confirmer la publication.

Important

La branche primaire n’est pas représentative de ce qui est déployé dans le service Data Factory. La branche primaire doit être publiée manuellement sur le service Data Factory.

Meilleures pratiques d'intégration Git

Autorisations

En général, vous ne souhaitez pas autoriser tous les membres de l’équipe à mettre à jour la fabrique de données. Les paramètres des autorisations suivants sont recommandés :

• Tous les membres de l’équipe doivent disposer d’autorisations de lecture dans la fabrique de données.
• Seul un ensemble sélectionné de personnes doit être autorisé à publier sur la fabrique de données. Pour ce faire, ces personnes doivent avoir le rôle Contributeur de Data Factory sur le groupe de ressources contenant la fabrique de données. Pour plus d’informations sur les autorisations, consultez Rôles et autorisations pour Azure Data Factory.

Il est recommandé de ne pas autoriser les archivages directs dans la branche de collaboration. Cette restriction peut aider à éviter les bogues, car chaque archivage passe par un processus de demande de tirage décrit dans Création de branches de fonctionnalités.

Utilisation de mots de passe à partir d’Azure Key Vault

Il est recommandé d’utiliser Azure Key Vault pour stocker les chaînes de connexion, les mots de passe ou l’authentification d’identité managée pour des services liés Data Factory. Pour des raisons de sécurité, la fabrique de données ne stocke pas les secrets dans Git. Toutes les modifications apportées aux services liés contenant des secrets tels que des mots de passe sont immédiatement publiées dans le service Azure Data Factory.

L’utilisation de Key Vault de l’authentification MSI facilite également l’intégration et le déploiement continus, car vous n’avez pas à fournir ces secrets lors du déploiement du modèle Resource Manager.

Résolution des problèmes d’intégration Git

Branche de publication obsolète

Voici quelques exemples de situations qui peuvent provoquer une branche de publication obsolète :

• Un utilisateur a plusieurs branches. Dans une branche de fonctionnalité, l’utilisateur a supprimé un service lié qui n’est pas associé à AKV (les services liés non-AKV sont publiés immédiatement, qu’ils soient dans Git ou non) et n’a jamais fusionné la branche de fonctionnalité dans la branche de collaboration.
• Un utilisateur a modifié la fabrique de données à l’aide du SDK ou de PowerShell.
• Un utilisateur a déplacé toutes les ressources vers une nouvelle branche et a essayé de publier pour la première fois. Les services liés doivent être créés manuellement au moment de l’importation des ressources.
• Un utilisateur charge manuellement un service lié ou un fichier JSON de runtime d’intégration non-AKV. Il fait référence à cette ressource à partir d’une autre ressource telle qu’un jeu de données, un service lié ou un pipeline. Un service lié non-AKV créé par le biais de l’interface utilisateur est publié immédiatement parce que les informations d’identification doivent être chiffrées. Si vous chargez un jeu de données qui fait référence à ce service lié et que vous essayez de le publier, l’interface utilisateur autorise cette opération puisqu’il existe dans l’environnement Git. Il est rejeté au moment de la publication dans la mesure où il n’existe pas dans le service de fabrique de données.

Si la branche de publication n’est pas synchronisée avec la branche primaire et contient des ressources obsolètes malgré une publication récente, vous pouvez recourir à l’une des solutions suivantes :

Option 1 : utiliser la fonctionnalité de remplacement en mode réel

Il publie ou remplace le code de votre branche de collaboration dans le mode en direct. Le code de votre référentiel est considéré comme source de vérité.

Flux de code : Branche de collaboration -> Mode réel

Option 2 : déconnecter le référentiel git et le reconnecter

Elle importe le code du mode réel dans la branche de collaboration. Elle considère le code en mode réel comme étant la source fiable.

Flux de code : Mode réel -> Branche de collaboration

1. Supprimez votre dépôt Git actuel
2. Reconfigurez Git avec les mêmes paramètres, mais vérifiez que Importer les ressources Data Factory existantes dans le dépôt est sélectionné et choisissez Branche de collaboration (même branche)
3. Créez une demande de tirage (pull request) pour fusionner les modifications apportées à la branche de collaboration.

Notes

Il est nécessaire de créer et de fusionner une demande de tirage si vous travaillez dans un référentiel qui n’autorise pas les validations directes. Dans la plupart des organisations, les soumissions dans le référentiel nécessitent une révision avant la fusion. Par conséquent, la meilleure pratique consiste généralement à utiliser cette approche. Toutefois, dans certains cas, aucune révision n’est nécessaire, auquel cas il n’est pas nécessaire de créer et de fusionner une demande de tirage( pull request), mais les modifications peuvent être directement validées dans la branche de collaboration.

Choisissez l’une ou l’autre des méthodes en fonction des besoins.

Toutes les ressources apparaissant comme nouvelles à la publication

Lors de la publication, toutes les ressources peuvent apparaître comme nouvelles, même si elles ont déjà été publiées. Cela peut se produire si la propriété lastCommitId est réinitialisée sur la propriété repoConfiguration de la fabrique, soit en redéployant un modèle ARM de la fabrique, soit en mettant à jour la propriété repoConfiguration de la fabrique via PowerShell ou l’API REST. La poursuite de la publication des ressources peut résoudre le problème, mais pour éviter qu’il se reproduise, évitez de mettre à jour la propriété repoConfiguration de la fabrique.

Passer à un autre dépôt Git

Pour basculer vers un autre référentiel Git, accédez à la page de configuration de Git dans le hub de gestion, sous Contrôle de code source. Sélectionnez Déconnecter.

Entrez le nom de votre fabrique de données, puis cliquez sur Confirmer pour supprimer le dépôt Git associé à votre fabrique de données.

Après avoir supprimé l’association avec le dépôt actuel, vous pouvez configurer vos paramètres Git pour utiliser un autre dépôt, puis importer des ressources Data Factory dans le nouveau dépôt.

Important

La suppression de la configuration Git d’une fabrique de données ne supprime rien dans le référentiel. La fabrique contient toutes les ressources publiées. Vous pouvez continuer à la modifier directement par rapport au service.

Contenu connexe

• Pour en savoir plus sur la surveillance et la gestion des pipelines, consultez Surveiller et gérer les pipelines par programmation.
• Pour implémenter l’intégration et le déploiement continus, consultez Intégration et livraison continues (CI/CD) dans Azure Data Factory.