Ich habe meinen ursprünglichen Beitrag unten aktualisiert, um Änderungen in den neuesten Versionen von SQL Source Control (3.0) und SQL Compare (10.1) widerzuspiegeln.
Da diese Frage vor über einem Jahr gestellt wurde, ist meine Antwort für Sie vielleicht nicht so hilfreich, aber für andere, die derzeit SSC evaluieren, dachte ich, ich würde meinen Senf dazu geben. Wir haben gerade angefangen, SQL Source Control (SSC) zu verwenden, und insgesamt bin ich damit bisher ziemlich zufrieden. Es hat jedoch einige Macken, insbesondere wenn Sie in einer Umgebung mit gemeinsam genutzten Datenbanken arbeiten (im Gegensatz zu jedem Entwickler, der lokal arbeitet) und insbesondere in einer Legacy-Umgebung, in der Objekte in derselben Datenbank willkürlich zwischen Entwicklungsteams aufgeteilt werden.
Um einen kurzen Überblick darüber zu geben, wie wir das Produkt in unserer Organisation verwenden, arbeiten wir in einer gemeinsam genutzten Umgebung, in der wir alle Änderungen an derselben Entwicklungsdatenbank vornehmen, also haben wir die gemeinsam genutzte Datenbank an das Quellcodeverwaltungs-Repository angehängt. Jeder Entwickler ist dafür verantwortlich, Änderungen an den Objekten in der Datenbank über SQL Server Management Studio (SSMS) vorzunehmen, und wenn er fertig ist, kann er seine Änderungen an die Quellcodeverwaltung übertragen. Wenn wir bereit sind, Staging bereitzustellen, führt der Build-Master (ich) den Entwicklungszweig des Datenbankcodes mit dem Hauptzweig (Staging) zusammen und führt dann SQL Compare unter Verwendung der Hauptzweig-Repository-Version der Datenbank als Quelle und Live aus Staging-Datenbank als Ziel, und SQL Compare generiert die erforderlichen Skripts, um die an der Staging-Umgebung vorgenommenen Änderungen bereitzustellen. Das Staging für Produktionsbereitstellungen funktioniert auf ähnliche Weise. Ein weiterer wichtiger Punkt ist, dass wir angesichts der Tatsache, dass wir dieselbe Datenbank mit anderen Entwicklungsteams teilen, eine eingebaute Funktion von SSC verwenden, mit der Sie Filter für Datenbankobjekte nach Name, Typ usw. erstellen können. Wir manuell Richten Sie Filter für die Objekte unseres spezifischen Teams ein und schließen Sie alle anderen Objekte aus, damit wir nicht versehentlich die Änderungen anderer Entwicklungsteams festschreiben, wenn wir unsere Bereitstellungen durchführen.
Im Allgemeinen ist es also ein ziemlich einfach einzurichtendes und zu verwendendes Produkt, und es ist wirklich nett, weil Sie immer mit Live-Objekten in SSMS arbeiten, im Gegensatz zu getrennten Skriptdateien, die in einem separaten Quell-Repository gespeichert sind und das Risiko eingehen, dass sie nicht mehr synchron sind . Es ist auch schön, weil SQL Compare die Bereitstellungsskripts für Sie generiert, sodass Sie sich keine Gedanken über das Einführen von Fehlern machen müssen, wie Sie es tun würden, wenn Sie die Skripts selbst erstellen würden. Und da SQL Compare ein sehr ausgereiftes und stabiles Produkt ist, können Sie ziemlich sicher sein, dass es die richtigen Skripte für Sie erstellen wird.
Abgesehen davon, hier sind einige der Macken, auf die ich bisher gestoßen bin:
- SSC ist ziemlich geschwätzig in Bezug auf die Kommunikation mit dem DB-Server, um Datenbankelemente zu verfolgen, die nicht mit dem Quellcodeverwaltungs-Repository synchronisiert sind. Es fragt alle paar Millisekunden ab, und wenn Sie mehrere Entwickler hinzufügen, die alle mit SSC an derselben Datenbank arbeiten, können Sie sich vorstellen, dass unsere Datenbankadministratoren nicht sehr zufrieden waren. Glücklicherweise können Sie Ihre Abfragehäufigkeit leicht auf einen akzeptableren Wert reduzieren, allerdings auf Kosten ansprechender visueller Benachrichtigungen, wenn Objekte geändert wurden.
- Mit der Objektfilterfunktion können Sie anhand der Objekte in SSMS nicht ohne weiteres erkennen, welche Objekte in Ihrem Filter enthalten sind. Sie wissen also nicht genau, ob ein Objekt unter Quellcodeverwaltung steht, anders als in Visual Studio, wo Symbole verwendet werden, um quellcodegesteuerte Objekte anzuzeigen.
- Die Objektfilter-GUI ist sehr klobig. Aufgrund der Tatsache, dass wir in einer veralteten Datenbankumgebung arbeiten, gibt es derzeit keine klare Trennung zwischen den Objekten, die unserem Team gehören, und denen anderer Teams, um zu verhindern, dass wir versehentlich die Änderungen anderer Teams festschreiben/bereitstellen haben wir ein Filterschema eingerichtet, um jedes spezifische Objekt, das wir besitzen, explizit einzuschließen. Wie Sie sich vorstellen können, wird dies ziemlich umständlich, und da die GUI zum Bearbeiten der Filter so eingerichtet ist, dass jeweils ein Objekt eingegeben wird, kann es ziemlich schmerzhaft werden, insbesondere wenn Sie versuchen, Ihre Umgebung zum ersten Mal einzurichten (ich endete damit Bewerbung schreiben). In Zukunft erstellen wir ein neues Schema für unsere Anwendung, um das Filtern von Objekten besser zu vereinfachen (abgesehen davon, dass es sowieso eine bessere Vorgehensweise ist).
- Unter Verwendung des gemeinsam genutzten Datenbankmodells ist es Entwicklern gestattet, alle anstehenden Änderungen an einer quellengesteuerten Datenbank festzuschreiben, selbst wenn die Änderungen nicht ihre eigenen sind. SSC warnt Sie, wenn Sie versuchen, eine Reihe von Änderungen einzuchecken, dass diese Änderungen möglicherweise nicht von Ihnen stammen, aber ansonsten sind Sie auf sich allein gestellt. Ich finde das tatsächlich eine der gefährlichsten „Macken“ von SSC.
- SQL Compare kann derzeit die von SSC erstellten Objektfilter nicht gemeinsam nutzen, daher müssten Sie manuell einen passenden Filter in SQL Compare erstellen, sodass die Gefahr besteht, dass diese nicht mehr synchron sind. Am Ende habe ich die Filter aus der zugrunde liegenden SSC-Filterdatei einfach ausgeschnitten und in den SQL-Compare-Projektfilter eingefügt, um den Umgang mit der klobigen Objektfilter-GUI zu vermeiden. Ich glaube, dass die nächste Version von SQL Compare es ermöglichen wird, Filter mit SSC zu teilen, also ist dieses Problem zumindest nur ein kurzfristiges. (HINWEIS:Dieses Problem wurde in der neuesten Version von SQL Compare behoben. SQL Compare kann jetzt die von SSC erstellten Objektfilter verwenden.)
- SQL Compare kann auch nicht mit einem SSC-Datenbank-Repository verglichen werden, wenn es direkt gestartet wird. Es muss innerhalb von SSMS gestartet werden. Ich glaube, dass die nächste Version von SQL Compare diese Funktionalität bieten wird, also ist es wieder ein weiteres kurzfristiges Problem. (HINWEIS:Dieses Problem wurde in der neuesten Version von SQL Compare behoben.)
- Manchmal ist SQL Compare nicht in der Lage, die richtigen Skripte zu erstellen, um die Zieldatenbank von einem Zustand in einen anderen zu bringen, normalerweise, wenn Sie das Schema vorhandener Tabellen aktualisieren, die nicht leer sind, also müssen Sie das derzeit tun manuelle Skripte schreiben und den Prozess selbst verwalten. Glücklicherweise wird dies durch „Migrationsskripte“ in der nächsten Version von SSC angegangen, und wenn man sich die frühe Version des Produkts ansieht, scheint es, dass die Implementierung dieser neuen Funktion gut durchdacht und entworfen wurde. (HINWEIS:Die Funktionalität von Migrationsskripten wurde offiziell veröffentlicht. Verzweigungen werden derzeit jedoch nicht unterstützt. Wenn Sie Migrationsskripts verwenden möchten, müssen Sie sql Compare mit Ihrem ursprünglichen Entwicklungscode-Zweig ausführen ... dem, in dem Sie haben Ihre Änderungen eingecheckt ... was ziemlich umständlich ist und mich dazu gezwungen hat, meinen Build-Prozess auf eine weniger als ideale Weise zu ändern, um diese Einschränkung zu umgehen. Hoffentlich wird dies in einer zukünftigen Version behoben.)
Insgesamt bin ich ziemlich zufrieden mit dem Produkt und mit der Reaktionsfähigkeit von Redgate auf Benutzerfeedback und der Richtung, die das Produkt einschlägt. Das Produkt ist sehr einfach zu verwenden und gut gestaltet, und ich denke, dass uns das Produkt in den nächsten ein oder zwei Versionen wahrscheinlich das meiste, wenn nicht alles, von dem geben wird, was wir brauchen.
