Versionierung von SQL Server?

Meine ehrliche Antwort ist, dass Sie keine Integration in Ihre Datenbankwerkzeuge und SCM durchführen, wenn Sie dies vermeiden können. Verwenden Sie das Dateisystem wo möglich. Es ist eine andere Ebene der Integration, die ein Schmerz sein wird. Kleine separate Werkzeuge sind besser als ein Ungetüm.

Wir verwenden Subversion und SQL 2005 zusammen in folgendem Manor:

• Wir verwenden nur TortoiseSVN. Keine VS / SSMS-Integration überhaupt.
• Wir haben den Grundsatz "alles automatisieren", also verlassen wir uns nie auf GUI-Tools, um zu arbeiten.
• Wir behalten alle Skripte in SVN zusammen mit dem Code. Der Code, das Schema und die Skripte werden zusammen versioniert.
• Schemaänderungen werden in der Reihenfolge der Anwendung nummeriert, d. h. 000-create-table-users.sql. Wir notieren die maximale Skriptnummer, die in jeder Umgebung bereitgestellt wird. Jedes Skript führt eine Migration zur nächsten Datenbank-R-Nummer durch. Bei der Bereitstellung prüfen wir die Quelle und führen alle Skripts von der letzten Versionsnummer bis zur höchsten Nummer aus.
• Alle Nicht-Schema-Skripte (Sprocs / Views) sind idempotent (können beliebig oft mit dem gleichen Ergebnis ausgeführt werden). Sie werden über ein von uns geschriebenes Plugin angewendet. Diese werden bei jeder Bereitstellung ersetzt. Vergessen Sie nicht, Ihre Ansichten zu aktualisieren!
• Wir vermeiden sowieso irgendwelche Skripte, da wir NHibernate verwenden, so dass es sowieso weniger Probleme mit der Skript-Versionierung gibt.

Von dieser Struktur aus können wir die Umgebung und die Datenbank zu jedem beliebigen Zeitpunkt auf jeder Maschine neu erstellen, was wichtig ist.

Wir verwenden es jedoch NICHT für Komponententests - wir verwenden die NHibernate-Schemagenerierung, um dies zusätzlich zu einer SQLite-Datenbank durchzuführen.

Der einzige negative Punkt, auf den wir gestoßen sind, besteht darin, sicherzustellen, dass die Entwickler den Prozess einhalten. Herding Katzen ist eine sehr geeignete Beschreibung.

Visual Studio Team System 2008 Datenbank Edition (Codename "DataDude") ist, was Sie brauchen.

Es ermöglicht Ihnen, Ihre Datenbankobjekte auf eine Weise zu versionieren, die Sie umhauen wird. (z. B. Upgrade eines Kundenstandorts auf eine bestimmte Version oder Rollback auf eine vorherige Version, ohne Daten zu zerstören).

Sehen Sie sich die Funktionen im Blog von Gert Drapers an, beginnend mit dieser Beitrag .

Oder wenn Sie einen Podcast bevorzugen, hören Sie DotNetRocks mit Chris Sells in der Show 494 .

Ich weiß nicht, ob Sie bei der Verwendung von DataDude auf TFS für die Quellcodeverwaltung beschränkt sind - aber es ist das unverdientermaßen "unterhypte" Mitglied der Visual Studio-Familie.

Dies könnte ein nützliches Werkzeug für Sie sein: Ссылка

Es ist so konzipiert, dass es die Versionskontrolle in jedem System einfach macht und Ihre Upgrade-Skripts auf vernünftige Weise verwaltet.

Git und Mercurial sind die einzigen, die Sie IMHO in Betracht ziehen sollten, die anderen 2 sind zu altmodisch. Moderne SCMs sollten Zweige behandeln wie Git.

Für Vergleiche zwischen Git und Quecksilber siehe: Ссылка , Ссылка .

Ich habe zwar keine Erfahrung mit SSMS-SCM-Integration, aber AFAIK hat keines der genannten Systeme (außer TFS). Ich würde es nicht als Benachteiligung bezeichnen, zum Beispiel ist GUI ein ziemlich praktisches Werkzeug, das Ihnen mehr Spaß macht als solch eine Integration. Dies ist zumindest mein Fall, wenn ich von SVN (mit VS-Integration mit Ankh) nach Git (ohne Integration) gehe ...

Mercurial hat VS-Integration mit VisualHG , wenn Sie denken, dass DVCS der richtige Weg ist. Wir verwenden das für C ++ / C # -Projekte in unserem Shop und es funktioniert gut genug. (OTOH, ich habe noch nie eine "vollständige" Integration verwendet, daher arbeite ich gerne mit der Explorer-Erweiterung und / oder der Befehlszeile für detaillierte VC-Arbeit.)

Wir haben jetzt die VSS-Unterstützung für die SQL-Quellcodeverwaltung hinzugefügt, die in SSMS integriert ist und eine vollständig integrierte Quellcodeverwaltung für die Datenbankentwicklung bietet. Um dies auszuprobieren, besuchen Sie bitte: Ссылка

In TFS fehlen einige Funktionen von VSS, insbesondere die Keyword-Erweiterung. Wenn Sie die Informationen zu Revisionsschlüsselwörtern nicht in Ihre Quelldateien einbetten, sollte dies kein Problem darstellen.

Es gibt möglicherweise eine ganze Reihe von Alternativen - SQL Server Management Studio (SSMS) unterstützt die Integration mit jeder Microsoft-Quellcodeverwaltungsschnittstelle MSSCCI Anbieter. So können Sie die Suche auf Quellcodeverwaltungssysteme ausweiten, die einen MSSCCI-kompatiblen Anbieter aufweisen.

In SSMS, Check out Tools - & gt; Optionen - & gt; Source Control, um zu sehen, welche Provider Plug-Ins auf Ihrem System installiert sind.

Zum Beispiel ist die Integration von Team Foundation Server in SQL Management Studio mit dem TFS MSSCCI Provider möglich. Ich denke, es gibt einen Anbieter für CVS / Subversion ("Aigenta Unified SCC") und so weiter.

Was eine Pro / Contra-Liste angeht, denke ich, vorausgesetzt, es gibt einen kompatiblen Anbieter, können Sie die Frage einem größeren Publikum zugänglich machen. Meine hauptsächliche Erfahrung ist mit VSS, TFS und Subversion. Es kommt wirklich auf dein Team und deine Umgebung an. Können Sie mehr über Ihre Umgebung erfahren?

z.

• wären Sie daran interessiert, CI (kontinuierliche Integration) zu etablieren?
• automatisierte Builds / automatisierte Versionierung?
• Unterstützung für mehrere Umgebungen?
• Konfigurationsmanagement?
• Welche Teamgröße hast du? wahrscheinlich viele Zusammenführungen / Verzweigungen usw.?
• Haben Sie bereits ein Fehlerverfolgungssystem installiert (Sie erhalten Arbeitsaufgaben / Fehlerverfolgung als Teil eines TFS-Rollouts)?