Konfigurowanie kontroli źródła i zarządzanie danymi referencyjnymi

Projekt bazy danych SQL bez kontroli źródła to tylko folder plików na maszynie innej osoby. W momencie, gdy zepsuje się laptop tej osoby lub gdy dwóch deweloperów edytuje tę samą procedurę składowaną, wracasz do punktu wyjścia. Umieszczenie projektu w Git zapewnia historię zmian, współpracę poprzez rozgałęzianie i żądania ściągnięcia oraz podstawy każdego potoku ciągłej integracji/ciągłego wdrażania.

Ale sama kontrola źródła nie rozwiązuje wszystkiego. Baza danych prawdopodobnie zawiera tabele odnośników, kody stanu i domyślne konfiguracje, które działają obok schematu. Potrzebujesz również strategii dla tych danych.

Konfigurowanie kontroli źródła dla projektu bazy danych SQL

Ponieważ projekt bazy danych SQL to tylko .sql pliki i .sqlproj plik, pasuje naturalnie do usługi Git. Każdy obiekt bazy danych znajduje się we własnym pliku, więc usługa Git śledzi zmiany na poziomie obiektu. Zatwierdzenie, które modyfikuje tabelę Customers i aktualizuje procedurę składowaną, pokazuje dokładnie te dwa pliki w różnicy, a nie monolityczny skrypt migracji z dziesiątkami niepowiązanych zmian.

Aby rozpocząć, zainicjuj repozytorium Git w folderze projektu:

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

Organizowanie folderu projektu

Spójna struktura folderów sprawia, że projekt jest nawigowalny w skrócie. Najczęściej spotykane pliki wzorców grupuje według typu obiektu:

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

W przypadku projektów w stylu zestawu SDK domyślny wzorzec globbing automatycznie pobiera każdy .sql plik w folderze. Nie są potrzebne żadne ręczne wpisy do pliku.

Dodaj plik .gitignore

Zachowaj repozytorium skoncentrowane na plikach źródłowych, wykluczając dane wyjściowe kompilacji i ustawienia specyficzne dla użytkownika:

bin/
obj/
*.dacpac
*.user

Element .dacpac jest odtwarzany z projektu przy każdym budowaniu CI/CD, więc nie ma powodu, aby śledzić go w Git.

Zarządzanie danymi referencyjnymi za pomocą skryptów przed wdrożeniem i po wdrożeniu

Model deklaratywny obsługuje obiekty schematu, takie jak tabele, widoki i procedury składowane, ale niektóre dane są tak istotne, jak sam schemat. Kody stanu, tabele odnośników, konfiguracje domyślne, listy regionów. Jeśli te dane znikną, aplikacja przestanie działać. Należy on do projektu, wersjonowany wraz z obiektami, które od niego zależą.

Wdrożenie wstępne i skrypty po wdrożeniu rozwiążą ten problem. Są to skrypty SQL wykonywane podczas wdrażania, ale znajdują się poza skompilowanym modelem bazy danych:

• Skrypt przed wdrożeniem jest uruchamiany przed planem wdrożenia. Służy do wykonywania zadań, które muszą zostać wykonane przed zmianami schematu, takich jak porzucanie ograniczeń lub migrowanie danych.
• Skrypt po wdrożeniu jest uruchamiany po zakończeniu planu wdrożenia. Służy do wypełniania danych referencyjnych, tabel wyszukiwania lub ustawiania domyślnych wartości aplikacji.

Dodawanie skryptów do projektu

Projekt obsługuje dokładnie jeden skrypt wdrażania wstępnego i jeden skrypt po wdrożeniu. Zadeklarujesz je w pliku .sqlproj z wpisami elementów: PreDeploy, PostDeploy.

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

Używanie funkcji SQLCMD obejmuje wiele plików danych

Jeden plik skryptu nie oznacza jednego gigantycznego pliku. Użyj składni SQLCMD :r , aby ściągnąć wiele plików z jednego punktu wejścia. Typowy wygląd PostDeploy.sql wygląda następująco:

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

Każdy przywołyny plik musi zostać wykluczony z kompilacji. W przeciwnym razie proces kompilacji próbuje skompilować go jako obiekt schematu i zakończy się niepowodzeniem. .sqlproj W pliku użyj Build Remove, aby zapobiec kompilacji i None Include zachować plik widoczny w projekcie.

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

📝 Powtórz ten wzorzec dla każdego pliku, do którego się odnosisz w skryptach przedwdrożeniowych lub powdrożeniowych.

Pisanie idempotentnych skryptów danych referencyjnych

Skrypty po wdrożeniu są uruchamiane w każdym wdrożeniu, a nie tylko przy pierwszym. Jeśli używasz zwykłych INSERT instrukcji, drugie wdrożenie zakończy się niepowodzeniem z powodu zduplikowanych naruszeń klucza. Zamiast tego użyj MERGE instrukcji , aby skrypty były bezpieczne do wielokrotnego uruchamiania:

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]);

Kluczowe wnioski

Zainicjuj repozytorium Git na poziomie rozwiązania i użyj pliku .gitignore, aby wykluczyć dane wyjściowe kompilacji, takie jak bin/, obj/ i .dacpac. Organizuj obiekty schematu w foldery, które dublują strukturę bazy danych, z jednym plikiem na obiekt. Umieść dane referencyjne w skryptach po wdrożeniu i użyj funkcji SQLCMD :r , aby zachować każdy skrypt skoncentrowany na jednej tabeli. Aby zapobiec kompilowaniu skryptów danych jako obiektów schematu, użyj polecenia Build Remove i None Include w .sqlproj pliku . Pisz MERGE instrukcje zamiast zwykłych INSERT instrukcji, dzięki czemu skrypty danych referencyjnych są idempotentne i bezpieczne do uruchamiania w każdym wdrożeniu. Następnie zacznij korzystać z tego repozytorium z rozgałęzianiem i przepływami żądań pull.