Automatisk implementering og version af din SQL Server-database med SSDT

Af Keith Schreiner

Jeg har læst og fået at vide mange gange, at det er en "bedste praksis" at styre versionen af ​​min database. For at gøre det har jeg prøvet tidligere værktøjer fra Microsoft, RedGate og andre, men ingen har virkelig fanget noget for mig. Jeg har også ikke lide den “rodede” proces med at skulle administrere flere SQL-scripts, når jeg opgraderer en produktionsdatabase. Men Microsofts seneste (gratis) værktøj, SQL Server Data Tools (SSDT), har gendannet min tro på, at versionering af min database ikke burde være en frygtelig opgave.

Definere

SSDT tilføjer en masse funktionalitet til Visual Studio til at arbejde med SQL Server-databaser. De vigtigste ting, det tilføjer, er et "SQL Server Database Project" og noget, der kaldes en DACPAC (Data-Tier Application Package). En DACPAC er en enkelt installationsfil, der indeholder hele dit databaseskema og nogle relaterede SQL-filer (som opslagsdata), dybest set alt for at implementere en ny version af din database i en fil. Det ligner en BACPAK, som er en DACPAC plus alle data i hver tabel (som en standard database-sikkerhedskopi). Men før vi snakker mere om DACPAC's, lad os diskutere, hvad SSDT tilføjer med sit SQL Server Database Project.

Udvikle

I Visual Studio har du, efter at du har oprettet et nyt SQL Server-databaseprojekt, en mulighed for at importere en database, som pænt opretter SQL-scripts af alle dine databaseobjekter (tabeller, visninger, lagrede procedurer og mere). Det næste trin, som jeg gør, er at oprette en “Data” -mappe og tilføje et SQL-script efter implementering for at udfylde opslagsdataene og eventuelt oprette nogle testdata.

I et databaseprojekt kan du kun have en postdistribution og en forudinstallationsfil, så det er en god praksis at bruge SQLCMD-syntaks til at inkludere andre filer i din hovedfil til at hjælpe med organisering og vedligeholdelse. Når du opretter disse SQL-scripts eller redigerer SQL til tabellerne eller lagrede procedurer, vil du begynde at bemærke alle de andre ting, SSDT tilføjer til Visual Studio: SQL IntelliSense, SQL-kodenavigation, en SQL Server Object Explorer, debugging af SP'er, enhedstest for SP'er, en visuel tabeldesigner, et skema Sammenlign værktøj, et Data Sammenlign værktøj og mere. Alle disse funktioner får databaseudvikling og vedligeholdelse til at føles naturlig i Visual Studio.

Indsætte

Når du har foretaget din databaseændringer, er det næste trin at implementere dem, og SSDT giver flere måder. Den første måde er "Publicer", som fungerer godt, hvis du har en direkte forbindelse til databasen fra din Visual Studio-maskine (som til din lokale eller "Dev" -database). Højreklik på databaseprojektet og vælg "Publicer ...", som åbner en dialog for at gemme en profil. Når en profil er gemt som en del af dit projekt, kan du bare dobbeltklikke på den for direkte at offentliggøre dit databaseprojekt i databasen eller bare for at generere et script til de ændringer, den vil køre.

Den anden måde er at bruge en DACPAC, som vi talte om ovenfor, når udviklere ikke har adgang til måldatabasen (som for Produktion). For at oprette en DACPAC skal du bare højreklikke på databaseprojektet og vælge "Snapshot Project", som derefter opretter en DACPAC i dit projekt "Snapshots" -mappe. Derefter har du flere muligheder for at implementere denne DACPAC. Hvis du har en DBA, der altid anvender databaseopdateringer, kan du give ham eller hende DACPAC til at anvende ved hjælp af SSMS (SQL Server Management Studio), som har en indbygget “Upgrade Data-tier Application” -opgave; den bruger en guide til at hjælpe med at anvende ændringerne (og tillader, at alle ændringer gennemgås for problemer, f.eks. mulig datatab, på hvert trin).

En anden DACPAC-implementeringsmulighed er at kalde “SqlPackage.exe” (med kommandolinjeparametre) eller at skrive nogle C # -koder (fra Microsoft.SqlServer.Dac-navneområdet), der udsætter selve DACPAC. Dette gør installationen automatisk, næsten til et punkt, hvor du ikke behøver at bekymre dig om det.

Prøve fra det virkelige liv

På det første projekt, jeg brugte SSDT (et nyt MVC-websted), stødte jeg på tre problemer med SSDT. Dette er, hvordan jeg løste dem og forenklet databasens udvikling kraftigt. Først ønskede jeg kun automatisk at implementere DACPAC på webstedets Application_Start, når databasen faktisk var ændret. Så jeg tilføjede et stykke logik for at se efter et nyt versionnummer i den nyeste DACPAC, før jeg anvendte det. Versionsnummeret for DACPAC indstilles i databaseprojektets egenskaber -> Projektindstillinger -> Egenskaber-dialogboksen, og den aktuelle databaseversion gemmes i systemtabellen, msdb.dbo.sysdac_instances_internal . At have dette version nummer ikke kun gjort hurtigere opstart, det gjorde andre opmærksomme på en "databaseversion".

Det andet problem var, hvordan man opretter databaseprojektet til at inkludere “testdata” til Dev-databasen, men ekskluderer det for produktion. Dette blev opnået ved at oprette et andet databaseprojekt (DatabaseAndTestData), der havde en "databasehenvisning" til det første projekt. I dette andet projekt inkluderer dets script efter implementering det første projekts script efter implementering og derefter alle testdata. Jeg brugte det første projekt (uden testdata) til at oprette DACPAC til produktion og offentliggjorde derefter lige det andet projekt (med testdata) direkte til Dev.

Endelig klagede nogle udviklere over, at de, efter at have opdateret skemaet eller opslagsdata, stadig har flere kedelige og gentagne opgaver for at få DACPAC klar til at blive implementeret. For at løse dette skrev jeg et simpelt program (UpdateDatabaseVersion.exe), der kan kaldes fra “Solution Explorer” i databaseprojektet ved hjælp af Visual Studio-udvidelsen, “VSCommands”. Det øger databaseversionsnummeret, opretter DACPAC og sætter det derefter i den rigtige mappe til distribution. Ved at implementere disse SSDT-processer strømliniserede det mit teams databaserelaterede opgaver, så vi kunne bruge mere tid på andre opgaver.

Konklusion

I fortiden føltes en ændring af en database som en lang, kompliceret proces med at udføre et skemaændring (til forhåbentlig den rigtige databaseversion), manuelt oprette et ændringsskript, minde distributionspersonen om databaseskiftet og krydse mine fingre at alt gik korrekt. Med SSDT er al denne usikkerhed forsvundet. SSDT er et fantastisk værktøj, der gør det nemt at oprette, implementere og version dine SQL Server-databaseopdateringer. Hvis du vil lære mere, skal du downloade prøvekoden, der viser, hvordan du automatisk distribuerer og versioner af en SQL Server-database.

Bemærkninger:

  • SSDT-websted: http://msdn.microsoft.com/en-us/data/tools
  • SSDT installeret i: C: \ Programfiler (x86) \ Microsoft SQL Server \ 110 \ DAC \ bin \
  • SSDT-version brugt: juli 2013 med Visual Studio 2012
  • VSCommands-udvidelse: http://vscommands.squaredinfinity.com/

Keith Schreiner er en software-arkitekt hos Geneca, et tilpasset softwareudviklingsfirma med base i Chicago. Han har over 15 års erfaring med at arbejde i softwareudviklingsbranchen.

© Copyright 2020 | mobilegn.com