Implementowanie ciągłej integracji/ciągłego wdrażania dla usługi Azure SQL Database

Ukończone

Teraz wiesz, jak wdrażać, konfigurować i używać usługi Azure SQL Database do tworzenia silnej podstawy dla nowoczesnej aplikacji. Wymagania aplikacji stale ewoluują i zmieniają się, więc następnym krokiem jest zrozumienie sposobu aktualizowania bazy danych w razie potrzeby. Operacje programowania (DevOps) to zestaw zasad i praktyk, które mogą pomóc.

DevOps to związek ludzi, procesów i technologii, aby stale zapewniać klientom wartość. Zespoły, które wdrażają kulturę, praktyki i narzędzia DevOps, stają się wysoce wydajne, tworząc szybciej lepsze produkty ku większemu zadowoleniu klientów.

Baza danych jest jedną z głównych części rozwiązania; w związku z tym możliwość zintegrowania bazy danych z praktykami DevOps jest kluczowym elementem nowoczesnego i elastycznego tworzenia aplikacji.

W usłudze Azure SQL istnieje kilka podejść do uwzględnienia bazy danych w procesie DevOps. Potok ciągłej integracji i ciągłego dostarczania (CD) jest szkieletem środowiska DevOps, a usługa Azure SQL może być w pełni zintegrowana z dowolnym wybranym narzędziem ciągłej integracji/ciągłego wdrażania. Dwa z najpopularniejszych i powszechnie używanych narzędzi na platformie Azure to GitHub Actions i Azure DevOps.

Implementowanie ciągłej integracji/ciągłego wdrażania dla baz danych

Posiadanie bazy danych w ramach potoku ciągłej integracji/ciągłego wdrażania oznacza, że chcesz skonfigurować i wdrożyć strukturę — a może nawet niektóre dane — w sposób w pełni zautomatyzowany, powtarzalny i deterministyczny. Po skonfigurowaniu można uruchomić proces wdrażania lub aktualizacji w dowolnym momencie, przez dowolną liczbę razy i uzyskać spójne wyniki.

W tej lekcji poznasz trzy główne podejścia do implementowania potoku ciągłej integracji/ciągłego wdrażania dla baz danych:

  • Żądany stan
  • Migracje Code First
  • Skrypty niestandardowe

Używanie podejścia żądanego stanu z SqlPackage.exe

W podejściu żądanego stanu utworzysz migawkę struktury bazy danych referencyjnej, która będzie reprezentować żądany stan. Następnie możesz użyć tej migawki, aby zsynchronizować inną docelową bazę danych, zazwyczaj testową lub produkcyjną bazę danych, do żądanego stanu. Możesz użyć narzędzia, takiego jak SqlPackage.exe , aby utworzyć migawkę .dacpac w pliku. Po zastosowaniu .dacpac elementu do docelowej bazy danych automatycznie znajdzie różnice, wygeneruj prawidłowy skrypt i zastosuj ten skrypt, aby zsynchronizować schemat docelowy z odwołaniem.

W scenariuszu łapania autobusów używamy podejścia żądanego stanu; jest to prawdopodobnie najłatwiejsze i najprostsze z trzech omówionych podejść.

Implementowanie Migracje Code First w zależności od języka

Istnieje inna opcja, jeśli nie chcesz pisać skryptów języka T-SQL; Zamiast tego chcesz zezwolić na automatyczne generowanie bazy danych i schematu w języku C#, Python lub Node oraz jednostek zdefiniowanych w rozwiązaniu (na przykład magistrali, trasy lub lokalizacji). Zazwyczaj istnieje określone narzędzie, które jest dostarczane lub ma zastosowanie do platformy lub platformy. Te narzędzia zapewniają, że za każdym razem, gdy zmienisz lub dodasz pole lub jednostkę, nowa struktura zostanie odzwierciedlona w bazie danych. Na końcu tego modułu można znaleźć odwołania do narzędzi dla określonych platform i struktur.

Używanie skryptów ręcznych na potrzeby wdrożeń krok po kroku

W podejściu ręcznym do obsługi skryptów deweloper starannie pisze i utrzymuje skrypty potrzebne do utworzenia i zmiany bazy danych w czasie. Po wdrożeniu skryptu w środowisku produkcyjnym nigdy nie jest on zmieniany; zamiast tego jest tworzony nowy. Każdy skrypt zawiera kod potrzebny do ewolucji bazy danych do nowego schematu. W przypadkach, gdy baza danych musi zostać wdrożona od podstaw, wszystkie skrypty muszą być wykonywane w odpowiedniej kolejności, aby upewnić się, że baza danych została utworzona i ewoluowała prawidłowo. Po wdrożeniu skryptu możesz użyć narzędzi, takich jak narzędzie Do porównywania schematów w narzędziach SQL Server Data Tools (SSDT), aby porównać definicje baz danych. Pomaga to zagwarantować, że wdrożony skrypt nie zostanie ponownie zastosowany do tej samej bazy danych w kolejnych wykonaniach.

Wybierz narzędzie potoku, aby łatwo zaimplementować ciągłą integrację/ciągłe wdrażanie

Po zidentyfikowaniu podejścia, które najlepiej odnosi się do sposobu aktualizowania bazy danych, możesz wybrać spośród dwóch typowych rozwiązań, Usługi Azure DevOps lub GitHub Actions, aby zaimplementować to podejście.

Implementowanie ciągłej integracji/ciągłego wdrażania za pomocą usługi Azure DevOps

Azure DevOps to pakiet produktów, który zapewnia pełną obsługę wszystkich aspektów metodyki DevOps, w tym potoku ciągłej integracji/ciągłego wdrażania. Potok składa się z zadań, które definiują kroki potoku. Zadanie może być niemal dowolne— od wykonania pliku wykonywalnego po kompilację rozwiązania .NET. W celu wdrożenia .dacpac pliku lub wykonania skryptu .sql można użyć określonego zadania o nazwie Zadanie wdrażania usługi Azure SQL Database.

Implementowanie ciągłej integracji/ciągłego wdrażania za pomocą funkcji GitHub Actions

Funkcja GitHub Actions umożliwia zdefiniowanie potoku ciągłej integracji/ciągłego wdrażania. Akcje służą do tworzenia kroków potoku. Możesz użyć akcji, aby wykonać proces niemal dowolnego typu. Polecenie Action Azure SQL Deploy umożliwia wdrożenie .dacpac pliku.

W następnym ćwiczeniu usługa Azure SQL Actions będzie używana do wdrażania i aktualizowania schematu bazy danych, co daje możliwość wyświetlenia go w działaniu.

Test wiedzy

1.

Które z poniższych podejść nie jest podejściem do ciągłej integracji/ciągłego wdrażania w usłudze Azure SQL Database?

2.

Metodyka DevOps została zdefiniowana jako związek trzech rzeczy. Która z poniższych opcji nie była jedną z nich?