Déploiements SQL avec SSDT DB

Ce n’est pas nouveau, le versionning et le déploiement de base données dans un projet est un sujet sensible. D’un côté, nous avons les développeurs très bien outillés pour tout ce qui est déploiement automatisé et tests. Et de l’autre, nous, développeurs BI archaïques et mal équipés… mais est-ce toujours vrai ?

Notre métier est, depuis quelques temps, en pleine mutation. Avec l’arrivée des méthodes Agiles, du devops, du lean IT… les cycles de vie des solutions (développement, déploiement…) évoluent, et il va falloir se remettre en question pour ne pas subir. Voire au contraire, s’améliorer!

Les projets SQL Server Data Tool Database ( SSDT DB ) posent une des premières briques dans cette direction.

En bref, SSDT DB permet de centraliser la structure de notre base de données dans un projet Visual Studio. Une solution permettra de regrouper un ensemble de BDD, de créer des références entre elles et ainsi servir de référence pour être facilement comparée à différents environnements (Dev/Preprod/Prod). Terminés les écarts entre nos différents environnements !

Développements

Difficile de parler de déploiement sans évoquer brièvement le développement. Déjà là, tout est fait pour une transition en douceur car l’outil est très permissif. Un projet peut être créé from scratch ou à partir d’une base existante et la mise à jour peut se faire dans les deux sens :

• Je travaille avec Visual Studio, je mets à jour mon environnement de Dev.
• Je travaille sous Management Studio, je mets mon projet à partir de mon environnement de Dev.

Dans tous les cas, votre solution sera LA référence de votre serveur et les déploiement se feront par le biais de la fonction de comparaison.

Comparaison/Déploiement

La fonction accessible avec un clic droit sur le projet souhaité :

Il faudra sélectionner l’environnement cible à mettre à jour ou référence (Dev, Preprod, Prod), puis le sens de la mise à jour avec l’option de switch :

L’outil détectera les différences, créations/modifications/suppressions, entre la source et la cible et il sera possible de sélectionner les éléments à mettre à jour :

La mise à jour de la base de données peut se faire directement avec la fonction “Update”, mais il sera possible de générer le script SQLcmd à fournir à l’équipe de déploiement, ou simplement pour le compléter avec une initialisation ou rattrapage de données si besoin.

Certains auront remarqué l’icone de configuration, il est en effet possible d’ignorer certains éléments comme les commentaires, les triggers…et pour éviter les boulettes, le script terminera en erreur en cas de suppression de données par défaut, il suffira alors de décocher l’option :

TFS

L’utilisation optimale de l’outil se fait avec TFS qui permettra en plus de gérer le travail collaboratif, de versionner notre base de données, de mettre à jour nos environnements avec la version souhaitée et de générer le script d’update rapidement.

Et concrètement ?

Personnellement, je ne suis pas encore complètement à l’aise avec l’environnement SSDT DB. Certaines modifications comme un ALTER de structure de table ou de vue sont plus simples à effectuer sous Visual Studio, mais les tests de procédures ou de vérifications des données ne sont pas (encore?) naturels. Il est difficile de savoir à quel environnement nous sommes connectés et le réflexe du “F5” pour exécuter du code sous Management Studio lance un build sous Visual Studio est une habitude qu’il est difficile de perdre.

J’utilise donc encore en majeure partie Management Studio mais la mise à jour du projet est très simple et le gain de temps pour les déploiements est notable. Il faut juste garder en tête que la solution est la référence.

Tips

Quelques trucs et astuces pour gagner du temps :

• Il est possible d’enregistrer les fichiers “compare”. Il sera judicieux d’en créer un par environnement dans vos projets,  ce qui évitera de refaire toute la manip de comparaison à chaque fois et gagner un temps précieux.
• Il est bon de savoir que chaque fichier de comparaison conserve la sélection des objets que vous sélectionnez. Créer un fichier par demande facilitera le déploiement d’une modification en travail collaboratif.
• Pour conserver les scripts des différentes demandes utilisateur ou différentes versions, vous pouvez créer un projet vide qui référencera tous les autres. Les scripts devront être paramétrés afin de ne pas être pris en compte lors du build ou de créer fichier de type “Script (Not in Build)”.

Pour aller plus loin avec les déploiements : Déploiements BI avec TFS détaillés lors de la session aux JSS 2014