Rozgałęzianie i bazy danych TFS

Question

Mam projekt, w którym musimy skonfigurować prostą strategię rozgałęziania, aby umożliwić rozwój nowych funkcji, a jednocześnie móc naprawiać błędy w innej gałęzi.

Problem, który mam z bazami danych.

Schemat bazy danych jest częścią TFS jako projektu bazy danych, ale aby mieć wystarczająco dużo danych testowych, które zrobiliśmy w jednym punkcie, należy wykonać kopię zapasową żywej bazy danych i wykorzystać ją do testowania podczas programowania.

Obecnie bazy danych (drzewa ogółem) znajdują się na serwerze grupy roboczej z jednym zestawem baz danych dla każdego programisty, a każdy zestaw baz danych jest od czasu do czasu aktualizowany skryptami sql tworzonymi przez innych programistów po zmianie schematu .

Moje pytanie: Jak możemy to zreorganizować, aby każda gałąź była niezależna i możemy łatwo przejść z jednej gałęzi do drugiej. Rozważałem już użycie SQL Express i umieszczenie baz danych wewnątrz oddziału, ale to się nie udało. Przyjrzeliśmy się również tworzeniu skryptów zawierających wszystkie dane i przebudowie bazy danych z bazy danych, ale okazało się, że zajęło to zbyt dużo czasu, a niektórzy programiści często zapomnieli zrobić to wystarczająco często.

Wszelkie pomysły?

Answer 1

Visual Studio obsługuje database projects. Użyj tego, a miejmy nadzieję, że rozgałęzienie będzie stosunkowo proste.

Można przywrócić kopię zapasową bazy danych, a następnie użyć GDR do synchronizacji/aktualizacji schematu bazy danych. Będziesz musiał skrypty zmiany danych.

Wiąże się to z dużym nakładem początkowej konfiguracji.

• VSTS DB Team Blog

• Visual Studio TFS Branching and Merging Guidance

• Visual Studio Team Foundation Server Branching and Merging Guide

Answer 2

projekty baz danych Visual Studio nie jest optymalnym narzędziem do wspierania uaktualnień baz danych, przy jednoczesnym zachowaniu danych.

Może być przydatne ponowne przemyślenie relacji między świeżymi instalacjami i aktualizacjami. Dla wielu firm aktualizacje są po kolei i skrypty aktualizacji są tworzone na podstawie delt świeżych skryptów instalacyjnych. Prowadzi to do powielania konserwacji, niespójności i dużej zależności od "aktualnego" schematu na ścieżce aktualizacji.

bym też zalecamy

• utrzymując jedynie uaktualnienia skryptów (z wyjątkami, gdzie preferowany jest kod źródłowy deklaratywne i pełne odświeża możliwe są po każdej aktualizacji)
• zdecydować, czy zrobić lub nie mają wspierać umniejsza
• Zapewnij na poziomie infrastruktury, że każdy skrypt uaktualniający zostanie zastosowany co najwyżej raz
• zasadniczo nigdy nie edytuj skryptu aktualizacji, spróbuj dodać nowe na końcu sekwencji aplikacji

Jest to dość inwazyjna zmiana i wymaga zmiany sposobu myślenia, dlatego najpierw należy starannie ocenić swoje potrzeby w zakresie długoterminowej aktualizacji. Wskazaniem, że trzeba przejść przez zmianę, jest oczekiwanie na wiele równoległych prac rozwojowych lub konserwacyjnych w wielu gałęziach wydań i rozwoju.