Nextras/Migrations rollback aplikace na produkci
- TonnyVlcek
- Člen | 31
TL;DR:
Chyba na produkci, chceme udělat co nejrychlejší rollback na předchozí
verzi, kde víme, že všechno funguje: Co dělat s databází a migracemi?
Ahoj,
používáme Nextras migrace a pro vývoj to funguje skvěle. Seznámil jsem
s teorií a důvody proč nextras migrace fungují tak, jak fungují (díky: https://www.youtube.com/watch?…). Teď ale narážíme na
potíž při přípravě infrastruktury pro produkci. Chceme mít možnost
udělat rollback aplikace, pokud se do produkce dostane něco špatného.
Rollback aplikace je v celku jednoduchý – máme uložené předchozí
buildy, takže stačí jen nainstalovat předchozí.
Jak na to s databází? Samozřejmě migrations:continue fungovat nebude,
protože předchozí migrace už jsou v databázi, migrations:reset taky ne
(dropnout produkční databází není ideální).
Možnosti
Koukal jsem na přednášku Verzování Databáze od Martina Majora (https://www.youtube.com/watch?…) a to by to nejspíš
vyřešilo hodně problémů. Pokud bychom zavedli psaní zpětně
kompatiblních migrací, při rollbacku aplikace by nebylo třeba dělat nic
s databází protože je zaručeno, že starší verze aplikace umí pracovat
s novou verzí databáze.
Naše databáze je zatím relativně malá, napadlo mě dělat snapshot pokaždé když je nasazena nová verze, která obsahuje změny v databázi. Pokud by potom bylo potřeba rychle udělat rollback na předchozí verze nasadil by se snapshot. (tohle ale asi není příliš škálovatelné a je to data-drahé).
Jak na to?
- TonnyVlcek
- Člen | 31
Díky za odpověď :)
Používáme RackSpace. Já se v dev-ops moc nevyznám a teď se to spíš učím od chlapíka co má ty servery na starosti. Z toho co mi říkal, tak pod RackSpace jsou v podstatě dvě možnosti:
- Používat nějakou existující službu RackSpace, což je prý pro náš projekt docela overkill, hlavně co se ceny týče (nehraje roli velikost databáze a je to připravený pro projekty které řeší mnohem větší objemy dat)
- Napsat si nějaký vlastní skript na zálohování a ukládat do jejich CloudStorage, který je v porovnání prý podstatně levnější.
Dneska jsem nad tím ještě dumal a probíral to s ním, došli jsme k tom, že pokud budeme potřebovat rollback tak se podíváme na diff těch dvou verzí a podle obsahu (nebo absence) migrací si to rozdělíme do dvou kategorií:
- Žádné migrace + Bezpečné migrace (zpětně kompatibilní) – pokud budeme vědět, že přidané migrace neovlivní chování aplikace ve verzi na kterou se vracíme.
- Nevratné migrace (například drop tabulky, nebo sloupce) – budeme se must podívat na poslední pravidelný snapshot databáze a když bude nutné, tak rollbacknout až tam (dojde k nějaké ztrátě dat). Tohle se budeme snažit omezit dvěma způsoby: psát zpětně kompatibilní migrace, místo rollbacku zkusit chybu opravit bugfixem, který přidá novou migraci.