Question

Disons que nous avons un serveur d'intégration continue. Lorsque je me connecte, le post-hook extrait le dernier code, exécute les tests, met tout en package. Quel est le meilleur moyen d'automatiser également les modifications de la base de données?

Idéalement, je construirais un programme d'installation capable de créer une base de données à partir de zéro ou de mettre à jour une base de données existante à l'aide d'une méthode de synchronisation automatisée.

Était-ce utile?

La solution

Si vous avez la possibilité de définir et de contrôler l'ensemble du processus de gestion de la base de données et de création de la base de données, consultez DB Ghost - c’est plus qu’un outil, c’est un processus.

Si vous l'aimez et que vous pouvez l'implémenter, vous obtiendrez d'excellents résultats, mais c'est un peu un "tout ou rien". genre d'approche. Recommandé.

Autres conseils

Je suis récemment tombé sur un article qui pourrait être utile.

L'auteur a expliqué certaines des meilleures pratiques d'intégration continue, notamment les tests, le traitement et l'automatisation.

Voici quelques-uns des plats à emporter:

  • Dans de nombreux magasins, le code est testé sur l'unité au point de validation. Pour les bases de données, il est préférable d'exécuter tous les tests unitaires en même temps et en séquence par rapport à une base de données d'assurance qualité, par opposition au développement, dans le cadre de l'étape de test
  • .
  • L'étape de test est une partie essentielle de tout processus CI / CD. Les scripts de test, y compris les tests unitaires eux-mêmes, doivent également être versionnés dans le contrôle de code source, extraits au moment de l’étape de construction et exécutés
  • Extraire des données de la production est un moyen rapide, mais n’est jamais une bonne idée
  • La meilleure approche consiste à utiliser un outil ou un script pour créer rapidement, de manière répétée et fiable des données de test synthétiques pour vos tables transactionnelles
  • L'exécution de tests unitaires pour produire des résultats de synthèse manuels pour la consommation humaine va à l'encontre de l'automatisation. Nous avons besoin de résultats lisibles par machine, qui permettent à un processus automatisé d’abandonner, de créer des branches et / ou de continuer.
  • L'exécution d'un processus de CI, qui nécessite la réussite de 100% de tous les tests, revient à ne pas avoir de CI du tout, si le pipeline de flux de travail est configuré de manière atomique pour s'arrêter en cas d'échec, ce qui devrait être le cas. Pour enfiler l'aiguille, les tests doivent avoir des seuils intégrés, qui généreront une erreur en fonction du% de tests ayant échoué ou, dans certains cas, en cas d'échec de certains tests de priorité élevée.
  • Tous les processus doivent en fin de compte produire un résultat booléen de réussite ou d'échec, mais certains processus non automatisés peuvent facilement se retrouver dans votre pipeline de flux de travail CI (par exemple, les tests unitaires). Le logiciel doit être branché dans n’importe quel pipeline de flux de travail, en prenant les entrées connues et en produisant les sorties attendues - comme réussir, échouer.
  • Le processus CI / CD doit être abandonné en cas d’échec et un courrier électronique de notification doit être immédiatement envoyé au lieu de poursuivre le cycle du pipeline.
  • Le processus d'élément de configuration ne doit pas recommencer jusqu'à ce que les erreurs de la dernière construction soient corrigées. En cas d’échec, toute l’équipe doit recevoir la notification d’échec, comprenant autant de détails que possible sur les échecs possibles.
  • Si un pipeline prend 1 heure, du début à la fin, pour terminer, y compris tous les tests, tous les intervalles de génération doivent être définis sur au moins une heure et tous les nouveaux commits doivent être mis en file d'attente et appliqués au prochain. construire.
  • Aucun mot de passe en texte brut ne doit exister dans les scripts d'automatisation

Je vous déconseille d'utiliser une sauvegarde de base de données comme artefact de développement. La plupart des meilleures pratiques en matière de CI vous suggèrent de gérer le schéma, les procédures, les déclencheurs et les vues en tant qu'artefacts de développement de première classe. Les effets secondaires sont que vous pouvez aller plus loin et les utiliser pour créer une nouvelle base de données à tout moment. Idéalement, vous disposez également de certaines données pouvant être insérées dans la base de données.

Voici une version de notes de falaise pour vous mouiller les pieds, mais il y en a beaucoup dans cet espace:   http://www.infoq.info/news/2008/02/versioning_databases_series

J'aime certaines des idées de Scott Ambler ici. Le site est bon mais le livre est étonnamment profond pour un ensemble de problèmes aussi difficiles. http://www.agiledata.org/ http://www.amazon.com/exec/obidos/ASIN/0321293533/ambysoftinc

Red Gate est une solution assez robuste qui fonctionne immédiatement. Mais la meilleure chose à faire est que vous puissiez l'intégrer à votre processus d'intégration continue. Je l'utilise avec Msbuild et Hudson. expliquant rapidement comment cela fonctionne: http://blog.vincentbrouillet.com/post / 2011/02/10 / Synchronisation de schéma de base de données avec RedGate

si vous souhaitez en savoir plus, n'hésitez pas à demander

L'approche Red Gate utilisant le contrôle de source SQL et la ligne de commande SQL Compare Pro est détaillée avec des exemples de code ici: http:

Troy Hunt a écrit un article sur Simple Talk intitulé "Intégration continue pour les bases de données SQL Server": http://www.simple-talk.com/content/article.aspx ? article = 1247

Avez-vous examiné FluentMigrator ? Le téléchargement par défaut inclut des scripts Nant qu'il serait facile d'ajouter à un CI. Gratuit, open source et facile à utiliser. Fonctionne pour une grande variété de bases de données.

La dernière version (5.0) de DB Ghost ne souffre pas du caractère "caractère non ASCII". problème (cela signifie simplement que le fichier est encodé en UTF8) et il devrait pouvoir faire exactement ce dont vous avez besoin.

De plus, les outils peuvent être utilisés de manière autonome pour exécuter les différentes fonctions (script, construction, comparaison, mise à niveau et empaquetage) si vous le souhaitez, mais simplement que leur utilisation combinée fournit un processus complet de bout en bout la valeur globale supérieure à la somme de ses parties.

Pour modifier le schéma, vous devez mettre à jour les scripts de création d'objet individuel et les scripts d'insertion par table (pour les données de référence) conservés sous contrôle de code source, exactement comme si vous développiez une base de données greenfield «day one». Les outils de DB Ghost permettent d'activer tout cela en construisant ces scripts dans une toute nouvelle base de données (en utilisant l'intégration continue si nécessaire), puis en comparant et en mettant à niveau une base de données cible, qui peut être une copie de la base de données de production. Ce processus produit un script delta qui peut être utilisé sur la base de données de production réelle lors de la mise en production.

Vous pouvez même créer un projet de base de données Visual Studio et l'ajouter à vos solutions actuelles.

Malc

Je sais que ce message est ancien, mais nous avons une nouvelle solution qui adopte l'approche suivante:

  1. Les développeurs écrivent les modifications SQL individuelles et les valident contrôle.
  2. Notre programme ( OneScript ) extrait les fichiers de script de modification.     contrôle de la source, les filtre et les trie, et génère un seul     libérer le fichier de script.
  3. Ce fichier de script de version est ensuite appliqué à un         base de données pour faire une version.

Notre page d'accueil ici explique ce processus plus en détail et propose un lien vers un exemple les réalisant. se déplace automatiquement à partir d'un crochet Subversion. Si peu de temps après une validation, le développeur reçoit un e-mail indiquant si la publication a réussi ou comportait des erreurs. Le code PowerScript est inclus.

Clause de non-responsabilité - Je travaille pour la société qui fabrique OneScript.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top