Wie verwalten Sie die Datenbank-Revisionen auf ein mittelgroßes Projekt mit Niederlassungen?

Question

Bei der Arbeit haben wir 4 Menschen arbeiten zusammen an verschiedenen Projekten.Für jedes Projekt, wir alle haben eine lokalen Kopie arbeiten wir auf und dann es ist eine Entwicklung, das staging und die live-Implementierung, die zusammen mit allen Zweigen wir haben (wir verwenden subversion).Unsere Datenbank ist MySQL.

Meine Frage ist also, was ist ein guter Weg, um zu verwalten, welche änderungen der Datenbank vorgenommen wurden jede Bereitstellung (und für die Entwickler Ihre lokalen Kopien).Gerade jetzt jede Veränderung geht in eine text-Datei, die Zeitstempel im Namen und setzen Sie in einen Ordner unter dem Projekt.Dies funktioniert nicht sehr gut, um ehrlich zu sein..Ich brauche eine Lösung, die helfen, halten Spur von dem, was angewendet wurde, wo.

Answer 1

Wenn Ihre Datenbank abbildet schön auf einen Satz von Datenzugriffsobjekte betrachten ‚Migration‘ verwenden. Die Idee ist, Ihr Datenmodell als Anwendungscode zu speichern, mit den Schritten für vorwärts und rückwärts durch jede Datenbankversion zu bewegen.

Ich glaube, Rails haben es zuerst .

Java hat mindestens ein Projekt .

Und hier ist ein .NET Migration Bibliothek .

Versionen zu ändern, führen Sie ein einfaches Skript, das Sie alle der oben oder unten Versionen Schritte durch Sie auf die Version zu bekommen. Das Schöne daran ist, können Sie Ihre Wanderungen in der gleichen Quell-Repository als App-Code überprüfen -. Es ist alles an einem Ort

Vielleicht andere können andere Migrations Bibliotheken vor.

Prost.

Edit: Siehe auch https://stackoverflow.com/questions/313/net-migrations-engine und .NET Datenbank-Migrationstool Roundup (von oben post).

Answer 2

http://odetocode.com/Blogs/scott /archive/2008/01/30/11702.aspx

Der obige Blog brachte uns in unserem aktuellen Datenbank Versionskontrollsystem. Einfach ausgedrückt, werden ohne Update-Skript keine DB Änderungen vorgenommen und alle Update-Skripte sind in unserem Quellcodeverwaltungsrepository.

Wir haben leider nur Schemaänderungen verwalten Sie können jedoch auch in der Lage / bereit sein Dumps Ihrer Daten in der Versionskontrolle zu prüfen, wie gut halten; solche Dateien zu erstellen ist eine ziemlich triviale Übung mit mysqldump.

Unsere Lösung unterscheidet sich von der Lösung in dem Blog in einer Schlüssel Weise dargestellt: es ist nicht automatisiert. Wir müssen Hand-Datenbank-Updates anwenden usw. Obwohl diese raubend etwas Zeit sein kann, ist es ein Teil der Bemühungen verschoben ein vollautomatisches System erforderlich wäre. Eine Sache, die wir aber haben automatisieren, war die db-Version in der Tracking-Software. Das war ziemlich einfach und es ist sichergestellt, dass unsere Software kennt die Datenbank gegen sie läuft und läuft nur, wenn es das Schema weiß mit es funktioniert

Der schwierigste Teil unserer Lösung war wie Updates von unseren Niederlassungen in unser Stamm zusammenführen. Wir verbrachten einige Zeit einen Workflow zu entwickeln, um die Möglichkeit von zwei Entwicklern zu adressieren versuchen Zweige mit DB-Updates zur gleichen Zeit verschmelzen und wie sie damit umgehen. Wir entschieden uns schließlich auf eine Datei in der Versionskontrolle Verriegelung (die betreffende Datei für uns tatsächlich eine Tabelle Mapping-Software-Version ist Version db, die in unserem Handbuch Management-Strategie unterstützt), wie viel würden Sie einen kritischen Abschnitt des Threads, und der Entwickler, bekommt die Sperre geht über ihre Aktualisierung des Rumpfes. Wenn der Vorgang abgeschlossen, würde der andere Entwickler in der Lage sein, zu sperren und es ist ihre Verantwortung aller Änderungen notwendig, um ihre Skripte zu machen, um sicherzustellen, dass erwartete Version Kollisionen und andere schlechte Juju vermieden werden.

Answer 3

Wir halten alle unsere Datenbank-Skripte (Daten-und schema-ddl) in version control.Wir halten auch einen zentralen Katalog, der änderungen.Wenn ein Entwickler eine änderung vornimmt, um ein schema/DDL-Datei oder fügt ein Skript, das änderungen die Daten in irgendeiner Weise, werden diese Dateien in den Katalog aufgenommen, zusammen mit der SVN-commit-Nummer.

Wir haben zusammen ein kleines utility, in-house, der liest den Katalog ändert sich und baut ein großes update-Skript, basierend auf dem Inhalt des Katalogs, indem Sie den Inhalt von jeder revision im Katalog und wendet Sie an.Das Konzept ist ziemlich ähnlich wie die DBDeploy Werkzeug, das glaube ich ursprünglich aus der Thoughtworks,, so dass Sie möglicherweise in der Lage sein, es zu nutzen.Es wird zumindest geben Ihnen eine gute Ort, um zu beginnen, von dem Punkt, den Sie anpassen können, eine Lösung, die direkt auf Ihre Bedürfnisse.

Viel Glück!