Myslím, že tento problém má dvě části.
První je správa databázového schématu a jeho změn. Děláme to pomocí South a uchováváme jak pracovní modely, tak migrační soubory v našem úložišti SCM. Pro bezpečnost (nebo paranoiu) provedeme výpis databáze před (a pokud se opravdu bojíme, i po) spuštění jakékoli migrace. Jih zatím vyhovoval všem našim požadavkům.
Druhým je nasazení změny schématu, která přesahuje pouhé spuštění migračního souboru generovaného Southem. Podle mých zkušeností změna databáze obvykle vyžaduje změnu nasazeného kódu. Pokud máte i malou webovou farmu, nemusí být synchronizace nasazeného kódu s aktuální verzí databázového schématu triviální – to se ještě zhorší, vezmete-li v úvahu různé vrstvy mezipaměti a vliv na již aktivního uživatele webu. Různé weby řeší tento problém různě a nemyslím si, že existuje jednoznačná odpověď.
Řešení druhé části tohoto problému nemusí být nutně přímočaré. Nevěřím, že existuje univerzální přístup a o vašem webu a prostředí není dostatek informací, aby bylo možné navrhnout řešení, které by bylo pro vaši situaci nejvhodnější. Domnívám se však, že existuje několik aspektů, které lze mít na paměti, aby pomohly nasměrovat nasazení ve většině situací.
V některých případech je možné převést celý web (webové servery a databáze) do režimu offline. Je to určitě nejpřímější způsob správy aktualizací. Ale časté prostoje (i když jsou plánované) mohou být dobrým způsobem, jak rychle začít podnikat, je únavné nasazovat i malé změny kódu a může trvat mnoho hodin, pokud máte velkou datovou sadu a/nebo složitou migraci. To znamená, že u webů, které pomáhám spravovat (které jsou všechny interní a obecně se používají pouze během pracovní doby v pracovní dny), tento přístup funguje skvěle.
Buďte opatrní, pokud provádíte změny na kopii vaší hlavní databáze. Hlavním problémem je, že váš web je stále aktivní a pravděpodobně přijímá zápisy do databáze. Co se stane s daty zapsanými do hlavní databáze, když jste zaneprázdněni migrací klonu pro pozdější použití? Váš web musí být buď celou dobu mimo provoz, nebo dočasně přepnout do stavu pouze pro čtení, jinak o ně přijdete.
Pokud jsou vaše změny zpětně kompatibilní a máte webovou farmu, někdy vám stačí aktualizovat živý produkční databázový server (což je podle mě ve většině situací nevyhnutelné) a poté postupně aktualizovat uzly ve farmě tím, že je odeberete z load balancer na krátkou dobu. To může fungovat dobře - hlavním problémem zde však je, pokud uzel, který již byl aktualizován, odešle požadavek na adresu URL, která není podporována starším uzlem, dojde k selhání, protože to nemůžete spravovat na úrovni nástroje pro vyrovnávání zatížení.
Viděl/slyšel jsem několik dalších způsobů, jak fungují dobře.
První je zabalit všechny změny kódu do zámku funkcí, který je pak konfigurovatelný za běhu pomocí některých možností konfigurace na celém webu. To v podstatě znamená, že můžete uvolnit kód, kde jsou všechny vaše změny vypnuty, a poté, co provedete všechny potřebné aktualizace vašich serverů, změníte možnost konfigurace, abyste tuto funkci povolili. Ale to dělá docela těžký kód...
Druhým je nechat kód řídit migraci. Slyšel jsem o webech, kde jsou změny v kódu napsány tak, že to zvládne migraci za běhu. Je schopen detekovat používanou verzi schématu a formát dat, která získala zpět - pokud jsou data ze starého schématu, provede migraci na místo, pokud jsou data již z nového schématu, nedělá nic . Z přirozeného používání webu bude velká část vašich dat migrována lidmi používajícími web, zbytek můžete provést pomocí migračního skriptu, kdykoli budete chtít.
Ale myslím si, že v tomto okamžiku se Google stane vaším přítelem, protože jak říkám, řešení je velmi kontextově specifické a obávám se, že tato odpověď začne ztrácet smysl... Hledejte něco jako „zero down time deployment“ a vy' Získáte výsledky jako toto se spoustou nápadů...