Den här artikeln talar om en ny metod för att versionskontrollera en databas med hjälp av en arbetsmapp så att historiska ändringar som gjorts i databasen kan spåras tillbaka.
Översikt
Eftersom den här artikeln är baserad på det nya tillvägagångssättet för källkontroll av en databas genom att övervinna arbetsmappbegränsningen, är det bättre att få en grundläggande förståelse för arbetsmappen och relaterade saker.
Bakgrund
Arbetsmapp, när den används som källkontroll, har en begränsning att den inte kan behålla historiken för databasändringarna. Men i den här artikeln kommer vi att fokusera på metoden att använda en sekundär källkontroll (bakom kulisserna) med en fungerande mapp som kan övervinna begränsningen.
Förutsättningar
Den här artikeln förutsätter att läsarna är bekanta med grunderna för databasversionskontroll med Working Folder och Git tillsammans med en förståelse för Visual Studio Team Services (VSTS) som nu kallas Azure DevOps.
Det rekommenderas att du använder följande uppsättningar verktyg för att gå igenom alla steg som nämns i den här artikeln:
- dbForge för SQL Server
- dbForge källkontroll
- Git för Windows (eller någon Git-klient)
- Azure DevOps (tidigare VSTS)
Den här artikeln förutsätter också att du har registrerat dig med Azure DevOps och redan har ett konto, eller så kan du registrera dig och skapa ett nytt konto nu om du vill följa alla stegen i den här artikeln.
Alternativt kan alla källkontroller som erbjuder alternativet Working Folder användas med SSMS (SQL Server Management Studio) förutsatt att du har de kunskaper som krävs för att ta det konceptuella tillvägagångssättet från denna artikel och omsätta det i handling.
Referens
För att utveckla en grundläggande förståelse för att använda arbetsmappen till källkontrolldatabasen, gå igenom min tidigare artikel genom att klicka på länken nedan:
Använda arbetsmappen för att källkontrolldatabasen i enkla steg
Begränsning av arbetsmapp
Vi måste först förstå begränsningen av att använda Working Folder för att källkontrollera en databas. Om du har läst min tidigare artikel vet du redan begränsningen.
Scenario för arbetsmapp
Om vi noga observerar följande steg kan vi enkelt förstå hur alternativet Working Folder-källkontroll är begränsat när det gäller databasversionering:
- Dev1 skapar en ny databas om armbandsur och kallar den Klockor enligt krav.
- Dev1 skapar vidare en ny tabell och kallar den Titta med WatchId och WatchName kolumner enligt krav.
- Dev1 har inte blivit ombedd att använda någon särskild källkontroll och själva projektet befinner sig i utvecklingstestfasen så han bestämmer sig för att använda källkontroll för Working Folder.
- Dev2 har blivit ombedd att skapa en ny tabell DigitalWatch med DigitalWatchId kolumnen så att han tar bort Titta tabell tänker att med DigitalWatch tabell Titta bord krävs inte längre.
- Det finns inget sätt att återställa ändringarna som gjorts av Dev2 och skapa Klockan tabell med hjälp av källkontrollen för arbetsmappen igen eftersom arbetsmappen precis har den senaste versionen av databaskoden.
Detta illustreras enligt följande:
Använda arbetsmapp för att spåra databasändringar
Det finns ett sätt att genomdriva Working Folder för att hålla reda på databasändringar som kan hjälpa oss att återställa de förlorade databasobjekten, även om användning av Working Folder som standard inte bibehåller historiken för databasändringar.
Användning av sekundär källkontroll (Git)
Detta kan uppnås genom att använda en sekundär källkontroll sida vid sida med alternativet Working Folder som är lite komplicerat att hantera men fungerar bra.
Vi kommer att använda Git som den sekundära källkontrollen med arbetsmappen i den här artikeln.
Git är ett distribuerat versionskontrollsystem och även en av de mest använda källkontrollerna idag.
Varför Git med Working Folder?
Man skulle kunna hävda varför vi behöver använda Git sida vid sida med Working Folder när vi direkt kan använda Git med dbForge Studio för SQL Server för att versionskontrollera vår databas.
Svaret är att förstå den flexibla karaktären hos alternativet Working Folder Source Control tillsammans med att utforska den ytterligare potentialen att fortsätta med Working Folder istället för att bara använda den som en tillfällig lösning.
Ladda ned valfri Git Source Control Client eller Git för Windows
Innan vi går vidare, installera en valfri Git Source Control-klient som kommer att hjälpa oss att spara databasändringar med tiden.
Den här artikelgenomgången använder Git för Windows-klienten.
Installera Git för Windows med de alternativ du väljer, vi har använt standardalternativen för att installera Git för Windows.
Skapa Azure DevOps Project med Git
Logga in på ditt Azure DevOps-konto och skapa ett nytt projekt SQLBookShopV3-Using-Working-Folder-with-Git och välj Git Källkontrollalternativ för att skapa ett privat arkiv enligt följande.
Gå till Repos i det vänstra navigeringsfältet och kopiera länken Repo (Git repository) genom att klicka på urklippsikonen bredvid länken.
Planen är att skapa lokal repo baserat på Git Repo-länken och sedan ge Working Folder bemyndigande genom detta.
Skapa arbetsmapp under Git Local Repos
Om du redan har Git Local Repos-mappen, skapa sedan din arbetsmapp SQLBookShopV3-Working-Folder-with-Git där:
C:\Users\
Alternativt kan du skapa Repos mapp valfri plats och skapa sedan undermappen SQLBookShopV3-Working-Folder-with-Git.
Skapa nytt Git Local Repository
Vi ska nu skapa ett lokalt Git-förråd så att arbetsmappen kan passa in i den.
Öppna Git GUI som bör finnas efter Git för Windows installation.
Skapa det lokala arkivet genom att välja Skapa nytt arkiv alternativ.
Skapa Git Local Repo (Repository).
Det lokala Git-förrådet har skapats framgångsrikt.
Länka Remote Git Repo med Local Repo
Det räcker inte att skapa Git Local Repository, vi har länkat det till vårt Git Remote Repository skapat genom Azure DevOps.
Länka Remote Git Repo med Git Local Repo genom att välja Remote från huvudmenyn och klicka sedan på Lägg till ny fjärrkontroll och skriv sedan in din Azure DevOps Project-plats.
Skapa SQLBookShopV3-databas
Öppna dbForge Studio för SQL Server och skapa en ny databas SQLBookShopV3 .
Skapa bokbord
Skapa boken tabell med kolumnerna BookId, Title och Author enligt följande.
CREATE TABLE SQLBookShopV3.dbo.Book ( BookId INT IDENTITY ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ,Title VARCHAR(100) ,Author VARCHAR(50) ) GO
Länka databas med källkontroll för arbetsmapp
I nästa steg kommer vi att länka databasen till Working Folder Source Control.
Högerklicka på databasen (SQLBookShopV3) och välj Källkontroll , och sedan Länka databas till källkontroll .
Leta sedan upp den arbetsmapp som skapats tidigare för att länka den till databasen.
Bekräfta ändringar i arbetsmappen
Gå till Källkontrollhanteraren och markera (Bekräfta ) den nyskapade boken tabellen i arbetsmappens källkontroll.
Kontrollera arbetsmappen för att se boken bord där.
Push Changes to Git Source Control (Book Table)
Öppna Git GUI igen och klicka på Sök igen knappen som nu ska visa tabellobjektet, lägg till följande initiala commits:
Initial Commit (boktabellen skapades första gången)
Gör sedan följande steg:
- Scenförändringar
- Bekräfta ändringar
- Push (Ändringar)
Alternativt kan du använda Git Bash för att köra Git från kommandoraden.
Visa ändringar som är anslutna till Git Source Control
Navigera till Azure DevOps webbsida, förutsatt att du redan är signerad och SQLBookShopV3-Using-Working-Folder-with-Git-projektet är aktiv.
Klicka på Repos i det vänstra navigeringsfältet för att se ändringarna som just gjorts för Git Source Control.
Kontrollera sedan tabellskriptet.
Lägg till aktie- och priskolumner
Lägg nu till ytterligare två kolumner Lager och Pris till boken tabell genom att använda följande skript.
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 ska se ut som nedan.
Bekräfta ändringar i arbetsmappen
Spara den senaste definitionen av boktabellen som nu innehåller två extra kolumner till Working Folder Source Control som visas nedan.
Leta upp Working Folder med Windows Explorer och öppna dbo.table.sql i anteckningsblocket för att se koden.
Arbetsmappen innehåller den senaste definitionen av tabellen och ger ingen information om tabellens första form.
Som diskuterats är detta begränsningen för Working Folder att vi bara kan se den senaste versionen av databasen som skrivs över av nyare versioner och därigenom lämnar inget utrymme att spåra (databasändrings)historiken.
Push Ändringar till Git Source Control (aktie- och priskolumner)
I nästa steg kommer vi att flytta de nyligen tillagda kolumnerna i tabellen till Git Remote Repository som visas nedan.
Spåra databasändringar med Git Source Control
Hittills har vi gjort två huvuddatabasändringar i följande ordning:
- Boken tabellen skapades med kolumnerna BookId, Title och Author
- Kolumnerna Pris och Lager har lagts till i boken tabell
Det finns inget sätt att se den första ändringen när еру Book table ursprungligen skapades med Working Folder.
Det är dock möjligt att se all historik över databasändringar med hjälp av Git så länge vi har pushat dessa ändringar till Git Remote Repository.
På Azure DevOps klickar du på Pushar i det vänstra navigeringsfältet för att se de historiska ändringarna av databasen.
Navigera till Commits för att se ordningen på databasändringar i form av commits.
Klicka på den första Commit a99df4b5 för att se den första definitionen av boken bord.
Gå tillbaka och klicka på nästa commit 6f863f0a för att se nästa databasändring(ar).
Grattis! Vi har lyckats spåra databasändringarna med Working Folder med en sekundär källkontroll (Git).
Vi kan nu återgå till den första versionen av tabellen om så önskas eller fortsätta att lägga till fler databasobjekt.
Saker att göra
Du kan nu bekvämt inte bara placera dina databasobjekt under källkontroll för arbetsmapp utan också hålla reda på alla databasändringar där genom att underhålla databashistorik.
- Försök att skapa en annan databas genom att länka boken tabell med BookType tabell på ett sådant sätt att BookTypeId primärnyckeln för BookType tabellen skickas som BookTypeId kolumnen för främmande nyckel i boken tabell och använd källkontroll för arbetsmapp för att spåra databasändringar.
- Försök att skapa klockorna databas som visas i det första diagrammet i artikeln och följ stegen genom att underhålla databasens ändringshistorik med Working Folder with Git
- Försök att återställa ändringar som nämns i det första diagrammet i artikeln när Dev2 av misstag tar bort Titta tabell skapad av Dev1 med Working Folder för att spåra databasändringar.
Användbart verktyg:
dbForge Source Control – kraftfullt SSMS-tillägg för att hantera SQL Server-databasändringar i källkontroll.