[StefanBergfeldt]

Jag har löst det så här när jag behövde göra en förändring av databasen under drift:

                    data.CommandText = "IF NOT EXISTS (SELECT * FROM sysobjects WHERE id = object_id(N'[dbo].[tblTradeShows]') AND OBJECTPROPERTY(id, N'IsUserTable') = 1) BEGIN CREATE TABLE [dbo].[tblTradeShows]([id] [int] IDENTITY(1,1) NOT NULL,[name] [nvarchar](50) NULL,[description] [nvarchar](1000) NULL,[startdate] [smalldatetime] NULL,[enddate] [smalldatetime] NULL,[url] [nvarchar](200) NULL,[representative] [nvarchar](500) NULL,[city] [nvarchar](50) NULL,[stand] [nvarchar](10) NULL,[products] [nvarchar](500) NULL) ON [PRIMARY] END";
                    data.ExecuteNonQuery();

[dotvoid]

Att uppdatera kod är ju kanske inte så svårt. Det svåra att ju just hantera ändringar i datastrukturer, migrering av genererad data som t ex bilder som ska skalas om osv. Tar proceduren lång tid så kan det vara en bra idé att lägga uppdateringen under subdomän och sen peka om som en del påpekat.

[Jine]

Versionshantering och då även av databasen (YAML-filer t.ex.) is the way to go.
Större uppdateringar / ombyggnad görs helst på egen subdomän & manuell ompekning.


EDIT:
Större projekten jag har varit iblandade i har det funnits ett par utvecklingsversioner, en/flera QA-versioner samt en prodmiljö.

Devversionerna är dev-kod men med dev-specifik data (ej proddata).
QA-versioner består av både QA-data (kunds test av nya funktioner eller dylikt, även här man kan sköta omskalning av bilder och liknande "större" uppdateringar) samt en skarp QA miljö med senaste data från prod - tillsammans med kod och uppdateringar ifrån QA-versionen innan.

När skarpa QA-versionen är godkänd av kund så pushar man hela QA till PROD, och då är det även garanterat att fungera då det blivit validerat i 2-3 steg.