![]() |
Jag har löst det så här när jag behövde göra en förändring av databasen under drift:
Kod:
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"; |
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.
|
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. |
Alla tider är GMT +2. Klockan är nu 04:44. |
Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson