Quelle est la bonne façon de migrer les modifications de base de données du développement vers le contrôle qualité vers les environnements de production? Actuellement, nous:
- Scriptez la modification dans un fichier SQL et associez-la à un élément de travail TFS.
- Le travail est évalué par des pairs
- Lorsque le travail est prêt pour les tests, le SQL est exécuté sur QA.
- Le travail est testé QA
- Lorsque le travail est prêt pour la production, le SQL est exécuté sur les bases de données de production.
Le problème est que c'est très manuel. Il repose sur le développeur qui se souvient de joindre le sql ou le peer-reviewer le rattrapant si le développeur oublie. Parfois, il finit par être le testeur ou le déployeur d'AQ qui découvre le problème.
Un problème secondaire est que vous finissez parfois par devoir coordonner manuellement les modifications si deux tâches distinctes modifient le même objet de base de données. C'est peut-être juste ainsi, mais il semble toujours qu'il devrait y avoir un moyen automatisé de «signaler» ces problèmes ou quelque chose.
Notre configuration: Notre boutique de développement est pleine de développeurs avec beaucoup d'expérience DB. Nos projets sont très orientés DB. Nous sommes principalement une boutique .NET et MS SQL. Actuellement, nous utilisons des éléments de travail MS TFS pour suivre notre travail. Ceci est pratique pour les modifications de code car il relie les ensembles de modifications aux éléments de travail afin que je puisse savoir exactement quelles modifications je dois inclure lors de la migration vers les environnements QA et Production. Nous n'utilisons pas actuellement un projet de base de données, mais nous pourrions y basculer à l'avenir (cela fait peut-être partie de la réponse).
Je suis très habitué à ce que mon système de contrôle de source s'occupe de ce genre de choses pour moi et j'aimerais avoir la même chose pour mon SQL.