Konfigurieren der Quellcodeverwaltung und Verwalten von Referenzdaten

Abgeschlossen

Ein SQL-Datenbankprojekt ohne Quellcodeverwaltung ist nur ein Ordner mit Dateien auf dem Computer einer Person. Sobald der Laptop der Person kaputtgeht oder zwei Entwickler dieselbe gespeicherte Prozedur ändern, fangen Sie wieder von vorne an. Wenn Sie das Projekt in Git einfügen, erhalten Sie den Änderungsverlauf, die Zusammenarbeit durch Verzweigungen und Pull-Anfragen sowie die Grundlage für jede CI/CD-Pipeline.

Die Quellcodeverwaltung allein löst jedoch nicht alles. Ihre Datenbank verfügt wahrscheinlich über Nachschlagetabellen, Statuscodes und Standardkonfigurationen, die zusammen mit dem Schema vorhanden sind. Sie benötigen auch eine Strategie für diese Daten.

Einrichten der Quellcodeverwaltung für ein SQL-Datenbankprojekt

Da ein SQL-Datenbankprojekt nur .sql Dateien und eine .sqlproj Datei ist, passt es natürlich zu Git. Jedes Datenbankobjekt befindet sich in einer eigenen Datei, sodass Git Änderungen auf Objektebene nachverfolgt. Ein Commit, der die Customers Tabelle ändert und eine gespeicherte Prozedur aktualisiert, zeigt genau diese beiden Dateien im Diff, nicht ein monolithisches Migrationsskript mit Dutzenden von nicht verknüpften Änderungen.

Initialisieren Sie zunächst ein Git-Repository im Projektordner:

cd MyDatabaseProject
git init
git add .
git commit -m "Initial commit of database project"

Organisieren des Projektordners

Eine konsistente Ordnerstruktur macht das Projekt auf einen Blick navigierbar. Die gängigsten Mustergruppendateien nach Objekttyp:

MyDatabaseProject/
├── MyDatabaseProject.sqlproj
├── Tables/
│   ├── Customers.sql
│   └── Orders.sql
├── Views/
│   └── vw_ActiveCustomers.sql
├── StoredProcedures/
│   └── usp_GetCustomerOrders.sql
├── Scripts/
│   ├── PostDeployment/
│   │   └── seed-data.sql
│   └── PreDeployment/
│       └── prep-db.sql
└── PostDeploy.sql

Bei SDK-Projekten ruft das Standardglobbingmuster automatisch jede .sql-Datei im Ordner ab. Es sind keine manuellen Dateieinträge erforderlich.

Hinzufügen einer Gitignore-Datei

Halten Sie das Repository auf Quelldateien fokussiert, indem Sie Buildausgaben und benutzerspezifische Einstellungen ausschließen:

bin/
obj/
*.dacpac
*.user

Das .dacpac wird bei jedem CI/CD-Build aus dem Projekt neu erstellt, daher gibt es keinen Grund, es in Git nachzuverfolgen.

Verwaltung von Referenzdaten mit Skripten vor und nach der Bereitstellung.

Das deklarative Modell behandelt Schemaobjekte wie Tabellen, Ansichten und gespeicherte Prozeduren, aber einige Daten sind ebenso wichtig wie das Schema selbst. Statuscodes, Nachschlagetabellen, Standardkonfigurationen, Regionslisten. Wenn diese Daten verschwinden, bricht die Anwendung zusammen. Es gehört zum Projekt und wird zusammen mit den Objekten, die davon abhängig sind, versioniert.

Skripts für den Einsatz und Skripts nach der Bereitstellung lösen dieses Problem. Sie sind SQL-Skripts, die während der Bereitstellung ausgeführt werden, sich aber außerhalb des kompilierten Datenbankmodells befinden:

• Ein Voreinsatzskript wird vor dem Bereitstellungsplan ausgeführt. Verwenden Sie sie für Aufgaben, die vor Schemaänderungen abgeschlossen werden müssen, z. B. das Ablegen von Einschränkungen oder das Migrieren von Daten.
• Nach Abschluss des Bereitstellungsplans wird ein nachbereitendes Skript ausgeführt. Verwenden Sie diese Option, um Referenzdaten, Seed-Nachschlagetabellen aufzufüllen oder Anwendungsstandardwerte festzulegen.

Hinzufügen von Skripts zum Projekt

Ein Projekt unterstützt genau ein Skript vor der Bereitstellung und ein Skript nach der Bereitstellung. Sie deklarieren sie in der .sqlproj Datei mit PreDeploy und PostDeploy Elementeinträgen:

<ItemGroup>
    <PreDeploy Include="prep-db.sql" />
</ItemGroup>
<ItemGroup>
    <PostDeploy Include="PostDeploy.sql" />
</ItemGroup>

Verwenden von SQLCMD-Einschlüssen für mehrere Datendateien

Eine Skriptdatei bedeutet nicht eine riesige Datei. Verwenden Sie die SQLCMD-Syntax :r , um mehrere Dateien von einem einzelnen Einstiegspunkt abzurufen. Ein typisches PostDeploy.sql sieht so aus:

:r .\Scripts\PostDeployment\seed-statuses.sql
:r .\Scripts\PostDeployment\seed-regions.sql
:r .\Scripts\PostDeployment\seed-app-settings.sql

Jede referenzierte Datei muss vom Build ausgeschlossen werden, andernfalls versucht der Buildprozess, sie als Schemaobjekt zu kompilieren und fehlschlägt. Verwenden Sie .sqlproj in der Build Remove Datei, um die Kompilierung zu verhindern und None Include die Datei im Projekt sichtbar zu halten:

<ItemGroup>
    <Build Remove="Scripts\PostDeployment\seed-statuses.sql" />
    <None Include="Scripts\PostDeployment\seed-statuses.sql" />
</ItemGroup>

📝 Wiederholen Sie dieses Muster für jede referenzierte Datei in Ihren Skripts vor der Bereitstellung oder nach der Bereitstellung.

Idempotente Referenzdatenskripte schreiben

Nach der Bereitstellung werden Skripte bei jeder Bereitstellung ausgeführt, nicht nur bei der ersten. Wenn Sie einfache INSERT-Anweisungen verwenden, schlägt die zweite Bereitstellung aufgrund duplizierter Schlüssel fehl. Verwenden Sie MERGE stattdessen Anweisungen, um die Skripts so sicher zu machen, dass sie wiederholt ausgeführt werden:

MERGE INTO [dbo].[OrderStatuses] AS target
USING (VALUES
    (1, N'Pending'),
    (2, N'Processing'),
    (3, N'Shipped'),
    (4, N'Delivered'),
    (5, N'Cancelled')
) AS source ([StatusID], [StatusName])
ON target.[StatusID] = source.[StatusID]
WHEN MATCHED THEN
    UPDATE SET [StatusName] = source.[StatusName]
WHEN NOT MATCHED THEN
    INSERT ([StatusID], [StatusName])
    VALUES (source.[StatusID], source.[StatusName]);

Tipp

Sie können die Skripts vor und nach der Bereitstellung nach dem Erstellen eines Projekts validieren, indem Sie die Dateierweiterung von .dacpac zu .zip ändern und extrahieren. Eine einzelne .sql Datei für jeden Skripttyp enthält den kombinierten T-SQL-Inhalt aus allen referenzierten Dateien.

Wichtige Erkenntnisse

Initialisieren Sie ein Git-Repository auf Lösungsebene, und verwenden Sie eine .gitignore Datei, um Buildausgaben wie bin/, obj/und .dacpac Dateien auszuschließen. Organisieren Sie Schemaobjekte in Ordnern, die die Datenbankstruktur spiegeln, mit einer Datei pro Objekt. Platzieren Sie Referenzdaten in Post-Deployment-Skripts und verwenden Sie SQLCMD-Einschlüsse :r, um jedes Skript auf eine einzelne Tabelle zu fokussieren. Um zu verhindern, dass Datenskripte als Schemaobjekte kompiliert werden, verwenden Sie Build Remove und None Include in der .sqlproj Datei. Schreiben Sie MERGE-Anweisungen anstelle von einfachen INSERT-Anweisungen, damit Referenzdatenskripte idempotent und bei jedem Deployment sicher ausführbar sind. Als Nächstes verwenden Sie dieses Repository für Verzweigungs- und Pull-Request-Workflows.