Distribuere SQL Server databaser fra Test til Live

For mine prosjekter jeg veksle mellom SQL Sammenlign fra Red Gate og Database Publishing Wizard fra Microsoft som du kan laste ned gratis her .

The Wizard er ikke så glatt som SQL Sammenlign eller SQL Data Sammenlign men det gjør susen. Ett problem er at skriptene den genererer kan trenge noen omorganisere og / eller redigering til å flyte i ett skudd.

På den positive siden kan det flytte skjema og data som ikke er dårlig for et gratis verktøy.

Hvis du har et selskap å kjøpe det, Toad fra Quest Software har denne type funksjonalitet bygget i. Det er i utgangspunktet en to-klikk operasjon for å sammenligne to skjemaer og generere en synkronisering skript fra den ene til den andre.

De har utgaver for de fleste av de populære databaser, inkludert selvfølgelig SQL Server.

Jeg jobber på samme måte Karl gjør, ved å holde alle mine SQL-skript for å lage og endre tabeller i en tekstfil som jeg holder i kildekontroll. Faktisk, for å unngå problemet med å måtte ha et skript undersøke live databasen for å finne ut hva som endrer til å kjøre, jeg vanligvis jobber som dette:

• På den første versjonen, legger jeg alt under testing i en SQL-script, og behandle alle tabeller som en CREATE. Dette betyr at jeg ender opp med å slippe og readding tabeller mye under testing, men det er ikke en stor avtale tidlig inn i prosjektet (siden jeg vanligvis hacking dataene jeg bruker på det tidspunktet uansett).
• På alle senere versjoner, jeg gjør to ting: jeg lage en ny tekstfil å holde oppgraderingen SQL-skript, som inneholder bare de endrer for den versjonen. Og jeg gjøre endringer til det opprinnelige, opprette en ny database script også. På denne måten en oppgradering bare kjører oppgraderingen manuset, men hvis vi må gjenskape DB vi ikke trenger å løpe 100-skript for å komme dit.
• Avhengig av hvordan jeg distribusjon DB endringer, vil jeg også gjerne sette en versjon bord i DB som holder versjonen av DB. Så i stedet for å gjøre noen menneskelige beslutninger om hvilke skript for å kjøre, uansett code Jeg har kjøre CREATE / oppgradering skript bruker versjonen for å finne ut hva de skal kjøre.

Den ene tingen dette ikke vil gjøre er å hjelpe om en del av det du flytter fra test til produksjon er data, men hvis du ønsker å administrere struktur og ikke betale for en hyggelig, men dyrt DB styring pakken, er egentlig ikke så veldig vanskelig. Jeg har også funnet det er en ganske god måte å holde mental styr på DB.

Jeg er enig i at skripting alt er den beste veien å gå, og er hva jeg argumentere på jobb. Du bør script alt fra DB og objekt skapelse til å fylle dine oppslagstabeller.

Alt du gjør i UI bare vil ikke oversette (spesielt for endringer ... ikke så mye for første distribusjoner) og vil ende opp som krever et verktøy som hva Redgate tilbyr.

Ved hjelp av SMO / DMO, er det ikke så vanskelig å lage et manus av skjema. Data er et litt mer moro, men likevel gjennomførbart.

Vanligvis tar jeg "Script It" tilnærming, men du bør kanskje vurdere noe langs disse linjene:

• Skille mellom utvikling og stillas, slik at du kan utvikle med en undergruppe av data ... dette jeg ville lage et verktøy for å bare trekke ned noen produksjonsdata, eller generere falske data der sikkerhet er bekymret.
• For teamutvikling, vil hver endring til databasen må koordineres blant gruppemedlemmene. Skjema og data endringer kan være blandet, men et enkelt script bør aktivere en gitt funksjon. Når alle funksjoner er klar, pakke du disse opp i en enkelt SQL-fil og kjøre den mot en gjenoppretting av produksjonen.
• Når iscenesettelse har ryddet aksept, du kjører enkelt SQL-filen på nytt på produksjonsmaskinen.

Jeg har brukt Red Gate verktøy og de er gode verktøy, men hvis du ikke har råd til det, bygge verktøy og jobbe på denne måten er ikke så langt fra ideelt.

Som Rob Allen, jeg bruker SQL Sammenlign / Data Sammenlign av Redgate. Jeg bruker også Database publiseringsveiviseren Microsoft. Jeg har også en konsoll app jeg skrev i C # som tar en sql skript og kjører den på en server. På denne måten kan du kjøre store skript med 'go' kommandoer i den fra en kommandolinje eller i en batch script.

Jeg bruker Microsoft.SqlServer.BatchParser.dll og Microsoft.SqlServer.ConnectionInfo.dll bibliotekene i konsollen søknaden.

Jeg er enig med å holde alt i kildekontroll og manuelt skripting alle endringer. Endringer i skjemaet for en enkelt utgivelse gå inn i et script fil som er opprettet spesielt for at utgivelsen. Alle lagrede procs, synspunkter, etc bør gå inn i enkeltfiler og behandlet akkurat som .CS eller aspx så langt kildekontroll går. Jeg bruker en Powershell script for å generere en stor sql fil for oppdatering av programmering ting.

Jeg liker ikke å automatisere anvendelsen av skjema endringer, som nye tabeller, nye søyler, etc. Når du gjør en produksjon utgivelse, jeg liker å gå gjennom endringen skriptet kommandoen ved kommando for å sørge for at hver og en fungerer som forventet. Det er ingenting verre enn å kjøre en stor endring skript på produksjon og får feil fordi du glemte noen små detaljer som ikke presentere seg selv i utvikling.

Jeg har også lært at indeksene trenger å bli behandlet på samme måte som koden filer og sette inn kildekontroll.

Og du bør definitivt ha mer enn 2 databaser - dev og leve. Du bør ha en dev database som alle bruker for daglige dev oppgaver. Deretter en iscenesettelse database som etterligner produksjon og brukes til å gjøre din integrasjonstesting. Så kanskje en komplett fersk kopi av produksjon (gjenopprettet fra en full backup), hvis det er mulig, slik at siste runden av installasjonstesting går mot noe som er så nær the real thing som mulig.

Ikke glem Microsofts løsning på problemet: Visual Studio 2008 Database Edition . Omfatter verktøy for distribusjon av endringer i databaser, å produsere en diff mellom databaser for skjema og / eller dataendringer, enhetstester testdatagenerering.

Det er ganske dyrt, men jeg brukte prøveversjon for en stund og syntes det var strålende. Det gjør databasen så lett å jobbe med som en hvilken som helst annen del av koden.

Jeg gjør alle mine database som DDL og deretter vikle at DDL inn et skjema proof klasse. Jeg kan gjøre forskjellige ting for å skape den DDL i første omgang, men fundamentalt jeg gjøre alt skjemaet maint i kode. Dette betyr også at hvis man trenger å gjøre ikke-DDL ting som ikke kart godt til SQL kan du skrive prosessuelle logikk og kjøre den mellom klumper av DDL / DML.

Mine DBS da ha en tabell som forteller hvilken versjon slik at man kan kode en relativt grei sett av tester:

1. Eksisterer DB? Hvis ikke lage den.
2. Er DB gjeldende versjon? Hvis ikke så kjører metodene, i rekkefølge, som bringer skjemaet oppdatert (det kan være lurt å be brukeren om å bekrefte og - ideelt sett - gjør backup på dette punktet).

For en enkelt bruker app jeg bare kjøre dette på plass, for en web-app vi i dag for å låse brukeren ut om versjonene ikke samsvarer, og har en frittstående skjema maint app vi kjører. For multi-bruker vil det avhenge av hvilket miljø.

Fordelen? Vel jeg har en veldig høy grad av tillit til at skjemaet for apps som bruker denne metoden er konsistent på tvers av alle tilfeller av disse programmene. Det er ikke perfekt, det er problemer, men det fungerer ...

Det er noen problemer når du utvikler i et team miljø, men det er mer eller mindre en gitt uansett!

Murph

Jeg bruker Subsonic vandringer mekanisme slik at jeg bare har en dll med klasser i squential orden som har 2 metoder, opp og ned. Det er en kontinuerlig integrasjon / build script kroken inn nant, slik at jeg kan automatisere oppgradering av min database.

Det er ikke den beste thign i verden, men det slår skriver DDL.

Redgate SqlCompare er en vei å gå etter min mening. Vi gjør DB utplassering på en jevnlig basis, og siden jeg begynte å bruke det verktøyet jeg har aldri sett seg tilbake. Svært intuitivt grensesnitt og sparer mye tid på slutten.

Pro-versjonen vil ta seg av scripting for kildekontroll integrering også.

Jeg jobber for tiden det samme til deg. Ikke bare distribuerer SQL Server databaser fra test for å leve, men inkluderer også hele prosessen fra Lokal -> Integrasjon -> Test -> Produksjon. Så hva kan gjøre meg lett hver dag er jeg gjøre Nant oppgaven med Red-Gate SQL Sammenlign . Jeg jobber ikke for Redgate men jeg må si det er godt valg.

Jeg også opprettholde skript for alle mine objekter og data. For distribusjon skrev jeg dette gratis verktøy - http://www.sqldart.com . Det vil la deg omorganisere skriptfiler og vil kjøre mye i en transaksjon.