Zaktualizowałem mój oryginalny post poniżej, aby odzwierciedlić zmiany w najnowszych wersjach SQL Source Control (3.0) i SQL Compare (10.1).
Ponieważ to pytanie zostało zadane ponad rok temu, moja odpowiedź może nie być dla ciebie zbyt pomocna, ale dla innych, którzy mogą obecnie oceniać SSC, pomyślałem, że dorzucę moje dwa centy. Właśnie zaczęliśmy korzystać z kontroli źródła SQL (SSC) i ogólnie jestem z tego dość zadowolony. Ma jednak pewne dziwactwa, zwłaszcza jeśli pracujesz w środowisku współużytkowanej bazy danych (w przeciwieństwie do każdego programisty pracującego lokalnie), a szczególnie pracujesz w starszym środowisku, w którym obiekty w tej samej bazie danych są przypadkowo dzielone między zespoły programistów.
Aby przedstawić krótki przegląd tego, w jaki sposób korzystamy z produktu w naszej organizacji, pracujemy we wspólnym środowisku, w którym wszyscy wprowadzamy zmiany w tej samej programistycznej bazie danych, więc dołączyliśmy udostępnioną bazę danych do repozytorium kontroli źródła. Każdy deweloper jest odpowiedzialny za wprowadzanie zmian w obiektach w bazie danych za pośrednictwem programu SQL Server Management Studio (SSMS), a po zakończeniu może zatwierdzić swoje zmiany w kontroli źródła. Kiedy jesteśmy gotowi do wdrożenia do stagingu, build master (ja) scala gałąź deweloperską kodu bazy danych z gałęzią główną (staging), a następnie uruchamia SQL Compare, używając wersji bazy danych z repozytorium gałęzi głównej jako źródła i na żywo pomostowa baza danych jako obiekt docelowy, a funkcja SQL Compare generuje niezbędne skrypty do wdrożenia zmian wprowadzonych w środowisku pomostowym. Przenoszenie do wdrożeń produkcyjnych działa w podobny sposób. Innym ważnym punktem, na który należy zwrócić uwagę, jest to, że biorąc pod uwagę fakt, że dzielimy tę samą bazę danych z innymi zespołami programistycznymi, używamy wbudowanej funkcji SSC, która umożliwia tworzenie filtrów na obiektach bazy danych według nazwy, typu itp. skonfiguruj filtry na obiektach naszego konkretnego zespołu, wykluczając wszystkie inne obiekty, abyśmy nie zatwierdzili przypadkowo zmian innych zespołów programistycznych podczas naszych wdrożeń.
Ogólnie rzecz biorąc, jest to dość prosty produkt w konfiguracji i obsłudze, który jest naprawdę przyjemny, ponieważ zawsze pracujesz z żywymi obiektami w SSMS, w przeciwieństwie do odłączonych plików skryptów przechowywanych w osobnym repozytorium źródłowym, które stwarzają ryzyko utraty synchronizacji . Jest to również miłe, ponieważ SQL Compare generuje za Ciebie skrypty wdrożeniowe, więc nie musisz się martwić o wprowadzanie błędów, tak jak gdybyś sam tworzył skrypty. A ponieważ SQL Compare jest bardzo dojrzałym i stabilnym produktem, możesz mieć pewność, że stworzy dla Ciebie odpowiednie skrypty.
Mając to na uwadze, oto kilka dziwactw, z którymi do tej pory się spotkałem:
- SSC jest dość gadatliwy po wyjęciu z pudełka, jeśli chodzi o komunikację z serwerem bazy danych w celu śledzenia elementów bazy danych, które nie są zsynchronizowane z repozytorium kontroli źródła. Odpytuje co kilka milisekund i jeśli dodasz wielu programistów pracujących na tej samej bazie danych przy użyciu SSC, możesz sobie wyobrazić, że nasi dbali nie byli zbyt zadowoleni. Na szczęście możesz łatwo zmniejszyć częstotliwość odpytywania do czegoś bardziej akceptowalnego, choć kosztem poświęcenia responsywnych powiadomień wizualnych o zmianie obiektów.
- Korzystając z funkcji filtrowania obiektów, nie można łatwo stwierdzić, patrząc na obiekty w SSMS, które obiekty są uwzględnione w filtrze. Więc nie wiesz na pewno, czy obiekt jest pod kontrolą źródła, w przeciwieństwie do Visual Studio, gdzie ikony są używane do wskazywania obiektów kontrolowanych przez źródło.
- GUI filtrowania obiektów jest bardzo toporne. Ze względu na to, że pracujemy w starszym środowisku bazodanowym, obecnie nie ma wyraźnego rozgraniczenia między obiektami, które posiada nasz zespół, a obiektami posiadanymi przez inne zespoły, aby zapobiec przypadkowemu zatwierdzeniu/wdrożeniu zmian innych zespołów , ustawiliśmy schemat filtrowania, aby jawnie uwzględnić każdy konkretny obiekt, który posiadamy. Jak możesz sobie wyobrazić, staje się to dość kłopotliwe, a ponieważ GUI do edycji filtrów jest skonfigurowany tak, aby wprowadzać jeden obiekt na raz, może to stać się dość bolesne, szczególnie próbując skonfigurować swoje środowisko po raz pierwszy (skończyło się napisanie wniosku, aby to zrobić). Idąc dalej, tworzymy nowy schemat dla naszej aplikacji, aby lepiej ułatwić filtrowanie obiektów (poza tym, że i tak jest to lepsza praktyka).
- Korzystając z modelu udostępnionej bazy danych, programiści mogą wprowadzać wszelkie oczekujące zmiany w bazie danych kontrolowanej przez źródło, nawet jeśli zmiany nie są ich. SSC wyświetla ostrzeżenie, jeśli spróbujesz sprawdzić kilka zmian, że te zmiany mogą nie być Twoje, ale poza tym, że jesteś sam. Uważam, że jest to jedno z najniebezpieczniejszych „dziwactwa” SSC.
- Porównanie SQL nie może obecnie udostępniać filtrów obiektów utworzonych przez SSC, więc musiałbyś ręcznie utworzyć pasujący filtr w Porównywaniu SQL, więc istnieje niebezpieczeństwo, że mogą one nie być zsynchronizowane. Właśnie skończyłem wycinać i wklejać filtry z bazowego pliku filtru SSC do filtra projektu SQL Compare, aby uniknąć radzenia sobie z nieporęcznym interfejsem GUI do filtrowania obiektów. Wierzę, że następna wersja SQL Compare pozwoli na współdzielenie filtrów z SSC, więc przynajmniej ten problem jest tylko krótkoterminowy. (UWAGA:ten problem został rozwiązany w najnowszej wersji programu SQL Compare. Funkcja SQL Compare może teraz używać filtrów obiektów utworzonych przez SSC.)
- SQL Compare również nie może porównywać z repozytorium bazy danych SSC po bezpośrednim uruchomieniu. Musi być uruchamiany z poziomu SSMS. Wierzę, że następna wersja SQL Compare zapewni tę funkcjonalność, więc znowu jest to kolejny krótkoterminowy problem. (UWAGA:ten problem został rozwiązany w najnowszej wersji programu SQL Compare.)
- Czasami SQL Compare nie jest w stanie utworzyć odpowiednich skryptów, aby przenieść docelową bazę danych z jednego stanu do drugiego, zwykle w przypadku aktualizowania schematu istniejących tabel, które nie są puste, więc obecnie musisz pisz ręczne skrypty i samodzielnie zarządzaj procesem. Na szczęście zostanie to rozwiązane za pomocą „skryptów migracji” w następnym wydaniu SSC, a patrząc na wczesną wersję produktu, wydaje się, że implementacja tej nowej funkcji była dobrze przemyślana i zaprojektowana. (UWAGA:funkcja skryptów migracji została oficjalnie wydana. Jednak obecnie nie obsługuje rozgałęzień. Jeśli chcesz użyć skryptów migracji, musisz uruchomić porównanie sql z oryginalną gałęzią kodu programistycznego... zaewidencjonowałeś swoje zmiany ... co jest dość niezgrabne i zmusiło mnie do zmodyfikowania mojego procesu kompilacji w sposób mniej niż idealny, aby obejść to ograniczenie. Mam nadzieję, że zostanie to rozwiązane w przyszłej wersji.)
Ogólnie jestem bardzo zadowolony z produktu i reakcji Redgate na opinie użytkowników oraz kierunku, w jakim produkt podąża. Produkt jest bardzo łatwy w użyciu i dobrze zaprojektowany, i czuję, że w następnej lub dwóch wydaniach produkt prawdopodobnie zapewni nam większość, jeśli nie wszystko, czego potrzebujemy.
