J'ai utilisé avec succès la méthodologie suivante, élaborée dans Version Control et votre base de données :
- maintenir un numéro de version dans les métadonnées (j'utilise une propriété étendue de base de données)
- tout changement de schéma est codé comme un script qui met à jour de la version actuelle vers la version suivante
- l'application est livrée avec tous les scripts pour passer de la version 0 (déploiement initial) à la version actuelle
- Chaque changement est effectué via un script. Y compris les modifications des données «système» comme les dictionnaires et les entrées de table de recherche.
- une fois déployée, l'application vérifie la version du schéma sur disque, puis exécute toutes les étapes de mise à niveau pour amener le schéma à la version requise actuelle
J'entends souvent l'opinion de «en quoi est-ce différent de simplement garder les scripts de définition d'objet sous contrôle de source?». La différence est énorme, car lorsque vous déployez une nouvelle version de votre application, vous n'allez pas simplement créer une nouvelle base de données. La plupart du temps, votre application devra mettre à niveau la base de données existante, y compris les données existantes . Il s'agit d'une différence cruciale, vos étapes de mise à niveau doivent garantir l'intégrité et la cohérence des données existantes pendant la mise à niveau. Certaines opérations sont triviales dans le code (ajoutez une colonne non nullable avec une valeur par défaut au script de définition d'objet de table, c'est fait), mais elles sont en fait extrêmement douloureuses lors du déploiement réel (la table a 1,5 milliard de lignes, la colonne d'ajout s'épuiserait de l'espace de journal si cela est fait de la manière «simpleton»).
Comment cela fonctionne avec la ramification:
- lorsque la branche est créée, elle capture la version actuelle du schéma, par exemple la version 1.6
- lorsque l'équipe commence à travailler sur la branche, elle ajoute une nouvelle version, 1.7, puis commence à coder l'étape de mise à niveau de 1.6 à 1.7
- l'étape de mise à niveau est modifiée à mesure que les modifications sont effectuées dans la branche. Il exécute toujours le script de mise à niveau de la version 1.6 vers la version 1.7, mais ce que font exactement ces scripts est soumis aux itérations de code normales et aux enregistrements dans la branche
- la branche termine le développement, elle se prépare à l'intégration inverse (à fusionner de nouveau dans la ligne de base)
- il fait une nouvelle intégration directe de la ligne de base à la branche. Si l'intégration n'apporte aucun changement à la version du schéma, tout va bien, la branche peut inverser l'intégration telle quelle. la version 1.7 devient la nouvelle version de base.
- le truc intéressant, c'est quand une autre branche a inversé l'intégration dans la base entre-temps et maintenant la version du schéma de base est devenue, disons, 1.7. Dans ce cas, notre branche doit faire passer sa version de schéma cible de déploiement à 1.8 et passer en revue l'étape de mise à niveau qui était auparavant de 1.6 à 1.7 pour voir comment elle fonctionne dans le nouvel environnement, passant de 1.7 à 1.8. Les conflits de schéma logique doivent être résolus, le script peut nécessiter des modifications, des tests doivent être effectués. Une fois terminée, la branche peut inverser l'intégration dans la base. La version cible déployée du produit devient désormais la version 1.8.
- lorsqu'une autre branche qui a bifurqué à la version 1.6 du schéma veut procéder à une intégration inversée, elle doit faire passer sa version de schéma à 1.9, tester le script de mise à niveau de 1.8 à 1.9, puis il peut réintégrer la base.
Notez qu'aucun outil n'est impliqué, aucun script de différence de schéma magique, aucun assistant et aucun script de clic droit-générer-impliqué. Il s'agit d'un processus 100% axé sur les développeurs, basé sur la source (scripts). Beaucoup trouvent tout ce processus complexe, mais cela fonctionne. En fait, en tant qu'utilisateur SQL Server, vous avez déjà tiré parti des résultats de ce processus dans votre utilisation quotidienne de SQL Server: SQL Server lui-même utilise un processus de mise à niveau de base de données très similaire et, comme vous vous en doutez probablement, le processus de développement de produits fait un usage intensif de ramification et le problème que vous avez mentionné est un problème très réel qui doit être résolu.
BTW, comment la ramification / intégration se produit réellement diffère entre les produits de contrôle de source, j'utilise les termes familiers du mode de fonctionnement d' intégration forcée .