Chaque release Azure Data Factory tourne-t-elle à la bataille de templates ARM ?

Azure Data Factory cache bien son JSON jusqu’au jour d’une release. Ce jour-là, le template ARM, les fichiers de paramètres, les paramètres globaux et les surcharges de linked services apparaissent tous d’un coup, et une seule incohérence de type bloque le déploiement jusqu’à ce que quelqu’un la trouve.

Pourquoi les releases sont fragiles

• Le pipeline est du JSON, que vous le voyiez ou non. L’éditeur visuel écrit des définitions de pipeline, de dataset et de linked service, et la publication les compile en template ARM. Certaines équipes l’encapsulent dans Bicep ; l’artefact en dessous est le même.
• Les environnements sont des fichiers de paramètres. Dev, Test et Prod diffèrent par leurs chaînes de connexion, leurs clés et leurs noms, et ces différences se trouvent dans des fichiers maintenus à la main.
• Les dépendances sont implicites. Les datasets et les linked services sont partagés entre les pipelines ; en changer un pour un pipeline que vous avez testé le change pour ceux que vous n’avez pas testés.
• Le rollback est un redéploiement. Revenir en arrière suppose de redéployer le template précédent, et tout ce qu’il référence doit encore exister.

ADF fait ce qu’une ressource Azure fait : il se déploie comme un template. Les templates sont faits pour provisionner de l’infrastructure statique, des comptes de stockage et des réseaux. Un schéma d’entrepôt possède un état et change à chaque release, ce qui ne correspond pas à ce que cet outil sait faire.

Où la gestion des releases devrait se situer

• Dans le générateur. Si l’entrepôt vient d’un modèle, une release est la différence entre deux états de ce modèle, et l’outil sait de quoi chaque différence dépend.
• Avec le rollback inclus. Une release générée sait ce qu’elle a changé, donc le script inverse existe avant que la release ne s’exécute.
• Comparée, pas espérée. La différence entre Test et Prod devrait être un rapport, pas une découverte.

Ce qui change avec Datavault Builder

Datavault Builder construit une release en comparant deux états, avec le support de Git et Gitflow intégré. Un état est votre environnement local, un état stocké dans Git, un autre environnement actif, un fichier zip ou un dossier ; la comparaison liste les différences, et vous choisissez lesquelles déployer.

• Pas de template à maintenir. La release est l’ensemble des différences que vous avez sélectionnées, généré pour l’environnement cible. Sélectionnez un produit de données et l’outil propose le hub, le satellite, la table de staging et la source dont il a besoin.
• Le rollback est généré avec elle. Chaque release porte son inverse, et la version du modèle à laquelle elle appartient.
• Les environnements sont comparés, pas espérés. Ce que Prod est sur le point de recevoir est la liste des différences entre son état et celui que vous déployez.
• La dérive des sources ne nécessite pas de release. Les colonnes manquantes se chargent à null avec un avertissement, les colonnes dont la taille augmente sont élargies, les nouvelles colonnes sont une mise à jour de mapping.
• Votre outillage CI reste en place. Azure DevOps ou GitHub Actions exécutent le package généré ; ils n’ont plus à comprendre l’entrepôt.

Ce qu’il faut décider

Auditez le processus de release et comptez deux choses : les fichiers de paramètres et les surcharges par environnement qu’il maintient, et les releases du dernier trimestre qui ont échoué à l’étape du template. C’est la maintenance qu’une release générée supprime.