Jeg tror, der er to dele af dette problem.
Først er det at administrere databaseskemaet og dets ændringer. Vi gør dette ved at bruge South og beholder både arbejdsmodellerne og migrationsfilerne i vores SCM-lager. For en sikkerheds skyld (eller paranoia), tager vi et dump af databasen før (og hvis vi er virkelig bange, efter) at køre nogen migreringer. Syd har hidtil været tilstrækkelig til alle vores krav.
For det andet er implementering af skemaændringen, som går ud over blot at køre migreringsfilen, der er genereret af South. Efter min erfaring kræver en ændring af databasen normalt en ændring af implementeret kode. Hvis du selv har en lille webfarm, er det måske ikke trivielt at holde den installerede kode synkroniseret med den aktuelle version af dit databaseskema - dette bliver værre, hvis du overvejer de forskellige cachinglag og effekt for en allerede aktiv bruger af webstedet. Forskellige sider håndterer dette problem forskelligt, og jeg tror ikke, der er et ensartet svar.
At løse den anden del af dette problem er ikke nødvendigvis ligetil. Jeg tror ikke på, at der er en ensartet tilgang, og der er ikke nok information om dit websted og miljø til at foreslå en løsning, der ville være bedst egnet til din situation. Jeg tror dog, at der er et par overvejelser, der kan huskes for at hjælpe med at guide implementeringen i de fleste situationer.
At tage hele webstedet (webservere og database) offline er en mulighed i nogle tilfælde. Det er bestemt den mest ligetil måde at administrere opdateringer på. Men hyppig nedetid (selv når det er planlagt) kan være en god måde at arbejde hurtigt på, gør det trættende at implementere selv små kodeændringer og kan tage mange timer, hvis du har et stort datasæt og/eller kompleks migrering. Når det er sagt, gør denne tilgang underværker for websteder, jeg hjælper med at administrere (som alle er interne og generelt kun bruges i arbejdstiden på hverdage).
Vær forsigtig, hvis du foretager ændringerne på en kopi af din masterdatabase. Hovedproblemet her er, at dit websted stadig er live og formodentlig accepterer skrivninger til databasen. Hvad sker der med data skrevet til masterdatabasen, mens du har travlt med at migrere klonen til senere brug? Dit websted skal enten være nede hele tiden eller midlertidigt have en skrivebeskyttet tilstand, ellers mister du dem.
Hvis dine ændringer er bagudkompatible, og du har en webfarm, kan du nogle gange slippe af sted med at opdatere liveproduktionsdatabaseserveren (hvilket jeg tror er uundgåeligt i de fleste situationer) og derefter gradvist opdatere noder i farmen ved at tage dem ud af load balancer i en kort periode. Dette kan fungere ok - men hovedproblemet her er, hvis en node, der allerede er blevet opdateret, sender en anmodning om en url, som ikke understøttes af en ældre node, vil du få fejl, da du ikke kan håndtere det på load balancer-niveauet.
Jeg har set/hørt et par andre måder, der fungerer godt.
Den første er at pakke alle kodeændringer i en funktionslås, som derefter kan konfigureres under kørsel gennem nogle konfigurationsmuligheder for hele webstedet. Dette betyder i bund og grund, at du kan frigive kode, hvor alle dine ændringer er slået fra, og så efter du har foretaget alle de nødvendige opdateringer til dine servere, ændrer du din konfigurationsindstilling for at aktivere funktionen. Men dette giver ret tung kode...
Den anden er at lade koden styre migreringen. Jeg har hørt om websteder, hvor ændringer af koden er skrevet på en sådan måde, at den håndterer migreringen under kørsel. Det er i stand til at detektere versionen af skemaet, der bruges, og formatet af de data, det fik tilbage - hvis dataene er fra det gamle skema, udfører det migreringen på plads, hvis dataene allerede er fra det nye skema, gør det ingenting . Fra naturlig brug af webstedet vil en stor del af dine data blive migreret af folk, der bruger webstedet, resten kan du gøre med et migreringsscript, når du vil.
Men jeg tror på dette tidspunkt Google bliver din ven, for som jeg siger, er løsningen meget kontekstspecifik, og jeg er bekymret for, at dette svar vil begynde at blive meningsløst... Søg efter noget som "nul nedetid deployment", og du' vil få resultater såsom dette med masser af ideer...