Dit artikel gaat over een nieuwe methode om een database versiebeheer te geven met behulp van een werkmap, zodat historische wijzigingen in de database kunnen worden getraceerd.
Overzicht
Aangezien dit artikel is gebaseerd op de nieuwe benadering van bronbeheer van een database door de beperking van de werkmap te omzeilen, is het beter om wat basiskennis te krijgen van de werkmap en aanverwante zaken.
Achtergrond
Werkmap, wanneer gebruikt als bronbesturingselement, heeft een beperking dat het de geschiedenis van de databasewijzigingen niet kan bewaren. Maar in dit artikel gaan we ons concentreren op de methode van het gebruik van een secundaire broncontrole (achter de schermen) met een werkmap die de beperking kan overwinnen.
Vereisten
In dit artikel wordt ervan uitgegaan dat de lezers bekend zijn met de basisprincipes van databaseversiebeheer met behulp van Working Folder en Git, samen met kennis van Visual Studio Team Services (VSTS), dat nu Azure DevOps wordt genoemd.
Het wordt aanbevolen om de volgende sets hulpmiddelen te gebruiken om alle stappen die in dit artikel worden genoemd te doorlopen:
- dbForge voor SQL Server
- dbForge Bronbeheer
- Git voor Windows (of een Git-client)
- Azure DevOps (voorheen VSTS)
In dit artikel wordt er ook van uitgegaan dat je je hebt aangemeld bij Azure DevOps en al een account hebt, of je kunt je nu aanmelden en een nieuw account maken als je alle stappen in dit artikel wilt volgen.
Als alternatief kan elk bronbeheer dat de optie Werkmap biedt, worden gebruikt met SSMS (SQL Server Management Studio), op voorwaarde dat u over de vereiste vaardigheden beschikt om de conceptuele benadering uit dit artikel te volgen en in praktijk te brengen.
Referentie
Om een basiskennis te ontwikkelen van het gebruik van de werkmap voor de bronbeheerdatabase, gelieve mijn vorige artikel door te nemen door op de onderstaande link te klikken:
Werkmap gebruiken voor bronbeheerdatabase in eenvoudige stappen
Beperking werkmap
We moeten eerst de beperking begrijpen van het gebruik van Working Folder voor bronbeheer van een database. Als je mijn vorige artikel hebt gelezen, ken je de beperking al.
Werkmapscenario
Als we de volgende stappen nauwlettend volgen, kunnen we gemakkelijk begrijpen hoe de bronbeheeroptie van de werkmap beperkt is als het gaat om databaseversiebeheer:
- Dev1 maakt een nieuwe database over polshorloges en noemt deze Horloges volgens vereiste.
- Dev1 maakt verder een nieuwe tabel en noemt deze Watch met WatchId en WatchName kolommen volgens vereiste.
- Dev1 is niet gevraagd om een bepaald bronbeheer te gebruiken en het project zelf bevindt zich in de ontwikkelingstestfase, dus besluit hij het bronbeheer van Working Folder te gebruiken.
- Dev2 is gevraagd om een nieuwe tabel te maken DigitalWatch met DigitalWatchId kolom zodat hij de Watch . verwijdert tafel denken dat met de DigitalWatch tafel de Kijk tafel is niet meer nodig.
- Er is geen manier om de wijzigingen die door Dev2 zijn aangebracht ongedaan te maken en de Watch te maken tabel nogmaals de bronbesturing van de werkmap gebruiken omdat de werkmap zojuist de nieuwste versie van de databasecode heeft.
Dit wordt als volgt geïllustreerd:
Werkmap gebruiken om databasewijzigingen bij te houden
Er is een manier om Working Folder af te dwingen om databasewijzigingen bij te houden, wat ons kan helpen de verloren databaseobjecten te herstellen, hoewel het standaard gebruik van Working Folder de geschiedenis van databasewijzigingen niet bijhoudt.
Gebruik van secundaire broncontrole (Git)
Dit kan worden bereikt door een secundaire broncontrole naast elkaar te gebruiken met de optie Werkmap, die een beetje ingewikkeld is om te beheren, maar goed werkt.
We gaan Git gebruiken als het secundaire bronbeheer met werkmap in dit artikel.
Git is een gedistribueerd versiebeheersysteem en ook een van de meest gebruikte broncodecontroles van vandaag.
Waarom Git met werkmap?
Je zou kunnen zeggen waarom we Git naast Working Folder moeten gebruiken als we Git direct kunnen gebruiken met dbForge Studio voor SQL Server om onze database versiebeheer te geven.
Het antwoord is om de flexibele aard van de bronbeheeroptie voor werkmap te begrijpen, samen met het verkennen van de verdere mogelijkheden om door te gaan met werkmap in plaats van het alleen als een tijdelijke oplossing te gebruiken.
Download elke Git Source Control Client of Git voor Windows
Voordat we verder gaan, moet u een Git Source Control-client van uw keuze installeren die ons zal helpen om databasewijzigingen in de loop van de tijd op te slaan.
Dit artikeloverzicht gebruikt Git voor Windows-client.
Installeer de Git voor Windows met de opties van uw keuze, we hebben de standaardopties gebruikt om Git voor Windows te installeren.
Maak een Azure DevOps-project met Git
Meld u aan bij uw Azure DevOps-account en maak een nieuw project SQLBookShopV3-Using-Working-Folder-with-Git en kies de Git Bronbeheeroptie om als volgt een privérepository te maken.
Ga naar Repo's op de linkernavigatiebalk en kopieer de Repo (Git-repository) link door op het klembordpictogram naast de link te klikken.
Het plan is om een lokale repo te maken op basis van de Git Repo-link en vervolgens Working Folder hierdoor te machtigen.
Maak een werkmap onder Git Local Repos
Als je de Git Local Repos-map al hebt, maak dan je werkmap SQLBookShopV3-Working-Folder-with-Git daar:
C:\Users\
U kunt ook de Repo's . maken map op een willekeurige plaats naar keuze en maak vervolgens de submap SQLBookShopV3-Working-Folder-with-Git.
Maak een nieuwe lokale Git-repository
We gaan nu een lokale Git-repository maken zodat de werkmap erin kan passen.
Open Git GUI die aanwezig zou moeten zijn na Git voor Windows installatie.
Maak de lokale repository door te kiezen voor Nieuwe repository maken optie.
Maak een Git Local Repo (Repository).
De lokale Git-repository is succesvol aangemaakt.
Externe Git-opslagplaats koppelen aan lokale opslag
Het creëren van Git Local Repository is niet genoeg, we hebben het gekoppeld aan onze Git Remote Repository die is gemaakt via Azure DevOps.
Koppel Remote Git Repo met Git Local Repo door de Remote . te selecteren optie in het hoofdmenu en klik vervolgens op Nieuwe afstandsbediening toevoegen en typ vervolgens uw Azure DevOps Project-locatie.
SQLBookShopV3-database maken
Open dbForge Studio voor SQL Server en maak een nieuwe database SQLBookShopV3 .
Boekentabel maken
Maak het Boek tabel met de kolommen BookId, Title en Author als volgt.
CREATE TABLE SQLBookShopV3.dbo.Book ( BookId INT IDENTITY ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ,Title VARCHAR(100) ,Author VARCHAR(50) ) GO
Database koppelen met bronbeheer voor werkmap
In de volgende stap gaan we de database koppelen aan Working Folder Source Control.
Klik met de rechtermuisknop op de database (SQLBookShopV3) en selecteer Bronbeheer , en dan Database koppelen aan bronbeheer .
Zoek vervolgens de eerder gemaakte werkmap om deze aan de database te koppelen.
Wijzigingen doorvoeren in werkmap
Ga naar Bronbeheerbeheer en vink aan (Bevestigen ) het nieuw gemaakte Boek tabel in het bronbeheer van de werkmap.
Controleer de werkmap om het Boek . te zien tafel daar.
Push Wijzigingen in Git Source Control (Book Table)
Open Git GUI opnieuw en klik op Opnieuw scannen knop die het tabelobject nu zou moeten tonen, voeg de volgende initiële commits toe:
Initiële Commit (de Boek-tabel die de eerste keer is gemaakt)
Voer dan de volgende stappen uit:
- Faseveranderingen
- Wijzigingen doorvoeren
- Duwen (Wijzigen)
Als alternatief kun je Git Bash gebruiken om Git vanaf de opdrachtregel uit te voeren.
Wijzigingen bekijken die zijn vastgelegd in Git Source Control
Navigeer naar Azure DevOps webpagina, op voorwaarde dat u al bent ondertekend en het SQLBookShopV3-Using-Working-Folder-with-Git-project is actief.
Klik op Repo's op de linkernavigatiebalk om de wijzigingen te zien die zojuist zijn vastgelegd in Git Source Control.
Controleer vervolgens het tabelscript.
Voorraad- en prijskolommen toevoegen
Voeg nu nog twee kolommen toe Voorraad en Prijs naar het Boek tabel met behulp van het volgende 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
De tabel zou er als volgt uit moeten zien.
Wijzigingen doorvoeren in werkmap
Sla de meest recente definitie van de Boek-tabel, die nu twee extra kolommen bevat, op in Bronbeheer voor werkmap, zoals hieronder weergegeven.
Zoek de werkmap met Windows Verkenner en open de dbo.table.sql in Kladblok om de code te zien.
De werkmap bevat de meest recente definitie van de tabel en geeft geen informatie over de eerste vorm van de tabel.
Zoals besproken, is dit de beperking van Working Folder dat we alleen de nieuwste versie van de database kunnen zien die wordt overschreven door nieuwere versies, waardoor er geen ruimte is om de (databasewijziging) geschiedenis te traceren.
Wijzigingen pushen in Git Source Control (voorraad- en prijskolommen)
In de volgende stap gaan we de nieuw toegevoegde kolommen van de tabel naar de Git Remote Repository pushen, zoals hieronder weergegeven.
Databasewijzigingen traceren met Git Source Control
Tot nu toe hebben we twee belangrijke databasewijzigingen doorgevoerd in de volgende volgorde:
- Het Boek tabel is gemaakt met de kolommen BookId, Titel en Auteur
- De kolommen Prijs en Voorraad zijn toegevoegd aan het Boek tafel
Er is geen manier om de eerste wijziging te zien wanneer еру Boekentabel oorspronkelijk is gemaakt met behulp van de werkmap.
Het is echter mogelijk om de hele geschiedenis van databasewijzigingen te bekijken met Git, zolang we die wijzigingen naar Git Remote Repository hebben gepusht.
Klik op de Azure DevOps op Pushes op de linkernavigatiebalk om de historische wijzigingen van de database te zien.
Navigeer naar Toezeggingen om de volgorde van databasewijzigingen in de vorm van commits te bekijken.
Klik op de eerste Vastleggen a99df4b5 om de eerste definitie van het Boek te zien tafel.
Ga terug en klik op de volgende commit 6f863f0a om de volgende databasewijziging(en) te zien.
Gefeliciteerd! We hebben de databasewijzigingen met succes gevolgd met behulp van Working Folder met een secundaire Source Control (Git).
We kunnen nu desgewenst terugkeren naar de eerste versie van de tabel of doorgaan met het toevoegen van meer database-objecten.
Dingen om te doen
U kunt nu comfortabel niet alleen uw database-objecten onder bronbeheer van de werkmap plaatsen, maar ook alle databasewijzigingen daar bijhouden door de databasegeschiedenis bij te houden.
- Probeer een andere database te maken door het Boek . te linken tabel met het BookType tabel zodanig dat de BookTypeId primaire sleutel van het BookType tabel wordt doorgegeven als de BookTypeId kolom buitenlandse sleutel in het Boek tabel en gebruik bronbeheer voor werkmappen om databasewijzigingen bij te houden.
- Probeer de Horloges . te maken database zoals te zien in het eerste diagram van het artikel en volg de stappen door de geschiedenis van databasewijzigingen bij te houden met behulp van Working Folder with Git
- Probeer de in het eerste diagram van het artikel genoemde wijzigingen ongedaan te maken wanneer Dev2 per ongeluk de Watch verwijdert tabel gemaakt door Dev1 met behulp van werkmap om databasewijzigingen bij te houden.
Handig hulpmiddel:
dbForge Source Control – krachtige SSMS-invoegtoepassing voor het beheren van SQL Server-databasewijzigingen in bronbeheer.