SSIS est-il la seule partie de votre stack encore incapable de faire du CI/CD ?

Le DevOps moderne atteint la plus grande partie d’une plateforme de données Microsoft et s’arrête au projet SSIS. Les packages sont dans Git, le pipeline de release déploie le .ispac, et tout ce qui se trouve entre ces deux faits se fait à la main : merger du XML, mapper des variables d’environnement, et découvrir à la première exécution planifiée si la release a fonctionné.

Pourquoi SSIS résiste au CI/CD

• Un package est du XML qui se compare mal. Les coordonnées de mise en page, les GUID et la logique cohabitent dans le même fichier, donc un petit changement en paraît un gros et deux modifications d’un même package se mergent rarement sans risque.
• Les environnements sont des mappings. Dev, Test et Prod sont des variables d’environnement SSISDB et des mappings de paramètres, maintenus à la main et mis à jour avant chaque release.
• La release est un fichier, pas un diff. Déployer le .ispac remplace le projet. Ce qui a changé ne fait pas partie de ce qui est déployé, et le XML d’un package n’est pas quelque chose que l’outillage de revue peut contrôler dans une pull request, donc la validation attend la première exécution.
• Le rollback, c’est le fichier précédent. Revenir en arrière signifie redéployer le dernier .ispac et espérer que ses mappings correspondent encore. Ce que la release a déjà changé dans l’entrepôt n’en fait pas partie.

Rien de tout cela n’est la faute de SSIS. Il a été conçu avant que la livraison continue ne devienne la norme, et cela se voit.

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 son inverse existe avant qu’elle ne s’exécute.
• En versionnant l’intention, pas le XML. Git et Gitflow sur le modèle donnent un diff qui se lit comme un changement de l’entrepôt, pas comme un changement de mise en page de fichier.

Ce qui change avec Datavault Builder

Datavault Builder génère des scripts de déploiement et de rollback versionnés par environnement à partir du modèle, avec le support de Git et Gitflow intégré. Une release commence par la comparaison de deux états : votre environnement local, un état dans Git, un autre environnement actif, un fichier zip ou un dossier ; vous choisissez ensuite les différences à déployer.

• Le problème du merge disparaît. Deux ingénieurs modifient le modèle sur deux branches et mergent un modèle, pas un fichier de package. Les chargements sont régénérés à partir du résultat.
• Les environnements sont un paramétrage, pas une table de mappings. Les détails de connexion par environnement sont définis une seule fois ; la release pour Test ou Prod est générée avec ces valeurs appliquées.
• Chaque release porte son rollback. Et la version du modèle à laquelle elle appartient.
• Les différences sont comparées avant le déploiement. Ce que Prod est sur le point de recevoir est la liste des différences entre son état et le vôtre. 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.
• Votre outillage de pipeline reste en place. Azure DevOps ou GitHub Actions exécutent le package généré. Ils n’ont plus besoin de comprendre SSIS.

Ce qu’il faut décider

Auditez les journaux de déploiement du dernier trimestre et comptez deux choses : les releases qui ont nécessité un changement manuel de mapping d’environnement, et les merges de packages qui ont été réglés en refaisant le travail de quelqu’un. C’est la maintenance qu’une release générée supprime.