Ciągła integracja i zarządzanie bazą danych

Question

Podczas pracy nad projektem z kilkoma innymi osobami często można mieć kilka osób z różnymi obszarami, takimi jak baza danych.

Moje wyzwanie polega na tym, jak pozwolić kilku osobom edytować model bazy danych w ciągłym środowisku integracyjnym.

Deweloper zasugerował napisanie "skryptu wersjonującego", w którym każda zmiana została wprowadzona do skryptu .sql, z numerem wersji, który byłaby w stanie wykryć baza danych. Nowy dodatek do modelu byłby w tym pliku oznaczony wersją, a baza danych byłaby aktualizowana po przesłaniu skryptu i uruchomieniu kompilacji.

Słyszałem również o wydawcy/subskrybencie ... i trochę o tym przeczytałem.

W jaki sposób radzisz sobie z tą sytuacją w codziennej pracy i jakie sugestie możesz mi zapewnić, aby zmiany w bazie danych przebiegły tak bezproblemowo, jak to możliwe?

** Edycja **

ramy migracji i migracją skrypty zostały wymienione. Jeśli masz jakieś praktyczne doświadczenie i zaproponowałbyś ramy, które również zostałyby docenione.

Answer 1

Cytowanie Jeff Atwood w doskonałej Get Your Database Under Version Control postu:

...

Myślałam o tym znowu ponieważ mój przyjaciel i co-author K. Scott Allen po prostu napisał błyskotliwą pięć części seria na temat filozofii i kontrola wersji bazy danych:

1. Three rules for database work
2. The Baseline
3. Change Scripts
4. Views, Stored Procedures and the Like
5. Branching and Merging

...

Naprawdę, cała seria jest warta odczytu nawet jeśli wielu z was wydaje się być szczególnie zainteresowany trzecią częścią. A przy okazji przyjrzyj się artykułowiwspomnianemu również w trzeciej części. Być może już wiesz o tym, ale wyjaśniono między innymi, dlaczego pisanie skryptów idempotent jest ważne.

chodzi oprzyrządowania, może chcesz sprawdzić UpToDater (kod Centric) LiquiBase (oparty na XML) lub ... dbdeploy, trochę gem na podstawie doświadczeń w świecie rzeczywistym rozwoju oprogramowania w ThoughtWorks. Nie chodzi o to, że 2 pierwsze nie są dobre, ale ten jest moim preferowanym (i jest dostępny dla Java, PHP lub .NET).

Answer 2

Sprawdź struktury migracji. AFAIK, pomysł przyszedł z szyn, ale ludzie zbudowali ramy dla prawie wszystkiego innego w tym momencie.

Answer 3

Zwykle najlepiej działam ze skryptami "migracyjnymi", które są kolejnym etapem od prostego skryptu z wersjami. Migracja polega na określeniu zmian w bazie danych (dodaniach, usunięciach itp.) Oraz cofnięciu zmian przeprowadzanych przez migrację. Jest to następnie oznaczane wersją jakiejś formy, która nie koliduje z innymi programistami. Szczególnie dobrym numerem wersji jest aktualny czas (w formacie YYYYMMDDHHMMSS lub w sekundach od epoki). Jest to dobry wybór, ponieważ jest bardzo mało prawdopodobne, aby pojawiły się starcia wersji i nadal bardzo łatwo jest sprawdzić, czy istnieją nowe wersje ze względu na ściśle rosnący charakter takich sygnatur czasowych.

Uwaga: na system Rails ma duży wpływ ten system. Aby uzyskać więcej szczegółów i pomysłów, gorąco polecam zajrzenie do tego systemu. migracja

szyn:

class CreateGroups < ActiveRecord::Migration 
    def self.up 
    create_table :groups do |t| 
     t.string :name 
     t.references :owner 

     t.timestamps 
    end 
    end 

    def self.down 
    drop_table :groups 
    end 
end 

Doktryna migracyjna:

class CreateGroups extends Doctrine_Migration 
{ 
    public function up() 
    { 
     // Create new author table 
     $columns = array('id' => array('type'   => 'integer', 
             'length'  => 4, 
             'autoincrement' => true), 
         'name' => array('type'   => 'string', 
             'length'  => 255), 
         'owner_id' => array('type' => 'integer', 
              'length' => 4)); 

    $this->createTable('groups', $columns, array('primary' => array('id'))); 
    } 

    public function down() 
    { 
    $this->dropTable('groups'); 
    } 
} 

(przepraszam za brak znaczników czasu w nauce ... w szynach wywołanie dodaje znaczniki czasu w created_at i updated_at pól do tabeli są automatycznie zarządzane dla ciebie. Nie jestem pewien podobnych zachowań w doktrynie, więc je zostawiłem).

Answer 4

To zależy.

Jeśli chodzi o wydany produkt, o którym mówisz, zmiany schematu powinny być starannie śledzone, abyś mógł zaplanować proces aktualizacji. Dobrze byłoby zacząć o tym teraz myśleć, więc "skrypt wersjonujący" ma pewien sens. Jednak kompatybilność wstecz/do przodu jest zwykle tylko wymaganiem widocznym dla użytkownika, a nie wymaganiem "między kompilacjami". Pomiędzy wersjami sensownym byłoby utrzymanie skryptu aktualizacyjnego, który modyfikuje tabele bazy danych, aby dostosować je do nowego schematu.

Jeśli jest to produkt nowy/niewydany, co Cię obchodzi, jeśli ktoś zmieni schemat?I dlaczego chciałbyś nawet zachować bazę danych pomiędzy ciągłymi kompilacjami integracyjnymi? W każdym razie powinieneś być w stanie zregenerować dowolne dane testowe za pomocą automatycznego testu. Każdy, kto zmieni schemat, powinien również zaktualizować testy.

W przypadku opublikowanego produktu prawdopodobnie trzeba będzie mieć zestaw testów, które mogą obsługiwać bazę danych "wersja 1.0", aby upewnić się, że można ją pomyślnie uaktualnić do "wersji 1.1" (na przykład).

Answer 5

Piszemy wszystko w Subversion i sprawdzamy w projekcie tak jak każdy inny kod. Wszystkie wdrożenia baz danych są wykonywane ze skryptów pobranych z systemu kontroli kodu źródłowego. Jeśli dwoje ludzi pracuje nad tym samym skryptem (co jest dość rzadkie) Subversion pozwoli ci połączyć dwa skrypty.

Answer 6

Stos technologii (w tym wykorzystana baza danych) nie został opisany w pytaniu, które jest bardzo istotne, które rozwiązanie najlepiej pasuje.

Bardzo popularnym rozwiązaniem migracji opartych na technologii Java jest Flyway. DBUp jest bardzo podobny, ale skupia się na stosie .NET.

Tutaj w Redgate oferujemy ReadyRoll, który integruje się ściśle z Visual Studio i działa wyłącznie na SQL Server.