Procedury przechowywane pod kontrolą źródła, najlepsza praktyka

Obecnie używam Tortoise SVN do kontroli źródła aplikacji sieci Web .NET. Jaki byłby najlepszy sposób na wprowadzenie naszych procedur przechowywanych SQL Server do kontroli źródła? Obecnie używam VS 2010 jako mojego środowiska programistycznego i łączę się z lokalną bazą danych SQL Server 2008 R2 za pomocą narzędzi SQL Server Data Tools (SSDT).

W przeszłości robiłem zapisywanie procs do pliku .sql i utrzymywanie tych plików pod kontrolą źródła. Jestem pewien, że musi istnieć bardziej wydajny sposób niż ten? Czy istnieje rozszerzenie, które mogę zainstalować na VS2010, SSDT, a nawet SQL Server na komputerze produkcyjnym?

Istnieją narzędzia, takie jak ten z Redgate , ale zawsze uważałem, że najlepiej jest zapisywać jako pliki SQL, być może nawet w projekcie bazy danych (SSDT?) W twoim rozwiązaniu.

Oprócz tego sugeruję następujące wytyczne:

• Zawsze zakładaj wersję SVN jako „bieżącą” / „najnowszą”
• Upewnij się, że każdy uruchamiany skrypt ma odpowiedni „ if exists then drop” na początku
• Pamiętaj o skrypcie swoich uprawnień, jeśli takie istnieją

Możesz początkowo utworzyć te pliki SQL, wykonując skrypty bezpośrednio z SSMS, i możesz ustawić, aby SSMS zapisywał wszystkie twoje „ drop” i „ create” oraz twoje uprawnienia.

Zapisanie plików SQL w kontroli źródła zapewnia kontrolę tylko nad plikami SQL. Nie kontroluje zmian rzeczywistych obiektów bazy danych, ani nie zapobiega jednoczesnym zmianom tego samego obiektu bazy danych przez wielu użytkowników (i myślę, że też chcielibyście mieć to pod kontrolą). To, czego używamy, to narzędzie innej firmy ( wersja ApexSQL), integruje się zarówno z SSMS, jak i VS, możesz wybrać, czy chcesz pracować z wersją bazy danych obiektu, czy z wersją kontroli źródła. Jeśli edytujesz wersję bazy danych, jest ona automatycznie sprawdzana tylko dla Ciebie, więc nikt inny nie może jej edytować (nie scala zmian od różnych użytkowników). Tylko po ponownym zameldowaniu inni mogą to zmienić. I możesz mieć swoją wersję SC inną niż wersja obiektu na żywo (używam tego, kiedy wychodzę na ten dzień i planuję zakończyć edycję i przetestować go na następnym)

Użyj Kontroli źródła RedGate, aby podłączyć ją do kontroli źródła.

http://www.red-gate.com/products/sql-development/sql-source-control/

Połączy SSMS bezpośrednio z repozytorium kontroli źródła, a nawet pozwoli na sprawdzenie danych statycznych.

Działa jak marzenie

Wypróbuj Ankhsvn , wysoce zalecane i bezpłatne.

Ze strony głównej:

AnkhSVN jest dostawcą kontroli źródeł Subversion dla Microsoft Visual Studio 2005, 2008, 2010 i 2012 .

AnkhSVN zapewnia obsługę zarządzania kodami źródłowymi Apache ™ Subversion® dla wszystkich typów projektów obsługiwanych przez Visual Studio i umożliwia wykonywanie najbardziej typowych operacji kontroli wersji bezpośrednio z poziomu Microsoft Visual Studio IDE.

Pulpit nawigacyjny Oczekujące zmiany zapewnia unikalny wgląd w proces programowania i zapewnia łatwy dostęp do kodu źródłowego i funkcji zarządzania problemami. Integracja głębokiej kontroli kodu źródłowego (SCC) pozwala skupić się na rozwoju, podczas gdy AnkhSVN śledzi wszystkie zmiany i zapewnia narzędzia do skutecznego radzenia sobie z konkretnymi potrzebami.

Próbowałem zarówno projektu bazy danych RedGate, jak i Visual Studio i wolę przechowywać definicję bazy danych w projekcie bazy danych. Gdy tylko baza danych stanie się częścią rozwiązania, możesz skorzystać z preferowanego dostawcy kontroli źródła. Większość z nich ma doskonałą integrację z Visual Studio.

Dzięki narzędziom SSDT masz „ostatnią wersję” definicji bazy danych, co pozwala na łatwe porównywanie schematów i generowanie skryptów aktualizujących schematy.

To powiedziawszy, schemat jest zwykle tylko częścią równouprawnienia. W rzeczywistości okazuje się, że bazy danych zawierają już dużo danych. A moi użytkownicy raczej się rozczarowują, gdy go tracą.

Gdy tylko wypuściłem wersję 1.0, pojawia się potrzeba utrzymania skryptów aktualizacji. Czasami zawierają one tylko zmiany schematu, ale wiele razy muszę tworzyć wartości domyślne na podstawie zawartości innej tabeli, muszę zwolnić określone ograniczenie, dopóki nie zainicjuję danych itp. Zwykle zwykłe uaktualnienie schematu nie do końca go wycina. Wolę te skrypty aktualizacji również w osobnym folderze w projekcie bazy danych. Zwykle wyglądają one jak „aktualizacja z wersji 1.0 do wersji 1.1”.

Moje bazy danych zawsze mają tabelę referencyjną, która informuje mnie o bieżącym numerze wersji, dzięki czemu mogę blokować niekompatybilne aktualizacje. Pierwsza instrukcja w moich skryptach aktualizacyjnych sprawdza bieżącą wersję i ratuje, czy różni się ona od oczekiwanych.

Kolejną korzyścią wynikającą z projektów baz danych jest możliwość wdrażania różnych zestawów danych w oparciu o ten sam schemat. Mam różne zestawy danych do programowania, zespołu kontroli jakości, testu akceptacji użytkownika i testów automatycznych integracji. Ponieważ projekt bazy danych może mieć tylko 1 skrypt po wdrożeniu, sztuczka polega na tym, aby utworzyć nowy projekt bazy danych, który odwołuje się do projektu „głównego” i uczynić niestandardowy zestaw danych częścią procesu po wdrożeniu tego projektu.

To były moje 2 centy. Niezależnie od tego, jaki proces wymyślisz, przede wszystkim musi on pasować do ciebie i twojego zespołu i, mam nadzieję, wspierać cię w większości typowych zadań.

Sam skończyłem pisać narzędzie.

Jest dostępny do pobrania za darmo - http://www.gitsql.net

Mam nadzieję, że pomoże to innym ludziom, którzy chcą osiągnąć ten sam cel końcowy.

Oto artykuł opisujący sposób kontroli źródła SQL Server. http://gitsql.net/documentation-04_SQL_Server_and_GIT

Starałem się, aby było to tak proste, jak to możliwe. (3 ekrany)

• Połącz się z SQL Server
• Wybierz obiekty
• Wybierz folder, z którego chcesz eksportować / importować

Ja także - przypadkowo - dodałem możliwość selektywnego wybierania poszczególnych obiektów do importu - lub eksportu. Co znacznie ułatwia programowanie.

Zwykle zmieniałem procedurę przechowywaną i tabelę, a następnie eksportowałem te dwa obiekty do katalogu GIT.

Następnie używam Drzewa Źródła, aby wizualnie zobaczyć zmiany, a następnie zatwierdzić je w bitbucket, jeśli jestem zadowolony.

Moja firma właśnie opracowała to nowe narzędzie ( bezpłatne ), które pomaga w łatwym wydobywaniu skryptów dla baz danych SQL, może dokonywać porównań , może uruchomić WinMerge do szybkiego porównywania skryptów z aktywną bazą danych, a także może synchronizować różnice zarówno aktualizując skrypty, jak i stosując zmiany do bazy danych (z wyjątkiem tabel, co wiązałoby się z większą złożonością i większym ryzykiem).

Servantt to WinMerge do porównywania baz danych SQL Server ze skryptami kontrolowanymi przez wersję.

Wspiera i zachęca do najlepszych praktyk w zakresie tworzenia oprogramowania:

• Utrzymywanie obiektów bazy danych pod kontrolą wersji (*)
• Usuwanie praw dostępu od programistów w środowiskach produkcyjnych
• Przegląd DBA zmian w procedurach / widokach dla wąskich gardeł wydajności i standardów nazewnictwa
• Nazewnictwo obiektów przy użyciu w pełni kwalifikowanych identyfikatorów i ograniczników w nawiasach kwadratowych (naprawia skrypty CREATE PROCEDURE / VIEW / FUNCTION / etc)

(*) Skrypty są zapisywane w folderze lokalnym, który może być roboczą kopią Git, Subversion, TFS, Source Safe lub dowolnego innego VCS.

Bezpłatne pobieranie: http://servantt.com

Wersja profesjonalna (która jest wciąż w fazie rozwoju) będzie zupełnie inną bestią - jest ukierunkowana na automatyzację wdrażania (zarządzanie wydaniami), do automatyzacji zadań, takich jak aktualizacja IIS, aktualizacja usług systemu Windows itp.