Gérer les environnements
Je pense que vous ne voulez certainement pas être forcé dans une seule version de base de données. Vous avez suffisamment de développeurs pour que vous ayez inévitablement plusieurs flux de travail de développement et des exigences pour appliquer des correctifs à l'environnement de production actuel, indépendamment des flux de travail de développement.
Vous pouvez utiliser Liquibase ou un processus manuel pour produire des scripts de patch pour mettre à niveau les versions. Je suggère de commencer par un processus manuel et d'utiliser l'outil de comparaison de schéma pour l'AQ sur les correctifs. Une synchronisation propre, automatisée et transparente d'une base de données non complexe est un peu utopique.
Votre modèle de données central peut être conservé dans le système qui vous convient. J'ai tout utilisé, des outils de référentiel d'entreprise fastidieux pour créer des scripts de table. Les scripts de création de table fonctionnent bien avec les outils de contrôle de source ordinaires tels que la subversion et tous les outils de référentiel ne font pas un bon travail de versioning.
Quoi que vous utilisiez comme référentiel de modèle de données maître, vous avez besoin d'un mécanisme assez propre pour déployer un environnement à partir de ce modèle. Il doit être structuré de manière à faciliter le déploiement dans un environnement. Vous avez également besoin d'un mécanisme pour patcher d'une version publiée à la suivante.
Ce que j'ai fait
J'ai fait ce qui suit dans le passé lorsque je gérais des environnements de développement. Ce n'est pas particulièrement de la haute technologie, mais il se prête au contrôle de version et aux builds automatisés, donc il est facile de déployer un environnement vers une version spécifique, et maintenir un grand nombre d'environnements est assez pratique.
Maintenir un référentiel central: il peut s'agir d'un ensemble de scripts de création de base de données conservés dans un système de contrôle de version ou d'un modèle de référentiel dans un outil de modélisation de données. Faites votre choix. Ce modèle devrait avoir un mécanisme de construction qui permet à un environnement d'être déployé à partir des scripts sans beaucoup d'intervention manuelle.
Si vous avez beaucoup de données de référence, vous aurez besoin d'un mécanisme de chargement. Selon la façon dont vous voulez le faire, vous pouvez le conserver dans une base de données ou dans un ensemble de fichiers. L'avantage des fichiers est qu'ils peuvent également être versionnés et étiquetés à partir du même système de contrôle de version que votre base de code. Un tas de fichiers CSV et de scripts de chargement en bloc dans un référentiel de contrôle de source peuvent le faire assez facilement.
Une option pour déployer des environnements de développement consiste à effectuer des sauvegardes de la base de données de production corrigées à la version appropriée et à les rendre disponibles pour les développeurs à restaurer dans un environnement de développement.
Rendez-le facile à déployer: comme tout processus de génération de CI, la base de données doit être déployable à partir d'un seul script. Configurez-le de sorte que les connexions à la base de données puissent être paramétrées, ou que le script soit indépendant de l'emplacement et puisse simplement être exécuté via la connexion.
Scripts de patch: vous aurez besoin de restaurer et probablement de restaurer les scripts de chaque version publiée.
Créez des environnements de test à partir du modèle de référentiel: cela garantit que le développement sur des environnements qui ne sont pas synchronisés avec le référentiel est pris en compte dans les tests.
Testez le processus de déploiement: les scripts de correction automatisés, quelle que soit leur création, doivent pouvoir être testés. Les outils de comparaison de schémas sont assez bons pour cela, même si vous ne les utilisez pas pour générer les scripts de patch.
Créez un environnement de référence avec le modèle de référentiel que vous avez testé
Créez un environnement de test de fumée avec une sauvegarde de votre version de production ou une version basée sur la version actuelle.
Exécutez le script de patch sur l'environnement de test de fumée.
Utilisez l'outil de comparaison de schémas pour comparer l'environnement de test de fumée avec l'environnement de référence. Le script de correctif doit avoir pour résultat que les deux bases de données sont identiques, afin que vous puissiez rechercher les différences.
Ce que j'aime dans ce processus
C'est un peu lourd et a été conçu pour être déployé dans des environnements de production assez bureaucratiques et opaques. Cependant, il présente les atouts suivants:
Les développeurs peuvent bricoler là où ils en ont besoin.
Plusieurs branches et flux de développement peuvent être adaptés.
Les scripts de déploiement eux-mêmes peuvent être testés de manière reproductible. Cela est très utile pour arrêter les combats de déploiement, car la répétabilité peut être démontrée.
Les outils de comparaison de schémas fournissent une assurance qualité sur le déploiement lui-même.
Les tests sont toujours effectués par rapport à ce qui devrait être publié, et cela corrigera les problèmes résultant de la désynchronisation des environnements.
Le déploiement basé sur des modèles de référentiel et des scripts de correctif signifie que les déchets non contrôlés ne sont pas accidentellement migrés des environnements de développement vers la production.
Une grande partie du processus peut être automatisée, bien qu'il soit souvent souhaitable de préparer et de tester manuellement les scripts des correctifs de déploiement.
Les environnements sont bon marché et faciles à déployer sans avoir à sauter à travers des cerceaux.
Les développeurs sont obligés de créer un système qui se prête à un processus de construction et de déploiement simple.
Les développeurs sont obligés d'apprendre les tâches d'administration de base de base de données, mais les environnements de test et de production sont isolés des erreurs noob.
Comment cela répond à vos besoins
Les développeurs disposent d'une copie locale des données pour exécuter le code de développement par rapport aux
scripts de déploiement ou aux images de base de données, ce qui signifie qu'ils peuvent configurer un environnement à partir de n'importe quelle version disponible.
Capable de restaurer la structure de la base de données dans un ensemble de modifications précédent
, trié par les scripts de déploiement. Que ce soit via DDL ou des images de sauvegarde de base de données de test créées via un processus contrôlé, les développeurs peuvent afficher un environnement dans n'importe quelle version spécifique que vous possédez.
Capable de séparer les changements de schéma de nouvelles fonctionnalités par rapport aux changements de correctifs de conception de schéma Les
correctifs vers une version commune peuvent être conservés dans une fourchette distincte dans l'arborescence svn. Si les sauvegardes de base de données sont utilisées comme environnements de référence, elles doivent être stockées quelque part avec la même structure de dossiers que la branche des projets de contrôle de source.
Capable de modifier la structure de la base de données localement pour les tests
Le processus de déploiement simple permet aux développeurs de bricoler et de restaurer facilement un environnement dans un état local, ou de créer un environnement de référence pour effectuer des comparaisons et effectuer des changements par rapport.
