Het inzetten van SQL Server-databases van Test to Live

stemmen
24

Ik ben benieuwd hoe jullie beheren inzet van een database tussen 2 SQL-servers, met name SQL Server 2005. Nu is er een ontwikkeling en een live één. Aangezien dit onderdeel van een buildscript zou moeten zijn (standaard Windows-batch, zelfs niet met de huidige complexiteit van deze scripts, zou ik overschakelen naar PowerShell of wat later), moet u Enterprise Manager / Management Studio Express niet mee.

Wil je gewoon kopiëren van de .mdf File en bevestig deze? Ik ben altijd een beetje voorzichtig bij het werken met binaire gegevens, omdat dit lijkt een compatibiliteit probleem (hoewel de ontwikkeling en wonen moeten dezelfde versie van de server draaien op alle tijd).

Of - gezien het gebrek aan Leg CREATE TABLE in T-SQL - heb je iets dat een bestaande database exporteert naar SQL-scripts die u kunt uitvoeren op het doel server te doen? Zo ja, is er een tool die automatisch een bepaalde database kan dumpen in SQL-query's en dat loopt uit de command line? (Nogmaals, Enterprise Manager / Management Studio Express tellen niet mee).

En tot slot - gezien het feit dat de live-database al gegevens bevat, de inzet mag niet inhouden het creëren van alle tabellen, maar het controleren van de verschillen in structuur en ALTER TABLE de live degenen in plaats daarvan, die ook de verificatie van gegevens / conversie nodig kunt hebben bij bestaande velden te wijzigen.

Nu, ik hoor veel goede dingen over de Rode Poort producten, maar voor hobby-projecten, de prijs is een beetje steil.

Dus, wat gebruikt u om automatisch te implementeren SQL Server-databases van Test te leven?

De vraag is gesteld op 03/08/2008 om 00:30
bron van user
In andere talen...                            


14 antwoorden

stemmen
14

Voor mijn projecten afwisselen ik tussen SQL Vergelijk van Red Gate en de Database Publishing Wizard van Microsoft waar u gratis kunt downloaden hier .

De wizard is niet zo glad als SQL Vergelijk of SQL-gegevens te vergelijken, maar het doet de truc. Een probleem is dat de scripts die het genereert sommige herschikken en / of bewerken kan het nodig zijn om te stromen in een schot.

Aan de kant, het kan je schema en de gegevens die is niet slecht voor een gratis tool te verplaatsen.

antwoordde op 03/08/2008 om 00:40
bron van user

stemmen
19

Ik heb genomen om de hand-codering al mijn DDL (creëert / wijzigen / verwijderen) verklaringen, toe te voegen aan mijn .sln als tekstbestanden, en het gebruik van de normale versies (met behulp van subversie, maar een eventuele herziening controle zou moeten werken). Op deze manier heb ik niet alleen krijgt het voordeel van versiebeheer, maar het updaten van live vanuit dev / fase is hetzelfde proces voor de code en database --tags, takken en ga zo maar door werk allemaal hetzelfde.

Anders ben ik het eens Redgate is duur als je niet beschikt over een bedrijf het voor u te kopen hebben. Als je een bedrijf kunt krijgen om het wel te kopen voor u, het is echt de moeite waard!

antwoordde op 03/08/2008 om 00:51
bron van user

stemmen
3

Als je een bedrijf te kopen, Toad van Quest Software heeft dit soort functionaliteit ingebouwd. Het is eigenlijk een twee-klik operatie om twee schema's te vergelijken en het genereren van een sync-script van de ene naar de andere.

Ze hebben edities van het grootste deel van de populaire databases, waaronder natuurlijk SQL Server.

antwoordde op 03/08/2008 om 01:22
bron van user

stemmen
4

Ik werken op dezelfde manier Karl doet, door het houden van al mijn SQL-scripts voor het maken en wijzigen van tabellen in een tekstbestand dat ik in de bron controle te houden. In feite, om het probleem van het hebben van een script onderzoekt de live-databank om te bepalen wat Alters te lopen te vermijden, werk ik meestal als volgt:

  • Op de eerste versie, plaats ik alles tijdens de test in een SQL-script, en behandelen alle tabellen als een CREATE. Dat betekent dat ik uiteindelijk laten vallen en readding tafels veel tijdens het testen, maar dat is geen big deal vroeg in het project (aangezien ik meestal het hacken van de gegevens die ik gebruik op dat moment toch).
  • Op alle latere versies, heb ik twee dingen doen: ik een nieuwe tekst bestand om de upgrade SQL-scripts, die net de verandert voor die versie bevatten houden te maken. En ik breng de wijzigingen aan het origineel, een frisse databank script ook. Op deze manier een upgrade draait gewoon de upgrade script, maar als we naar de DB opnieuw hoeven we niet tot 100 scripts om er te komen.
  • Afhankelijk van hoe ik het inzetten van de DB verandert, zal ik ook doorgaans op een versie tafel in de DB dat de versie van de DB houdt. Dan, in plaats van om het even welke menselijke beslissingen over welke scripts worden uitgevoerd, wat code die ik het creëren / upgrade scripts loopt maakt gebruik van de versie om te bepalen wat te lopen.

Het enige wat dit niet zal doen, is helpen als een deel van wat je beweegt van test tot productie data, maar als je wilt structuur beheren en niet te betalen voor een mooie, maar dure DB beheerpakket, is echt niet erg moeilijk. Ik heb ook het is een vrij goede manier om mentale bijhouden van uw DB gevonden.

antwoordde op 03/08/2008 om 01:37
bron van user

stemmen
2

Ik ben het eens dat het scripten alles is de beste manier om te gaan en is wat ik voorsta op het werk. Je moet script alles van DB en het maken van objecten aan het vullen van uw opzoektabellen.

Alles wat je doet in UI alleen zal niet vertalen (vooral voor veranderingen ... niet zo veel voor de eerste implementaties) en zal eindigen die een tools zoals wat Redgate biedt.

antwoordde op 03/08/2008 om 02:38
bron van user

stemmen
3

Met behulp van SMO / DMO, is het niet te moeilijk om een ​​script van uw schema te genereren. Data is een beetje meer plezier, maar nog steeds goed te doen.

In het algemeen, neem ik "Script It" benadering, maar wilt u misschien iets langs deze lijnen te overwegen:

  • Onderscheid tussen ontwikkeling en Staging, zodanig dat je kunt ontwikkelen met een subset van data ... dit zou ik een tool om gewoon naar beneden trekken deel van de productie van gegevens, of valse gegevens waar de veiligheid betreft het genereren van maken.
  • Voor teamontwikkeling, zal elke verandering aan de database moeten worden gecoördineerd onder uw teamleden. Schema en de gegevens veranderingen kunnen worden vermengd, maar een enkel script moet een bepaalde functie in te schakelen. Zodra u alle functies zijn klaar, je bundelen deze in één SQL-bestand en voer dat tegen een herstel van de productie.
  • Zodra je staging aanvaarding heeft ontruimd je de enkele SQL-bestand opnieuw uitvoeren op de productie machine.

Ik heb gebruik gemaakt van de Rode Poort gereedschappen en ze zijn grote hulpmiddelen, maar als je niet kunt veroorloven, het opbouwen van de instrumenten en deze manier van werken is niet al te ver van het ideaal.

antwoordde op 04/08/2008 om 18:38
bron van user

stemmen
6

Net als Rob Allen, ik gebruik SQL Vergelijk / Data Vergelijken op Redgate. Ik gebruik ook de database publishing tovenaar door Microsoft. Ik heb ook een console app die ik geschreven in C #, dat een sql script draait en draait het op een server. Op deze manier kun je grote scripts met 'GO' commando's in het van een opdrachtregel of in een batch script uit te voeren.

Ik gebruik Microsoft.SqlServer.BatchParser.dll en Microsoft.SqlServer.ConnectionInfo.dll bibliotheken in de console applicatie.

antwoordde op 04/08/2008 om 19:00
bron van user

stemmen
2

Ik ga akkoord met het houden van alles in de bron controle en handmatig alle wijzigingen scripts. Wijzigingen in het schema voor een single release gaan in een script bestand speciaal voor die release. Alle ontwerp en bouw, uitzicht, etc moet gaan in afzonderlijke bestanden en behandeld, net als .cs of .aspx zover bron controle gaat. Ik gebruik een powershellmanuscript tot één groot .sql bestand te genereren voor het bijwerken van de programmeerbaarheid spullen.

Ik hou niet van het automatiseren van de toepassing van het schema veranderingen, zoals nieuwe tabellen, nieuwe kolommen, enz. Bij het doen van een productie-release, ik willen gaan door de verandering scriptopdracht door opdracht om ervoor te zorgen dat een ieder werkt zoals verwacht. Er is niets erger dan het draaien van een grote verandering script op de productie en het krijgen van fouten maakt omdat u een aantal kleine details die niet zelf in ontwikkeling heeft presenteren aanvragen.

Ik heb ook geleerd dat indexen moeten worden behandeld, net als code-bestanden en in source control zetten.

En je moet zeker meer dan 2 databases - dev en leven. Je moet een dev database die iedereen gebruikt voor de dagelijkse dev taken. Dan is een enscenering database die productie nabootst en wordt gebruikt om uw integratie testen te doen. Dan misschien een complete recente kopie van de productie (hersteld van een volledige back-up), als dat mogelijk is, zodat uw laatste ronde van de installatie testen gaat tegen iets dat zo dicht mogelijk bij het echte werk mogelijk te maken.

antwoordde op 13/08/2008 om 16:41
bron van user

stemmen
7

Weet Microsoft's oplossing voor het probleem niet vergeten Visual Studio 2008 Database Edition . Bevat tools voor het implementeren van wijzigingen in databases, het produceren van een diff tussen databases voor schema en / of wijzigingen in gegevens, unit testen, testgegevens generatie.

Het is vrij duur, maar ik gebruikte het proces editie voor een tijdje en dacht dat het was briljant. Het maakt de database zo gemakkelijk om mee te werken als elk ander stuk van de code.

antwoordde op 18/08/2008 om 11:47
bron van user

stemmen
1

Ik doe al mijn maken van een database als DDL en wikkel dat DDL in een schema handhaving klasse. Ik kan verschillende dingen aan de DDL in de eerste plaats te maken te doen maar fundamenteel Ik doe al het schema onderhoudsjongen stuurde in de code. Dit betekent ook dat als men nodig heeft om niet-DDL dingen die niet goed in kaart te SQL doen kun je procedurele logica schrijven en voer het uit tussen brokken van DDL / DML.

Mijn dbs hebben dan een tabel die de huidige versie definieert zodat men een relatief eenvoudige reeks tests kan programmeren:

  1. Heeft de DB bestaan? Als het niet te creëren.
  2. Is de DB de huidige versie? Zo niet dan lopen de methodes, in volgorde, dat het schema te brengen up to date (wilt u misschien aan de gebruiker gevraagd om te bevestigen en - idealiter - doen backups op dit punt).

Voor een enkele gebruiker app ik dit run gewoon op zijn plaats, voor een web app we op dit moment aan de gebruiker uit te sluiten als de versies niet overeenkomen en hebben een stand-alone schema maint app we lopen. Voor multi-user het zal afhangen van de specifieke omgeving.

Het voordeel? Nou, ik heb een zeer hoge mate van vertrouwen dat het schema voor de apps die deze methode gebruiken, is consistent in alle exemplaren van deze toepassingen. Het is niet perfect, er zijn problemen, maar het werkt ...

Er zijn een aantal zaken bij het ontwikkelen in teamverband, maar dat is min of meer een gegeven toch!

Murph

antwoordde op 26/08/2008 om 16:38
bron van user

stemmen
2

Ik gebruik Subsonic's migraties mechanisme dus ik heb gewoon een dll met lessen in squential opdat 2 methodes, op en neer te hebben. Er is een continue integratie / build script haak in Nant, zodat ik de opwaardering van mijn database kan automatiseren.

Het is niet de beste thign in de wereld, maar het is beter dan het schrijven van DDL.

antwoordde op 26/08/2008 om 18:39
bron van user

stemmen
2

Redgate SqlCompare is een manier om te gaan in mijn mening. Wij doen DB inzet op een regelmatige basis en sinds ik begon met behulp van dat hulpmiddel dat ik heb nooit meer achterom gekeken. Zeer intuïtieve interface en bespaart een hoop tijd in het einde.

De Pro-versie zorgt voor scripting voor de bron controle integratie ook nemen.

antwoordde op 28/08/2008 om 01:22
bron van user

stemmen
1

Ik ben momenteel bezig met hetzelfde voor jou. Niet alleen het inzetten van SQL Server-databases van test om te leven, maar ook het hele proces van Local -> Integratie -> Test -> Production. Dus wat kan me gemakkelijk elke dag te maken is dat ik NAnt taak Red-Gate SQL vergelijken . Ik ben niet voor Redgate, maar ik moet zeggen dat het een goede keuze.

antwoordde op 27/11/2008 om 04:15
bron van user

stemmen
2

Ik blijf ook scripts voor al mijn objecten en gegevens. Voor het implementeren schreef ik dit gratis hulpprogramma - http://www.sqldart.com . Het laat je de volgorde van je script bestanden en zal de hele boel binnen een transactie uit te voeren.

antwoordde op 08/06/2010 om 22:33
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more