Discussion :

[crystal_palace]

Bonjour,

Je suis actuellement à la recherche d'une solution pour la gestion des changements de structure dans mes bases de données, j'aimerais savoir si quelqu'un pourrait me conseiller des produits/solutions qui permettent de faire ça.

Je vous explique:

À l'heure actuelle, voici le déroulement des opérations lorsqu'un développeur veut effectuer une modification sur une base de données :

1. Il dépose un fichier au format SQL contenant son code (ALTER COLUMN, CREATE TABLE,...) sur un serveur de fichier.
2. Je contrôle le ficher, notamment qu'il ne comporte uniquement des modifications qui portent sur la structure et non pas sur les données.
3. Je l'exécute sur le serveur de test.
4. Les développeurs et utilisateurs de l'environnement de test valident les modifications.
5. Enfin le script est appliqué sur l'environnement de production.

Je pensais à créer un projet dans un dépôt GIT pour chaque base qui contiendrait tous les scripts. Les développeurs pourraient faire des "merge request" et j'accepterai ou non les modifications.
Cela me permettrait de garder toutes les modifications et de pouvoir reconstruire ma structure en passant tous les scripts afin de pouvoir retrouver un état de la base à un instant T.

Qu'est-ce que vous en pensez ? Si vous avez de meilleures alternatives, je suis preneur.

Merci d'avance pour vos réponses.

[pubpub]

Bonjour,
Pourquoi ne pas utiliser un "SQL Server Database Project" dans Visual Studio ?
@+

[crystal_palace]

@pubpub : Merci ton conseil, c'est exactement ce dont j'avais besoin.
Bonne journée à toi !

[mikedavem]

Hello,

Tout dépend du rythme de mise à jour et la maturité de l'entreprise sur des processus CI/CD chez toi. Gérer toi même le projet VS peut vite être périlleux.
Dans mon cas, si je devais à chaque fois valider un script SQL provenant d'une équipe de développement je deviendrai rapidement le goulet d'étranglement (1 DBA vs 60 Devs) car nous pouvons avoir des releases - inclus des scripts SQL - jusqu'à plusieurs fois par jour.

En gros, les changements de données et les mises à jour de schéma sont pris par 2 processus différents:
- Le changement de schéma + versionning est automatiquement géré par les DEVs et une repo GIT + Flyway pour la partie déploiement - Migration-Based (VS est plutôt orienté State-Based). J'interviens uniquement sur des cas spécifiques où le changement de schéma peut etre intrusif pendant la journée. Cela demande un peu d'éducation de la part des DEVs et une bonne collaboration avec le DBA. On arrive aussi à détecter et fixer les problèmes en amont sur l'environnement d'acceptation.
- La partie données est pris dans un processus semi automatisé à base de tickets. J'ai un regard dessus pour éviter les mises à jour bloquantes. Même chose, on a pas mal de choses qu'on corrige au niveau de l'acceptation.

Bien entendu comme tout ne passe pas forcément par moi, nous avons dû renforcer le système de monitoring en le rendant plus "observable" d'un point de vue plus globale à l'application.

++

[SQLpro]

Perso je met en place un déclencheur DDL pour capturer toutes les modif dans la base de dev.....

A +

[crystal_palace]

@mikedavem :

Après avoir tester "SQL Server Database Project" de VS, le coté State-based me pose effectivement quelques problèmes notamment au niveau du controle des sources.
Je souhaite également mettre en place un processus CI/CD pour l'évolution des bases de données, GIT+Flywaydb semble vraiment faire l'affaire, mais je regarde aussi du côté de liquibase ou la version community comporte un peu plus de fonctions que flywaydb.
Quand tu parles de renforcer le monitoring pour le rendre plus observable d'un point de vue plus global à l'application, tu parles de la mise en place d'audit et d'outil de corrélation des données ?

@SQLpro

L'utilisation de déclencheurs DDL ne rend-elle pas trop compliqué le versionnement des changements ?

[mikedavem]

@mikedavem :
Je souhaite également mettre en place un processus CI/CD pour l'évolution des bases de données, GIT+Flywaydb semble vraiment faire l'affaire, mais je regarde aussi du côté de liquibase ou la version community comporte un peu plus de fonctions que flywaydb.

Peu importe l'outil à partir du moment qu'il fasse le job escompté

Quand tu parles de renforcer le monitoring pour le rendre plus observable d'un point de vue plus global à l'application, tu parles de la mise en place d'audit et d'outil de corrélation des données ?

Entre autre oui. Dans notre cas nous avons migré la partie monitoring de SQL Server sur la plateforme commune de monitoring basé sur Prometheus et Grafana avec des dashboards orientés "super utilisateurs" et DBA.

1) Cela permet de renforcer la collaboration et discussions entre équipes (le facteur humain est aussi une composante importante de l'observabilité) et on peut travailler ensembe sur l'établissement d'une télémétrie adaptée au besoin.

2) Il est maintenant plus simple de corréler des métriques de l'ensemble de l'application (orienté microservices) avec celles de l'infrastructure de bases de données. L'analyse rétrospective est beaucoup plus simple maintenant

3) Il nous manquait une certaine visibilité sur les potentiels impacts des événements provenants soit du pipeline de livraison continu soit des changements faits par l'équipe opérationnelle au niveau des instances (changement de config + ajout d'une base etc ...). Il a fallu développer une interface (principalement basée sur des jobs SQL + audit SQL Server and framework PowerShell utilisé par l'ITSM) qui permet d'envoyer diverses notifications au système de monitoring sous la forme d'annotations dans Grafana. Ainsi, si on observe un changement au niveau des métriques SQL, on peut facilement corréler avec le déploiement d'une release au travers de flyway ou un numéro de ticket ITSM pour un changement au niveau de la config ou un événement lié à un changement qui n'aurait pas été fait au travers des processus habituels.

L'utilisation de déclencheurs DDL ne rend-elle pas trop compliqué le versionnement des changements ?

On a pensé à cette solution mais pas pour le versionning qui se gère bien plus facilement au travers des adéquates mais pour le logging des changements chez nous (Git + Flyway). Au final parce que nous utilisons flyway, nous avons déjà ces informations à disposition, ce qui évite une gestion plus lourde aux travers des déclencheurs DDL.

++