Pracoval jsem převážně v oblasti vývoje obchodních aplikací a správy konfigurací. Vaše otázka je reprezentativní pro výzvy v takovém prostředí; když upgradujete například Microsoft Word, nemusíte hned měnit všechny dokumenty z doc na docx. A dokumenty mají dokonce jednodušší strukturu a úplnou relační databázi.
Ne tak pro obchodní aplikace; uživatelé přeskakují vydání, provádějí neautorizované změny datového modelu a systém musí nadále běžet a poskytovat správná čísla...
Pro naše vlastní aplikace (největší z nich je asi 600 tabulek) používáme CASE nástroj, který si sami vyvinuli, který zahrnuje větvení/slučování, ale přístup lze provést i ručně.
Datový model verze
Datový model lze zapsat strukturovaným způsobem. Například jako obsah tabulky (CSV, který se má načíst do tabulky s metadaty) nebo jako kód, který detekuje používanou verzi a přidává sloupce a tabulky, pokud chybí, včetně netriviálních migrací.
To dokonce umožňuje více uživatelům současně měnit datový model.
Když používáte automatickou detekci (například používáme volání s názvem „verify_column“ místo „add_column“), umožňuje to dokonce hladkou migraci nezávisle na čísle vydání, ze kterého zákazník zahajuje upgrade. Takový postup analyzuje tabulku, která má být změněna, a vydá správné DDL, jako je alter table t1 add col1 number not null když chybí sloupec nebo alter table t1 modify col1 not null když sloupec již byl přítomen, ale s možnou hodnotou null.
Pro Oracle a SQL Server vám mohu poskytnout několik ukázkových postupů. V MySQL bych to kódoval pomocí jazyka na straně klienta, nejlépe nezávislého na OS, aby bylo možné spustit instalace na Windows a Linux. Možná pomocí Apache Ant, když s tím máte zkušenosti.
Údaje o verzi
Tabulky jsme rozdělili do čtyř kategorií:
- R:referenční data; údaje, které musí místo aplikace poskytnout, než systém skutečně použije. Například kódy účtů hlavní knihy. Referenční data se po uvedení do provozu jen zřídka mění a jejich velikost se neustále nezvětšuje. Obsah odráží obchodní model webu, kde se aplikace používá.
- T:údaje o transakci; údaje, které stránka registruje, mění a odstraňuje během používání aplikace. Například položky hlavní knihy. Data transakce začínají na 0 a neustále rostou. Když společnost zdvojnásobí výnosy, zdvojnásobí se také údaje o transakcích.
- S:nasazená data; data NEUdržovaná uživatelem na webu, ale poskytnutá a spravovaná vývojovou stranou. V podstatě se jedná o kód přeměněný na data. Například „F“ znamená „Žena“. Chyby v nasazených datech mohou vést k systémovým chybám.
- O:zbytek (v ideálním případě není potřeba, protože jsou technické, ale některé systémy vyžadují dočasnou tabulku A nebo tabulku B).
Obsah tabulek kategorie 'S' (nasazená data) je umístěn pod kontrolu verzí. Obvykle je registrujeme jako metadata v našem nástroji pro případ, pak pojmenovaném „sady dat“, ale můžete také použít například Microsoft Excel nebo dokonce kód.
Například v Excelu budete mít seznam řádků nasazených dat. Do sloupce A můžete zadat funkci Excelu jako =B..&"|"&C..& "|" & ... který vše spojuje a dělá to vhodné pro načítání nástrojem loader.
Například v kódu můžete mít volání jako:
verifySeed('TABLE_A', 'CODE', 'VALUE')
Excel je trochu těžké přenést pod kontrolu verzí, což umožňuje více uživatelům měnit obsah současně. Přístup s kódem je velmi jednoduchý.
Nezapomeňte také přidat funkce pro odstranění zastaralých nasazených dat. Například výslovným uvedením zastaralých nasazených dat nebo automatickým odstraněním všech nasazených dat přítomných v tabulkách, kterých se poslední instalace nedotkla.