Мисля, че този проблем има две части.
Първо е управлението на схемата на базата данни и нейните промени. Правим това с помощта на South, като запазваме както работещите модели, така и файловете за миграция в нашето SCM хранилище. За безопасност (или параноя) правим дъмп на базата данни преди (и ако наистина се страхуваме, след това) стартиране на всякакви миграции. South беше адекватен за всичките ни изисквания досега.
Второто е внедряване на промяната на схемата, която надхвърля простото стартиране на файла за миграция, генериран от South. Според моя опит промяната в базата данни обикновено изисква промяна на внедрения код. Ако имате дори малка уеб ферма, поддържането на внедрения код в синхрон с текущата версия на схемата на вашата база данни може да не е тривиално - това се влошава, ако вземете предвид различните слоеве на кеширане и ефект върху вече активен потребител на сайта. Различните сайтове се справят с този проблем по различен начин и не мисля, че има еднозначен отговор за всички.
Решаването на втората част на този проблем не е непременно просто. Не вярвам, че има универсален подход и няма достатъчно информация за вашия уебсайт и среда, за да предложим решение, което би било най-подходящо за вашата ситуация. Въпреки това мисля, че има няколко съображения, които могат да се имат предвид, за да помогнат за насочване на внедряването в повечето ситуации.
Извеждането на целия сайт (уеб сървъри и база данни) офлайн е опция в някои случаи. Това със сигурност е най-лесният начин за управление на актуализации. Но честите прекъсвания (дори когато са планирани) могат да бъдат добър начин за бързо извършване на работата, прави уморително внедряването дори на малки промени в кода и може да отнеме много часове, ако имате голям набор от данни и/или сложна миграция. Въпреки това за сайтове, които помагам при управлението (които всички са вътрешни и обикновено се използват само през работно време в работни дни) този подход прави чудеса.
Бъдете внимателни, ако правите промените в копие на вашата основна база данни. Основният проблем тук е, че вашият сайт все още е активен и вероятно приема записи в базата данни. Какво се случва с данните, записани в главната база данни, докато сте заети с мигрирането на клонинга за по-късна употреба? Вашият сайт трябва или да не работи през цялото време, или временно да е поставен в състояние само за четене, в противен случай ще ги загубите.
Ако промените ви са обратно съвместими и имате уеб ферма, понякога можете да се разминете с актуализиране на сървъра на базата данни на живо производство (което според мен е неизбежно в повечето ситуации) и след това постепенно да актуализирате възлите във фермата, като ги извадите от балансиране на натоварването за кратък период от време. Това може да работи добре - обаче основният проблем тук е, ако възел, който вече е актуализиран, изпрати заявка за URL адрес, който не се поддържа от по-стар възел, ще получите неуспех, тъй като не можете да управлявате това на ниво балансиране на натоварването.
Виждал/чувал съм няколко други начина, които работят добре.
Първият е обвиване на всички промени в кода в заключване на функция, което след това може да се конфигурира по време на изпълнение чрез някои опции за конфигурация в целия сайт. Това по същество означава, че можете да пуснете код, където всичките ви промени са изключени, а след това, след като направите всички необходими актуализации на вашите сървъри, променяте опцията си за конфигурация, за да активирате функцията. Но това прави доста тежък код...
Второто позволява на кода да управлява миграцията. Чувал съм за сайтове, където промените в кода са написани по такъв начин, че да се справят с миграцията по време на изпълнение. Той е в състояние да открие версията на използваната схема и формата на данните, които е върнал - ако данните са от старата схема, той извършва миграцията на място, ако данните вече са от новата схема, не прави нищо . От естественото използване на сайта голяма част от вашите данни ще бъдат мигрирани от хора, които използват сайта, останалата част можете да направите със скрипт за миграция, когато пожелаете.
Но мисля, че в този момент Google става ваш приятел, защото както казах, решението е много специфично за контекста и се притеснявам, че този отговор ще започне да става безсмислен... Потърсете нещо като "разгръщане с нулево време на престой" и вие ще получа резултати като това с много идеи...
