Jag tror att det finns två delar av detta problem.
Det första är att hantera databasschemat och dess ändringar. Vi gör detta med South, och behåller både arbetsmodellerna och migreringsfilerna i vårt SCM-förråd. För säkerhets skull (eller paranoia) tar vi en dumpning av databasen innan (och om vi är riktigt rädda, efter) kör några migrering. South har varit tillräcklig för alla våra krav hittills.
För det andra är att distribuera schemaändringen som går utöver att bara köra migreringsfilen som genereras av South. Enligt min erfarenhet kräver en ändring av databasen normalt en ändring av distribuerad kod. Om du till och med har en liten webbfarm, kanske det inte är trivialt att hålla den distribuerade koden synkroniserad med den aktuella versionen av ditt databasschema - detta blir värre om du tar hänsyn till de olika cachinglagren och effekten för en redan aktiv webbplatsanvändare. Olika sajter hanterar det här problemet på olika sätt, och jag tror inte att det finns något som passar alla.
Att lösa den andra delen av detta problem är inte nödvändigtvis okomplicerat. Jag tror inte att det finns ett tillvägagångssätt som passar alla, och det finns inte tillräckligt med information om din webbplats och miljö för att föreslå en lösning som skulle vara mest lämplig för din situation. Jag tror dock att det finns några överväganden som kan komma ihåg för att hjälpa till att vägleda implementeringen i de flesta situationer.
Att ta hela webbplatsen (webbservrar och databas) offline är ett alternativ i vissa fall. Det är verkligen det enklaste sättet att hantera uppdateringar. Men frekventa driftstopp (även när det är planerat) kan vara ett bra sätt att göra vår verksamhet snabbt, gör det tröttsamt att implementera även små kodändringar och kan ta många timmar om du har en stor datamängd och/eller komplex migrering. Som sagt, för webbplatser jag hjälper till att hantera (som alla är interna och vanligtvis endast används under arbetstid på arbetsdagar) gör detta tillvägagångssätt underverk.
Var försiktig om du gör ändringarna på en kopia av din huvuddatabas. Det största problemet här är att din webbplats fortfarande är aktiv och förmodligen accepterar skrivningar till databasen. Vad händer med data som skrivs till huvuddatabasen när du är upptagen med att migrera klonen för senare användning? Din webbplats måste antingen vara nere hela tiden eller vara tillfälligt skrivskyddad, annars kommer du att förlora dem.
Om dina ändringar är bakåtkompatibla och du har en webbfarm, kan du ibland komma undan med att uppdatera liveproduktionsdatabasservern (vilket jag tror är oundvikligt i de flesta situationer) och sedan stegvis uppdatera noder i farmen genom att ta ut dem från lastbalanserare under en kort period. Det här kan fungera okej - men huvudproblemet här är om en nod som redan har uppdaterats skickar en begäran om en url som inte stöds av en äldre nod så kommer du att misslyckas eftersom du inte kan hantera det på belastningsbalanseringsnivån.
Jag har sett/hört att ett par andra sätt fungerar bra.
Den första är att slå in alla kodändringar i ett funktionslås som sedan kan konfigureras under körning genom vissa konfigurationsalternativ för hela webbplatsen. Detta innebär i huvudsak att du kan släppa kod där alla dina ändringar är avstängda, och sedan efter att du har gjort alla nödvändiga uppdateringar på dina servrar ändrar du ditt konfigurationsalternativ för att aktivera funktionen. Men detta gör ganska tung kod...
Den andra är att låta koden hantera migreringen. Jag har hört talas om sajter där ändringar i koden är skriven på ett sådant sätt att den hanterar migreringen vid körning. Den kan upptäcka versionen av schemat som används och formatet på data som den fick tillbaka - om data är från det gamla schemat gör det migreringen på plats, om data redan är från det nya schemat gör det ingenting . Från naturlig webbplatsanvändning kommer en stor del av din data att migreras av personer som använder webbplatsen, resten kan du göra med ett migreringsskript när du vill.
Men jag tror att Google vid det här laget blir din vän, för som jag sa, lösningen är väldigt kontextspecifik och jag är orolig att det här svaret kommer att börja bli meningslöst... Sök efter något som "zero down time deployment" och du kommer att få resultat som detta med massor av idéer...