Jaki jest dobry sposób na migrację zmian DB z programowania do kontroli jakości do środowisk produkcyjnych? Obecnie my:

1. Skryptuj zmianę w pliku SQL i dołącz ją do elementu pracy TFS.
2. Praca jest recenzowana
3. Gdy praca jest gotowa do testowania, SQL jest uruchamiany w ramach kontroli jakości.
4. Praca jest testowana pod kątem jakości
5. Gdy praca jest gotowa do produkcji, SQL jest uruchamiany w produkcyjnych bazach danych.

Problem polega na tym, że jest to bardzo ręczne. Polega on na tym, że deweloper pamięta, aby dołączyć sql lub recenzenta łapiąc go, jeśli programista zapomni. Czasami kończy się to testerem lub wdrażającym QA, który odkrywa problem.

Drugi problem polega na tym, że czasami trzeba ręcznie koordynować zmiany, jeśli dwa oddzielne zadania zmieniają ten sam obiekt bazy danych. Może tak po prostu jest, ale nadal wydaje się, że powinien istnieć jakiś zautomatyzowany sposób „oflagowania” tych problemów lub coś takiego.

Nasza konfiguracja: nasz sklep deweloperski jest pełen programistów z dużym doświadczeniem w zakresie DB. Nasze projekty są bardzo zorientowane na DB. Jesteśmy głównie sklepem .NET i MS SQL. Obecnie używamy elementów roboczych MS TFS do śledzenia naszej pracy. Jest to przydatne w przypadku zmian kodu, ponieważ łączy zestawy zmian z elementami pracy, dzięki czemu mogę dowiedzieć się dokładnie, jakie zmiany muszę wprowadzić podczas migracji do środowisk QA i produkcyjnych. Obecnie nie korzystamy z projektu DB, ale możemy przejść do niego w przyszłości (być może jest to część odpowiedzi).

Jestem bardzo przyzwyczajony do mojego systemu kontroli źródła, który zajmuje się takimi rzeczami dla mnie i chciałbym mieć to samo dla mojego SQL.

W środowisku VS zawsze korzystałem z projektów baz danych w celu wdrożenia skryptów aktualizacji. W swoich skryptach używam niewyobrażalnych nazw, takich jak „DatabaseUpdate17.sql” lub „PriceUpdateFeb February2010.sql”. Posiadanie ich jako projektów baz danych pozwala mi powiązać je z zadaniami Team Server, błędami (i jeśli zrobiliśmy recenzje kodu, również z nimi). Do każdej bazy danych (nad którą mam uprawnienia) dołączam również tabelę specjalnie do zbierania zmian w schemacie.

CREATE TABLE [dbo].[AuditDDL](
    [EventID] [int] IDENTITY(1,1) PRIMARY KEY NOT NULL,
    [EventData] [xml] NULL,                    -- what did they do
    [EventUser] varchar(100) NOT NULL,         -- who did it
    [EventTime] [datetime] DEFAULT (getdate()) -- when did they do it
    )
GO

Dobrze, że troszczy się o 3 z 6 Ws .

CREATE TRIGGER [trgAuditDDL]
ON DATABASE 
FOR DDL_DATABASE_LEVEL_EVENTS 
AS
INSERT INTO AuditDDL(EventData, EventUser)
SELECT EVENTDATA(), original_login()
GO

Do instrukcji dołączam instrukcję insert, która rejestruje początek i koniec łatki. Wydarzenia, które mają miejsce poza łatkami, są warte uwagi.

Na przykład wstawka „rozpocznij łatkę” dla „poprawki 17” wyglądałaby następująco:

INSERT INTO [dbo].[AuditDDL]
           ([EventData]
           ,[EventUser])
     VALUES
           ('<EVENT_INSTANCE><EventType>BEGIN PATCH 17</EventType></EVENT_INSTANCE>'
           ,ORIGINAL_LOGIN())
GO

Ponieważ wyłapuje się również przy przebudowywaniu indeksów, musisz co miesiąc uruchamiać następujące czynności, aby usunąć te zdarzenia:

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"ALTER_INDEX")]') =1
GO

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"UPDATE_STATISTICS")]') =1
GO

Wcześniejsza wersja opublikowana wcześniej w usłudze Server Fault .

W środowisku zgodnym z SOX i PCI-DSS nigdy nie będziesz mieć dostępu do serwerów produkcyjnych. Dlatego skrypty muszą być jasne i wykonane wcześniej. Komentarze u góry skryptów aktualizacji zawierają listy nowych tabel, przechowywane procy, funkcje itp., A także listy zmodyfikowanych tabel, przechowywane procy, funkcje itp. Jeśli dane zostaną zmodyfikowane, wyjaśnij, co jest modyfikowane i dlaczego.

Drugi problem polega na tym, że czasami trzeba ręcznie koordynować zmiany, jeśli dwa oddzielne zadania zmieniają ten sam obiekt bazy danych. Może tak po prostu jest, ale nadal wydaje się, że powinien istnieć jakiś zautomatyzowany sposób „oflagowania” tych problemów lub coś takiego.

Nigdy nie spotkałem narzędzia, które pozwala nam to śledzić automatycznie. Poprzedni pracodawcy stosowali zasadę „właściciela bazy danych” - jednej i tylko jednej osoby, która jest osobiście odpowiedzialna za bazę danych. Ta osoba nie będzie jedynym programistą działającym przeciwko tej bazie danych, ale raczej wszystkie zmiany muszą przez nią przejść. Działało to dość dobrze, aby zapobiec wzajemnym zderzeniom i szkodom.

Czy spojrzałeś na SQL Source Control? Możesz go użyć do połączenia SQL Servera z TFS / SVN / Vault lub VSS - http://www.red-gate.com/products/sql-development/sql-source-control/

Innym rozwiązaniem jest użycie czegoś takiego jak PowerDesigner, ERWin itp. Do projektowania i zarządzania zmianami w bazie danych.

Zaczynamy przechodzić do zasad, w których bazy danych są modelowane w PowerDesigner. Wszystkie zmiany w strukturze / kodzie bazy danych są wprowadzane w modelu, sprawdzane w kontroli źródła, a następnie generowane są skrypty zmian z modeli w celu zaimplementowania zmian w bazie danych. Te skrypty zmian są również rejestrowane w celu kontroli źródła. Duże zmiany są recenzowane, a PowerDesigner bardzo ułatwia korzystanie z wbudowanych funkcji.

PowerDesigner to ogólne narzędzie do modelowania obsługujące więcej niż tylko bazy danych, więc zaczynamy go używać do zarządzania wymaganiami, tworzenia schematów koncepcyjnych, fizycznych i architektury (także OOM) itp. Zasadniczo używamy go do zapewnienia szkieletu naszej proces inżynierii oprogramowania.

(Nie jestem w żaden sposób związany z Sybase, która opracowała PowerDesigner - pomyślałem, że wrzucę to tam).

DB Ghost

DB Ghost to moje ulubione narzędzie do zarządzania bazami danych.

Korzyści

1. Wszystkie obiekty w bazie danych są przechowywane jako skrypty w kontroli źródła.
2. Możesz także pisać skrypty „dane statyczne” (dane tabeli odnośników).
3. Możesz zaktualizować kontrolę źródła ręcznie lub poprzez skrypt skryptowej programistycznej bazy danych.
4. Możesz szybko zbudować bazę danych ze skryptów w kontroli źródła (w tym danych statycznych).
5. Możesz wdrożyć zmiany w wystąpieniach bazy danych, w tym we wszystkich wystąpieniach produkcyjnych:
   • Możesz porównać „bazę danych kompilacji” (utworzoną ze skryptów) z istniejącą bazą danych i wygenerować skrypt zmian.
   • Możesz polecić DB Ghost, aby automatycznie synchronizował zmiany między dwoma instancjami bazy danych, np. Bazą danych kompilacji i produkcyjną bazą danych.

[4] jest szczególnie przydatny do wprowadzania lokalnych zmian lub tworzenia osobnych instancji dla różnych środowisk. W rzeczywistości jest to tak łatwe, że tworzę osobną bazę danych dla każdej funkcji lub błędu, nad którym pracuję, który wpływa na bazę danych.

Detale

Główną zaletą korzystania z niego nad utrzymywaniem jawnych skryptów zmian lub migracji jest to, że w większości przypadków nie trzeba utrzymywać jawnych skryptów zmian lub migracji - zazwyczaj można zachować tylko „bieżącą wersję” bazy danych. Jednym z irytujących aspektów zarządzania skryptami migracji jest to, że nie ma łatwego sposobu na zobaczenie, np. Listy kolumn w tabeli (na podstawie skryptów migracji). Oczywiście, niektóre zmiany należy wprowadzić jako jawne migracje, ale są one wystarczająco łatwe do obsługi jako osobne skrypty.

Szczególnie miłą konsekwencją zarządzania bazami danych (zestawem skryptów), a także szybkiego tworzenia nowych instancji jest to, że testowanie ważnego kodu bazy danych jest bardzo łatwe (i bardzo przyjemne). Używam tSQLt do testowania jednostek.

Żałuję tylko, że nie było podobnego narzędzia dla innych DBMS-ów.

Wiem, że to brzmi zbyt przesadnie w stosunku do większości DBA:

Czy rozważałeś użycie Ruby on Rails do śledzenia zmian w Bazie danych (i tylko zmian w DB). Nie musisz uruchamiać żadnej aplikacji ani pisać kodu ruby ​​itp. Ale uważam, że styl migracji (tak to nazywają) jest dość przydatny: http://guides.rubyonrails.org/migrations.html

Obsługiwany jest także serwer SQL, może być konieczne użycie JRuby + JDBC.