Denne artikel taler om en ny metode til versionskontrol af en database ved hjælp af en arbejdsmappe, så historiske ændringer foretaget i databasen kan spores tilbage.
Oversigt
Da denne artikel er baseret på den nye tilgang til kildestyring af en database ved at overvinde arbejdsmappebegrænsningen, er det bedre at få en grundlæggende forståelse af arbejdsmappen og relaterede ting.
Baggrund
Arbejdsmappe, når den bruges som en kildekontrol, har en begrænsning, at den ikke kan opbevare historikken for databaseændringerne. Men i denne artikel vil vi fokusere på metoden til at bruge en sekundær kildekontrol (bag kulisserne) med en arbejdsmappe, der kan overvinde begrænsningen.
Forudsætninger
Denne artikel antager, at læserne er fortrolige med det grundlæggende i databaseversionskontrol ved hjælp af Working Folder og Git sammen med en forståelse af Visual Studio Team Services (VSTS), som nu kaldes Azure DevOps.
Det anbefales at bruge følgende sæt værktøjer til at køre gennem alle de trin, der er nævnt i denne artikel:
- dbForge til SQL Server
- dbForge kildekontrol
- Git til Windows (eller enhver Git-klient)
- Azure DevOps (tidligere VSTS)
Denne artikel forudsætter også, at du har tilmeldt dig Azure DevOps og allerede har en konto, eller du kan tilmelde dig og oprette en ny konto nu, hvis du ønsker at følge alle trinene i denne artikel.
Alternativt kan enhver kildekontrol, der tilbyder muligheden for arbejdsmappe, bruges med SSMS (SQL Server Management Studio), forudsat at du har de nødvendige færdigheder til at tage den konceptuelle tilgang fra denne artikel og omsætte den til handling.
Reference
For at udvikle en grundlæggende forståelse af at bruge arbejdsmappen til kildestyringsdatabase, bedes du gå gennem min tidligere artikel ved at klikke på linket nedenfor:
Brug af arbejdsmappe til kildekontroldatabase i enkle trin
Begrænsning af arbejdsmappe
Vi skal først forstå begrænsningen ved at bruge Working Folder til at kildestyre en database. Hvis du har læst min tidligere artikel, kender du allerede begrænsningen.
Scenario for arbejdsmappe
Hvis vi nøje observerer følgende trin, kan vi nemt forstå, hvordan kildestyringsindstillingen for Working Folder er begrænset, når det kommer til databaseversionering:
- Dev1 opretter en ny database om armbåndsure og kalder den ure efter krav.
- Dev1 opretter yderligere en ny tabel og kalder den Se med WatchId og WatchName kolonner efter krav.
- Dev1 er ikke blevet bedt om at bruge nogen bestemt kildekontrol, og selve projektet er i udviklingstestfasen, så han beslutter sig for at bruge Working Folder-kildestyring.
- Dev2 er blevet bedt om at oprette en ny tabel DigitalWatch med DigitalWatchId kolonnen, så han sletter Se tabel tænker, at med DigitalWatch tabel Se tabel er ikke længere påkrævet.
- Der er ingen måde at fortryde ændringerne udført af Dev2 og oprette Watch tabel ved at bruge arbejdsmappens kildekontrol igen, fordi arbejdsmappen lige har fået den seneste version af databasekoden.
Dette er illustreret som følger:
Brug af arbejdsmappe til at spore databaseændringer
Der er en måde at gennemtvinge Working Folder til at holde styr på databaseændringer, som kan hjælpe os med at gendanne de tabte databaseobjekter, selvom brug af Working Folder som standard ikke opretholder historikken for databaseændringer.
Brug af sekundær kildekontrol (Git)
Dette kan opnås ved at bruge en sekundær kildekontrol side om side med at bruge indstillingen Working Folder, som er lidt kompliceret at administrere, men fungerer godt.
Vi kommer til at bruge Git som den sekundære kildekontrol med arbejdsmappe i denne artikel.
Git er et distribueret versionskontrolsystem og også en af de mest almindeligt anvendte kildekontroller i dag.
Hvorfor Git med Working Folder?
Man vil argumentere for, hvorfor vi skal bruge Git side om side med Working Folder, når vi direkte kan bruge Git med dbForge Studio til SQL Server til at versionskontrollere vores database.
Svaret er at forstå den fleksible karakter af indstillingen Working Folder Source Control sammen med at udforske det yderligere potentiale for at fortsætte med Working Folder i stedet for blot at bruge det som en midlertidig løsning.
Download enhver Git Source Control Client eller Git til Windows
Inden vi går videre, skal du installere enhver Git Source Control-klient efter eget valg, som vil hjælpe os med at gemme databaseændringer med tiden.
Denne artikelgennemgang bruger Git til Windows-klient.
Installer Git til Windows med dine valgmuligheder, vi har brugt standardindstillingerne til at installere Git til Windows.
Opret Azure DevOps Project ved hjælp af Git
Log ind på din Azure DevOps-konto, og opret et nyt projekt SQLBookShopV3-Using-Working-Folder-with-Git og vælg Git Kildekontrol mulighed for at oprette et privat lager som følger.
Gå til Repos på venstre navigationslinje, og kopier linket Repo (Git repository) ved at klikke på udklipsholderikonet ved siden af linket.
Planen er at oprette lokal repo baseret på Git Repo-linket og derefter styrke Working Folder gennem dette.
Opret arbejdsmappe under Git Local Repos
Hvis du allerede har Git Local Repos-mappe, så opret din arbejdsmappe SQLBookShopV3-Working-Folder-with-Git der:
C:\Users\
Alternativt kan du oprette Repos mappe et hvilket som helst sted efter eget valg, og opret derefter undermappen SQLBookShopV3-Working-Folder-with-Git.
Opret nyt Git Local Repository
Vi skal nu oprette et lokalt Git-lager, så arbejdsmappen kan passe ind i det.
Åbn Git GUI som skulle være til stede efter Git til Windows installation.
Opret det lokale lager ved at vælge Opret nyt lager mulighed.
Opret Git Local Repo (Repository).
Det lokale Git-lager er blevet oprettet.
Link Remote Git Repo med Local Repo
Det er ikke nok at oprette Git Local Repository, vi har forbundet det med vores Git Remote Repository, der er oprettet gennem Azure DevOps.
Forbind Remote Git Repo med Git Local Repo ved at vælge Remote fra hovedmenuen og derefter klikke på Tilføj ny fjernbetjening og indtast derefter din Azure DevOps Project-placering.
Opret SQLBookShopV3-database
Åbn dbForge Studio til SQL Server og opret en ny database SQLBookShopV3 .
Opret bogbord
Opret bogen tabel med BookId, Title og Author kolonnerne som følger.
CREATE TABLE SQLBookShopV3.dbo.Book ( BookId INT IDENTITY ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ,Title VARCHAR(100) ,Author VARCHAR(50) ) GO
Link database med arbejdsmappekildekontrol
I næste trin vil vi linke databasen til Working Folder Source Control.
Højreklik på databasen (SQLBookShopV3), og vælg Kildekontrol , og derefter Link database til kildekontrol .
Find derefter den tidligere oprettede arbejdsmappe for at forbinde den med databasen.
Bekræft ændringer til arbejdsmappe
Gå til Kildekontrolstyring og marker (Bekræft ) den nyoprettede bog tabel ind i Working Folder source control.
Tjek arbejdsmappen for at se bogen bord der.
Skub ændringer til Git-kildekontrol (bogtabel)
Åbn Git GUI igen, og klik på Scan igen knappen, som skal vise tabelobjektet nu, tilføj følgende indledende commits:
Initial Commit (bogtabellen oprettet første gang)
Udfør derefter følgende trin:
- Stageændringer
- Bekræft ændringer
- Push (Ændringer)
Alternativt kan du bruge Git Bash til at køre Git fra kommandolinjen.
Se ændringer forpligtet til Git-kildekontrol
Naviger til Azure DevOps webside, forudsat at du allerede er underskrevet og SQLBookShopV3-Using-Working-Folder-with-Git-projektet er aktiv.
Klik på Repos på venstre navigationslinje for at se de ændringer, der netop er foretaget til Git Source Control.
Tjek derefter tabelscriptet.
Tilføj aktie- og priskolonner
Tilføj nu yderligere to kolonner Aktier og Pris til bogen tabel ved at bruge følgende script.
CREATE TABLE SQLBookShopV3.dbo.Book ( BookId INT IDENTITY ,Title VARCHAR(100) NULL ,Author VARCHAR(50) NULL ,Price DECIMAL(8, 2) NULL ,Stock SMALLINT NULL ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ) ON [PRIMARY] GO
Tabellen skal se ud som nedenfor.
Bekræft ændringer til arbejdsmappe
Gem den seneste definition af bogtabellen, som nu indeholder to ekstra kolonner til Working Folder Source Control som vist nedenfor.
Find arbejdsmappe ved hjælp af Windows Stifinder, og åbn dbo.table.sql i notesblok for at se koden.
Arbejdsmappen indeholder den seneste definition af tabellen og giver ingen information om tabellens første form.
Som diskuteret er dette begrænsningen af Working Folder, at vi kun kan se den seneste version af databasen, som bliver overskrevet af nyere versioner og derved ikke efterlader plads til at spore (databaseændrings)historikken tilbage.
Skub ændringer til Git-kildekontrol (aktie- og priskolonner)
I det næste trin skal vi skubbe de nyligt tilføjede kolonner i tabellen til Git Remote Repository som vist nedenfor.
Spor databaseændringer med Git Source Control
Indtil videre har vi lavet to hoveddatabaseændringer i følgende rækkefølge:
- Bogen tabellen blev oprettet med kolonnerne BookId, Title og Author
- Kolonnerne Pris og Lager blev føjet til bogen tabel
Der er ingen måde at se den første ændring, da еру Book table oprindeligt blev oprettet ved hjælp af Working Folder.
Det er dog muligt at se hele historikken for databaseændringer ved hjælp af Git, så længe vi har skubbet disse ændringer til Git Remote Repository.
På Azure DevOps skal du klikke på Pusher på venstre navigationslinje for at se de historiske ændringer af databasen.
Naviger til Commits for at se rækkefølgen af databaseændringer i form af commits.
Klik på den første Commit a99df4b5 for at se den første definition af bogen tabel.
Gå tilbage og klik på næste commit 6f863f0a for at se næste databaseændring(er).
Tillykke! Vi har med succes sporet databaseændringerne ved hjælp af Working Folder med en sekundær kildekontrol (Git).
Vi kan nu vende tilbage til den første version af tabellen, hvis det ønskes, eller fortsætte med at tilføje flere databaseobjekter.
Ting at gøre
Du kan nu komfortabelt ikke kun placere dine databaseobjekter under arbejdsmappekildekontrol, men også holde styr på alle databaseændringerne der ved at vedligeholde databasehistorikken.
- Prøv venligst at oprette en anden database ved at linke bogen tabel med BookType tabel på en sådan måde, at BookTypeId primære nøgle for BookType tabellen videregives som BookTypeId fremmednøglekolonnen i bogen tabel og brug arbejdsmappekildekontrol til at spore databaseændringer.
- Prøv venligst at oprette Urene database som ses i det første diagram i artiklen, og følg trinene ved at vedligeholde databaseændringshistorikken ved hjælp af Working Folder with Git
- Prøv venligst at fortryde ændringer nævnt i det første diagram i artiklen, når Dev2 ved et uheld sletter Se tabel oprettet af Dev1 ved hjælp af Working Folder til at spore databaseændringer.
Nyttigt værktøj:
dbForge Source Control – kraftfuld SSMS-tilføjelse til styring af SQL Server-databaseændringer i kildekontrol.