Aktualizacja wersji w projektach bazy danych Visual Studio

Question

Moja firma używa projektu bazy danych Visual Studio do wdrażania aktualizacji do naszej bazy danych. O ile wiem, zapewnia funkcjonalność porównywania stanu schematu projektu i docelowej bazy danych oraz generowania kodu w celu aktualizacji schematu tego ostatniego do poprzedniego. Zapewnia także jeden skrypt przed wdrożeniem i jeden skrypt po wdrożeniu, ale nic więcej.

Brakuje jakiejkolwiek koncepcji wersji i/lub zamówienia. Jeśli chcę, powiedzmy, dodać nieprzepisującą kolumnę FK do tabeli, muszę zrobić to w dwóch krokach - najpierw dodać ją jako kolumnę zerowalną ze skryptem po wdrożeniu, aby zaktualizować wiersze, aby miały znaczące wartości w Po drugie, uczyń kolumnę nie-nullable. Te muszą się zdarzyć w porządku.

O ile mogę powiedzieć, nie ma możliwości zapewnienia tego sekwencyjnego porządkowania skryptów przed i po wdrożeniu przy wdrażaniu projektów bazy danych Visual Studio. Czy jestem tutaj? Ma to 2 konsekwencje: po pierwsze, po prostu nie możesz dodać kolumny nieakceptowalnej FK do tabeli po jej utworzeniu, a po drugie, że twoje skrypty przed i po wdrożeniu będą rosły i rosły cruft sprzed lat, ponieważ są one uruchamiane za każdym razem baza danych jest wdrożona.

Czy istnieje sposób aktualizacji wersji z projektami bazy danych Visual Studio, a jeśli nie, czy istnieje typ projektu, który pozwoliłby na tego typu wersjonowanie?

Answer 1

Przede wszystkim oznaczono to tagiem studia wizualnego 2012 - jeśli używasz tej wersji, upewnij się, że uaktualniasz ją do wersji 2013 lub 2015 i otrzymujesz najnowszą wersję SSDT, ponieważ co 3 miesiące pojawiają się nowe wersje z nowymi funkcjami i poprawkami więc warto jest dostać nowszą wersję - bity, o których mówię poniżej, to aktualne zachowanie, nie wiem, czy to wszystko było dostępne w oryginalnym ssdt w visual studio 2012.

Jest kilka rzeczy do powiedzenia, po pierwsze można wymusić uporządkowane wdrożenia za pomocą opcji/p: BlockWhenDriftDetected w połączeniu z rejestracją bazy danych jako aplikacji warstwy danych (/ p: RegisterDataTierApplication). Pozwoliłoby to, aby to zrobić:

1. Budowa dacpac 1
2. Deploy dacpac 1
3. Budowa dacpac 2
4. Deploy dacpac 2
5. Budowa dacpac 3

To zatrzyma możesz wdrożyć dacpac 2 zanim wdrożyłeś dacpac 1, ale nie jest to idealne rozwiązanie, ponieważ jeśli zbudujesz dacpac 3 przed wdrożeniem dacpac 2, nie będziesz mógł wdrożyć z przebudowuje dacpac 3, więc nie jest idealny.

Kiedy zajmujesz się zmianami w bazie danych (jakikolwiek rdbms nie tylko serwer sql) czasami zdarzają się sytuacje, w których musimy wprowadzać zmiany w fazach i dla mnie jest to bardziej kwestia procesu niż technologia.Co mogę zrobić, to:

1. Utwórz pierwszą część zmian
2. Tworzenie bilet w portfelu sfinalizować zmiana
3. wdrożyć zmianę
4. w kolejnej iteracji po wdrożeniu, podnieś bilet do sfinalizowania zmian
5. Wdrażanie finalizację

Niektóre rzeczy zwrócić uwagę na ten temat:

• Potrzeba dyscypliny, aby upewnić się uporządkować i kompletny materiał, pracuje w błyskotliwy sposób nie oznacza, niechlujny :)
• Wszelkie skrypty piszesz należy idempotent więc jeśli chcesz skonfigurować niektóre dane statyczne etc używać coś takiego, jeśli istnieje czeków lub oświadczenie scalania, jeśli modyfikować żadnych obiektów schematu owinąć je, jeśli istnieje itp Jeśli to zrobisz znajdziesz wdrażania znacznie bardziej proste doświadczenie

Jeśli zastosujemy ten proces, zamiast polegać na typie polityki wersji, nie musisz się martwić kolejnością wdrażania dacpacs, jeśli skrypt jest ważny, pozostaw go w skrypcie po wdrożeniu i sprawdź, czy skrypt powinien wykonać jakąkolwiek pracę przed wykonaniem tego skryptu. Jeśli twoje skrypty są zbyt duże, możesz użyć: r importu sqlcmd, aby rozdzielić je na różne pliki. Słyszałem również o ludziach używających procedur przechowywanych w bazie danych i wywołujących je ze skryptów po wdrożeniu.

Preferuję proces, w którym po prostu wdraża się najnowszą (lub określoną wersję) dacpaca, ponieważ oznacza to, że zawsze można wdrożyć do tej wersji bez względu na to, czy przechodzimy do późniejszej kompilacji, czy też z powrotem do wcześniejszej wersji.

Wreszcie, wraz z przykładem dodawania nieakceptowalnej kolumny fk, można to zrobić z pojedynczym wdrożeniem dacpaca. Aby to zrobić, byś:

1. Utwórz nową definicję tabeli (łącznie niepuste i klucza obcego przymusu)
2. W skrypcie po deploy zrobić aktualizacji na stole tak, że ustawia dane poprawnie (oczywiście czyni go idempotent więc może pozostać na zawsze, jeżeli potrzeby być)
3. podczas wdrażania włączyć/p: GenerateSmartDefaults

Co się dzieje, gdy skrypt rozmieszczenie jest generowany jest dostać skrypt, który wygląda tak:

• Pre-Deploy skrypt (jeśli występują)
• Utwórz kolumnę NOT NULL z tymczasowym domyślne ograniczenie
• Kropla tymczasowe ograniczenie
• Tworzenie klucza obcego z nocheck więc nie jest rzeczywiście enfored
• Run post- wdrożyć skrypt
• Włącz ograniczenie klucza obcego przy użyciu „z check”

/P: Parametry rzeczy ja wielobranżowe jonowane to argumenty przekazywane do programu sqlpackage.exe.jeśli nie używasz tego, ale używasz innej metody wdrażania, możesz normalnie przekazać je jako parametry, jeśli dasz mi znać, w jaki sposób się wdrożysz, jeśli utkniesz i będę mógł ci pomóc. Aby uzyskać opis argumentów zobacz https://msdn.microsoft.com/en-us/library/hh550080.aspx (składnia wiersza poleceń sqlpackage.exe).

Daj mi znać, jeśli masz jakieś pytania, jest jeszcze kilka rzeczy do przemyślenia, ale sprawdzenie definicji schematu i wdrożenie automatycznych skryptów powoduje znaczne zmniejszenie nakładu pracy, co oznacza, że ​​możesz skoncentrować się na czymś bardziej użytecznym. - pisanie testów jednostkowych dla jednego :).

Ed