Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’APPLIQUE À :
Azure Data Factory Azure Synapse Analytics
Tip
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 !
Dans Azure Data Factory, l’introduction du cycle de vie du connecteur garantit que les clients ont toujours accès aux connecteurs les plus fiables, sécurisés et riches en fonctionnalités. Avec les phases de cycle de vie structurées, la mise à niveau majeure du connecteur évolue à travers des phases de cycle de vie distinctes, de la préversion à la disponibilité générale et à la fin du support, ce qui offre des attentes claires en matière de stabilité, de support et d’améliorations futures. Ce framework de cycle de vie garantit que les utilisateurs peuvent adopter en toute transparence de nouveaux connecteurs avec confiance, tirer parti des mises à jour régulières des performances et de la sécurité, et préparer à l’avance toutes les versions antérieures. En utilisant le contrôle de version dans le cycle de vie du connecteur, le service permet aux utilisateurs d’avoir une expérience d’intégration prévisible, transparente et future, ce qui réduit les risques opérationnels et améliore la fiabilité globale de la charge de travail.
Release rhythm
Les mises à niveau des connecteurs sont essentielles pour faire évoluer l’innovation de manière rapide, maintenir les performances, la compatibilité et la fiabilité. Ces mises à niveau se produisent généralement dans les scénarios suivants :
Nouvelles améliorations de fonctionnalités telles que la sécurité, les performances, etc.
Bien que le service évolue activement pour fournir les fonctionnalités les plus sécurisées et fiables dans le connecteur, l’application du cycle de vie du connecteur est une approche efficace pour s’assurer que les utilisateurs peuvent tirer pleinement parti des nouvelles améliorations à leur rythme gérable sans interruption de l’activité.
Modification du protocole introduite par les fournisseurs de sources de données externes, ce qui entraîne des modifications potentielles du comportement
Ces modifications ne sont pas toujours prévisibles de manière exhaustive et surviennent en raison d’une incompatibilité apportée par un fournisseur de source de données lui-même. Étant donné ces incertitudes, le contrôle de version garantit que les utilisateurs peuvent adopter le connecteur mis à jour (par exemple, version 2.0) tout en conservant une option de secours dans une période. Cela permet aux utilisateurs de bien planifier une mise à niveau de version pour prendre en charge les différences potentielles tout en fournissant aux utilisateurs un chemin de transition clair.
Correction des comportements inattendus
Dans certains cas, les versions antérieures du connecteur peuvent présenter des comportements inattendus ou bogues en raison de contraintes héritées. Lorsqu’une mise à niveau corrige ces comportements et améliore l’intégrité et la fiabilité des données, il peut également apporter inévitablement des changements de comportement. Dans ce cas, le contrôle de version joue un rôle crucial pour s’assurer que les utilisateurs sont conscients de ces modifications, peuvent les tester dans un environnement contrôlé et passer en douceur sans interruption.
En adoptant un cycle de vie de connecteur structuré avec le contrôle de version, le service fournit aux clients une transparence, un contrôle et une prévisibilité lors de l’introduction des mises à niveau du connecteur. Les utilisateurs peuvent évaluer en toute confiance de nouvelles versions, atténuer les risques associés aux changements de comportement et tirer parti d’améliorations continues tout en conservant la stabilité opérationnelle.
Le diagramme décrit le cycle de vie d’une version de connecteur de sa préversion privée à sa suppression.
Un cycle de vie de connecteur comprend plusieurs étapes avec une évaluation approfondie et mesurable pour garantir la qualité. Il inclut la préversion privée, la préversion publique, la disponibilité générale, la fin de la prise en charge et la version supprimée. Le tableau suivant répertorie le nom de l’étape et les critères appropriés.
| Stage | Description | Lifecycle |
|---|---|---|
| Private Preview | La phase de préversion privée marque la sortie initiale d'une nouvelle version de connecteur à un nombre limité d'utilisateurs. Pendant cette phase, les utilisateurs opt-in peuvent utiliser la dernière version du connecteur et fournir des commentaires. | 3 mois ou plus |
| Public Preview | Cette étape marque la première publication d'une nouvelle version du connecteur à tous les utilisateurs. Au cours de cette phase, les utilisateurs sont encouragés à essayer la dernière version du connecteur et à fournir des commentaires. Pour les connexions nouvellement créées, il est défini par défaut sur la dernière version du connecteur. Les utilisateurs peuvent revenir à la version précédente. | 1 mois ou plus* |
| General Availability | Une fois qu’une version du connecteur répond aux critères de disponibilité générale, elle est publiée au public et convient aux charges de travail de production. Pour atteindre cette étape, la nouvelle version du connecteur doit répondre aux exigences en termes de performances, de fiabilité et de capacité à répondre aux besoins de l’entreprise. | 12 mois ou plus* |
| Fin du support (EOS) annoncé | Lorsqu’une version de connecteur atteint son EOS, elle ne recevra aucune mise à jour ni prise en charge supplémentaire. Un avis de six mois est annoncé avant la date EOS de cette version. Ceci est documenté avec la date de suppression. | 6 mois avant la date de fin du support* |
| End-of-Support (EOS) | Une fois la date d’arrivée de EOS annoncée précédemment, la version du connecteur devient officiellement non prise en charge. Cela implique qu’il ne recevra aucune mise à jour ni correctifs de bogues et qu’aucun support officiel ne sera fourni. Les utilisateurs ne pourront pas créer de charges de travail sur une version qui se trouve sous la phase EOS. L’utilisation d’une version de connecteur non prise en charge est au risque de l’utilisateur. La charge de travail exécutée sur la version d’EOS peut ne pas échouer immédiatement. Le service peut accélérer le passage à la phase finale à tout moment, à la discrétion de Microsoft en raison de problèmes de sécurité en suspens ou d’autres facteurs. | / |
| Version removed | Une fois que la version du connecteur passe sa date EOS, le service supprime tous les composants associés à cette version du connecteur. Cela implique que les pipelines utilisant cette version de connecteur interrompent l’exécution. | 1 à 12 mois après la date de fin de support* |
* Ces chronologies sont fournies en tant qu’exemple et peuvent varier en fonction de différents facteurs. Les chronologies du cycle de vie sont soumises à des modifications à la discrétion de Microsoft.
Présentation des versions du connecteur
Pour gérer efficacement les mises à jour de connexion, il est important de comprendre le contrôle de version et comment interpréter la modification. Les connecteurs dans Azure Data Factory suivent généralement le contrôle de version sous la forme Major.Minor (par exemple, 1.2) :
- Mises à jour majeures (x.0) : Il s’agit de modifications importantes qui nécessitent une révision des modifications avant la mise à niveau.
- Mises à jour mineures (1.x) : Celles-ci peuvent introduire de nouvelles fonctionnalités ou correctifs, mais avec des modifications mineures apportées au comportement existant.
Comment Data Factory gère la mise à niveau de la version du connecteur
Les mises à jour de version majeure et mineure peuvent inclure des modifications qui peuvent avoir un impact sur la sortie de votre pipeline ou les composants associés. Pour vous aider à vous préparer, nous vous informerons à l’avance, en fournissant une fenêtre de test et de mise à niveau vers la dernière version. Vous trouverez des exemples spécifiques de modifications de version dans la documentation de chaque connecteur individuel. Nous vous recommandons d’examiner et de mettre à niveau dès que possible vers la dernière version de façon à tirer parti des améliorations les plus récentes, et à garantir que vos pipelines continuent à s’exécuter de manière fluide et fiable.
Lorsque de nouvelles versions sont publiées, le service commence à toujours définir les dernières versions par défaut pour tous les nouveaux services liés créés. À ce stade, les utilisateurs peuvent revenir à la version antérieure si nécessaire.
Lorsqu’une version atteint sa date de fin de support, les utilisateurs ne sont plus autorisés à créer un service lié sur cette version.
En plus des mises à jour majeures et mineures, le service fournit également de nouvelles fonctionnalités et correctifs de bogues entièrement compatibles avec votre configuration existante. Ces modifications ne nécessitent pas de mise à jour pour le connecteur. Selon la nature de la modification, les utilisateurs peuvent recevoir automatiquement les améliorations ou avoir la possibilité d’activer les nouvelles fonctionnalités en fonction des besoins. Cette approche garantit une expérience transparente tout en conservant la stabilité et la flexibilité.