Ik denk dat dit probleem uit twee delen bestaat.
De eerste is het beheren van het databaseschema en zijn wijzigingen. We doen dit met behulp van South, waarbij zowel de werkende modellen als de migratiebestanden in onze SCM-repository worden bewaard. Voor de veiligheid (of paranoia) nemen we een dump van de database voordat (en als we echt bang zijn, erna) migraties uitvoeren. Zuid voldoet tot nu toe aan al onze eisen.
Ten tweede is het implementeren van de schemawijziging die verder gaat dan alleen het uitvoeren van het door South gegenereerde migratiebestand. In mijn ervaring vereist een wijziging in de database normaal gesproken een wijziging in de geïmplementeerde code. Als je zelfs maar een kleine webfarm hebt, is het misschien niet triviaal om de geïmplementeerde code synchroon te houden met de huidige versie van je databaseschema - dit wordt nog erger als je de verschillende caching-lagen en het effect op een reeds actieve sitegebruiker in overweging neemt. Verschillende sites pakken dit probleem anders aan en ik denk niet dat er een pasklaar antwoord is.
Het oplossen van het tweede deel van dit probleem is niet per se eenvoudig. Ik geloof niet dat er een one-size-fits-all-aanpak is, en er is niet genoeg informatie over uw website en omgeving om een oplossing voor te stellen die het meest geschikt is voor uw situatie. Ik denk echter dat er een paar overwegingen zijn die in gedachten kunnen worden gehouden om de implementatie in de meeste situaties te begeleiden.
De hele site (webservers en database) offline halen is in sommige gevallen een optie. Het is zeker de meest ongecompliceerde manier om updates te beheren. Maar frequente downtime (zelfs wanneer gepland) kan een goede manier zijn om snel zaken te doen, maakt het vermoeiend om zelfs kleine codewijzigingen door te voeren en kan vele uren duren als u een grote dataset en/of complexe migratie heeft. Dat gezegd hebbende, voor sites die ik help beheren (die allemaal intern zijn en over het algemeen alleen tijdens werkuren op werkdagen worden gebruikt), doet deze aanpak wonderen.
Wees voorzichtig als u de wijzigingen aanbrengt op een kopie van uw hoofddatabase. Het grootste probleem hier is dat uw site nog steeds live is en vermoedelijk schrijfacties naar de database accepteert. Wat gebeurt er met gegevens die naar de hoofddatabase zijn geschreven terwijl u bezig bent met het migreren van de kloon voor later gebruik? Uw site moet ofwel de hele tijd offline zijn of tijdelijk in een alleen-lezen-status worden geplaatst, anders raakt u ze kwijt.
Als uw wijzigingen achterwaarts compatibel zijn en u een webfarm hebt, kunt u soms wegkomen door de databaseserver voor liveproductie bij te werken (wat volgens mij in de meeste situaties onvermijdelijk is) en vervolgens de knooppunten in de farm stapsgewijs bij te werken door ze uit de load balancer voor een korte periode. Dit kan goed werken - het grootste probleem hier is echter dat als een knooppunt dat al is bijgewerkt een verzoek om een url verzendt die niet wordt ondersteund door een ouder knooppunt, dit mislukt omdat u dat niet kunt beheren op het niveau van de load balancer.
Ik heb een aantal andere manieren gezien/gehoord die goed werken.
De eerste is het inpakken van alle codewijzigingen in een functievergrendeling die vervolgens tijdens runtime kan worden geconfigureerd via enkele configuratie-opties voor de hele site. Dit betekent in wezen dat u code kunt vrijgeven waar al uw wijzigingen zijn uitgeschakeld, en nadat u alle noodzakelijke updates op uw servers hebt aangebracht, wijzigt u uw configuratie-optie om de functie in te schakelen. Maar dit maakt nogal zware code...
De tweede is om de code de migratie te laten beheren. Ik heb gehoord van sites waar wijzigingen in de code zo zijn geschreven dat de migratie tijdens runtime wordt afgehandeld. Het kan de versie van het gebruikte schema detecteren en het formaat van de gegevens die het terugkreeg - als de gegevens van het oude schema zijn, voert het de migratie uit, als de gegevens al uit het nieuwe schema komen, doet het niets . Van natuurlijk sitegebruik wordt een groot deel van uw gegevens gemigreerd door mensen die de site gebruiken, de rest kunt u doen met een migratiescript wanneer u maar wilt.
Maar ik denk dat Google op dit punt je vriend wordt, want zoals ik al zei, de oplossing is erg contextspecifiek en ik ben bang dat dit antwoord zinloos begint te worden... Zoek naar zoiets als 'zero-downtime-implementatie' en je' krijg resultaten zoals dit met veel ideeën...