Questo articolo parla di un nuovo metodo per controllare la versione di un database utilizzando una cartella di lavoro in modo da poter risalire alle modifiche cronologiche apportate al database.
Panoramica
Poiché questo articolo si basa sul nuovo approccio al controllo del codice sorgente di un database superando la limitazione della cartella di lavoro, è meglio acquisire una conoscenza di base della cartella di lavoro e delle cose correlate.
Sfondo
La cartella di lavoro, se utilizzata come controllo del codice sorgente, presenta una limitazione che non può mantenere la cronologia delle modifiche al database. Ma in questo articolo ci concentreremo sul metodo di utilizzo di un controllo del codice sorgente secondario (dietro le quinte) con una cartella di lavoro in grado di superare la limitazione.
Prerequisiti
Questo articolo presuppone che i lettori abbiano familiarità con le nozioni di base del controllo della versione del database usando la cartella di lavoro e Git insieme a una conoscenza di Visual Studio Team Services (VSTS), che ora è chiamato Azure DevOps.
Si consiglia di utilizzare i seguenti set di strumenti per eseguire tutti i passaggi menzionati in questo articolo:
- dbForge per SQL Server
- Controllo del codice sorgente dbForge
- Git per Windows (o qualsiasi client Git)
- Azure DevOps (ex VSTS)
Questo articolo presuppone inoltre che tu ti sia registrato ad Azure DevOps e abbia già un account oppure che tu possa registrarti e creare un nuovo account ora se desideri seguire tutti i passaggi in questo articolo.
In alternativa, qualsiasi controllo del codice sorgente che offre l'opzione Cartella di lavoro può essere utilizzato con SSMS (SQL Server Management Studio), a condizione che tu abbia le competenze necessarie per adottare l'approccio concettuale di questo articolo e metterlo in atto.
Riferimento
Per sviluppare una comprensione di base dell'utilizzo della cartella di lavoro nel database di controllo del codice sorgente, consultare il mio articolo precedente facendo clic sul collegamento seguente:
Utilizzo della cartella di lavoro nel database di controllo del codice sorgente in semplici passaggi
Limitazione della cartella di lavoro
Dobbiamo prima comprendere la limitazione dell'utilizzo di Cartella di lavoro per il controllo del codice sorgente di un database. Se hai letto il mio precedente articolo conosci già la limitazione.
Scenario cartella di lavoro
Se osserviamo da vicino i seguenti passaggi, possiamo facilmente capire come l'opzione di controllo del codice sorgente della cartella di lavoro sia limitata quando si tratta di controllo delle versioni del database:
- Dev1 crea un nuovo database sugli orologi da polso e lo chiama Orologi come da requisito.
- Dev1 crea ulteriormente una nuova tabella e la chiama Guarda con WatchId e WatchName colonne come da requisito.
- A Dev1 non è stato chiesto di utilizzare alcun particolare controllo del codice sorgente e il progetto stesso è in fase di test di sviluppo, quindi decide di utilizzare il controllo del codice sorgente della cartella di lavoro.
- A Dev2 è stato chiesto di creare una nuova tabella DigitalWatch con DigitalWatchId colonna in modo da eliminare il Guarda tavolo pensando che con il DigitalWatch tavolo il Guarda la tabella non è più richiesta.
- Non è possibile annullare le modifiche apportate da Dev2 e creare Guarda tabella utilizzando ancora una volta il controllo del codice sorgente della cartella di lavoro perché la cartella di lavoro ha appena ricevuto l'ultima versione del codice del database.
Questo è illustrato come segue:
Utilizzo della cartella di lavoro per tenere traccia delle modifiche al database
C'è un modo per imporre Cartella di lavoro per tenere traccia delle modifiche al database che possono aiutarci a ripristinare gli oggetti del database persi, sebbene l'utilizzo di Cartella di lavoro per impostazione predefinita non mantenga la cronologia delle modifiche al database.
Utilizzo del controllo del codice sorgente secondario (Git)
Ciò può essere ottenuto utilizzando un controllo del codice sorgente secondario affiancato all'utilizzo dell'opzione Cartella di lavoro che è un po' complicata da gestire ma funziona bene.
In questo articolo utilizzeremo Git come controllo del codice sorgente secondario con la cartella di lavoro.
Git è un sistema di controllo della versione distribuito e anche uno dei controlli del codice sorgente più comunemente usati oggi.
Perché Git con la cartella di lavoro?
Si potrebbe obiettare perché dobbiamo usare Git fianco a fianco con Cartella di lavoro quando possiamo usare direttamente Git con dbForge Studio per SQL Server per controllare la versione del nostro database.
La risposta è comprendere la natura flessibile dell'opzione di controllo del codice sorgente della cartella di lavoro ed esplorare l'ulteriore potenziale per continuare con la cartella di lavoro anziché utilizzarla semplicemente come soluzione temporanea.
Scarica Any Git Source Control Client o Git per Windows
Prima di andare oltre, installa qualsiasi client Git Source Control di tua scelta che ci aiuterà a salvare le modifiche al database nel tempo.
Questa procedura dettagliata dell'articolo utilizza il client Git per Windows.
Installa Git per Windows con le opzioni di tua scelta, abbiamo utilizzato le opzioni predefinite per installare Git per Windows.
Crea un progetto Azure DevOps usando Git
Accedi al tuo account Azure DevOps e crea un nuovo progetto SQLBookShopV3-Using-Working-Folder-with-Git e scegli Git Opzione di controllo del codice sorgente per creare un repository privato come segue.
Vai a Repo sulla barra di navigazione a sinistra e copia il link Repo (repository Git) facendo clic sull'icona degli appunti accanto al link.
Il piano è creare repository locale basato sul collegamento Git Repo e quindi potenziare la cartella di lavoro tramite questo.
Crea cartella di lavoro in Git Local Repos
Se hai già la cartella Git Local Repos, crea la tua cartella di lavoro SQLBookShopV3-Working-Folder-with-Git lì:
C:\Utenti\
In alternativa, crea i Repo cartella in qualsiasi posizione a tua scelta e quindi crea la sottocartella SQLBookShopV3-Working-Folder-with-Git.
Crea un nuovo repository Git Local
Ora creeremo un repository Git locale in modo che la cartella di lavoro possa inserirvisi.
Apri Git GUI che dovrebbe essere presente dopo Git per Windows installazione.
Crea il repository locale scegliendo Crea nuovo repository opzione.
Crea Git Local Repo (Repository).
Il repository Git locale è stato creato correttamente.
Collega Remote Git Repo con Local Repo
La creazione di Git Local Repository non è sufficiente, lo abbiamo collegato al nostro Git Remote Repository creato tramite Azure DevOps.
Collega Remote Git Repo con Git Local Repo selezionando Remote opzione dal menu principale e quindi facendo clic su Aggiungi nuovo telecomando e quindi digita il percorso del tuo progetto Azure DevOps.
Crea database SQLBookShopV3
Apri dbForge Studio per SQL Server e crea un nuovo database SQLBookShopV3 .
Crea tavolo libro
Crea il Libro tabella con le colonne BookId, Title e Author come segue.
CREATE TABLE SQLBookShopV3.dbo.Book ( BookId INT IDENTITY ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ,Title VARCHAR(100) ,Author VARCHAR(50) ) GO
Collega il database con il controllo del codice sorgente della cartella di lavoro
Nel passaggio successivo, collegheremo il database al controllo del codice sorgente della cartella di lavoro.
Fare clic con il pulsante destro del database (SQLBookShopV3) e selezionare Controllo origine , quindi Collega il database al controllo del codice sorgente .
Quindi, individua la cartella di lavoro creata in precedenza per collegarla al database.
Imposta modifiche alla cartella di lavoro
Vai a Gestione controllo risorse e seleziona (Impegna ) il Libro appena creato tabella nel controllo del codice sorgente Cartella di lavoro.
Controlla la cartella di lavoro per vedere il Libro tavolo lì.
Push modifiche a Git Source Control (Book Table)
Apri Git GUI di nuovo e fai clic su Rescan pulsante che dovrebbe mostrare l'oggetto tabella ora, aggiungi i seguenti commit iniziali:
Commit iniziale (la tabella Book creata la prima volta)
Quindi procedi come segue:
- Cambiamenti di fase
- Imposta modifiche
- Spingi (Modifiche)
In alternativa, puoi usare Git Bash per eseguire Git dalla riga di comando.
Visualizza le modifiche apportate a Git Source Control
Passa a Azure DevOps pagina web, a condizione che tu abbia già firmato e il progetto SQLBookShopV3-Using-Working-Folder-with-Git è attivo.
Fai clic su Repo sulla barra di navigazione a sinistra per visualizzare le modifiche appena apportate a Git Source Control.
Quindi, controlla lo script della tabella.
Aggiungi colonne stock e prezzo
Ora aggiungi altre due colonne Stock e Prezzo al Libro tabella utilizzando il seguente 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
La tabella dovrebbe apparire come di seguito.
Imposta modifiche alla cartella di lavoro
Salva la definizione più recente della tabella Libro che ora contiene due colonne extra in Controllo del codice sorgente della cartella di lavoro come mostrato di seguito.
Individua la cartella di lavoro utilizzando Esplora risorse e apri dbo.table.sql nel blocco note per visualizzare il codice.
La cartella di lavoro contiene la definizione più recente della tabella e non fornisce alcuna informazione sulla prima forma della tabella.
Come discusso, questa è la limitazione di Cartella di lavoro che possiamo vedere solo l'ultima versione del database che viene sovrascritta da versioni più recenti, quindi non lasciando spazio per risalire alla cronologia (modifica del database).
Push modifiche a Git Source Control (colonne stock e prezzo)
Nel passaggio successivo, invieremo le colonne appena aggiunte della tabella al repository Git Remote come mostrato di seguito.
Traccia le modifiche al database con Git Source Control
Finora, abbiamo apportato due modifiche principali al database nel seguente ordine:
- Il libro la tabella è stata creata con le colonne BookId, Title e Author
- Le colonne Prezzo e Stock sono state aggiunte al Libro tabella
Non c'è modo di vedere la prima modifica quando la tabella еру Book è stata originariamente creata utilizzando la cartella di lavoro.
Tuttavia, è possibile visualizzare tutta la cronologia delle modifiche al database utilizzando Git a condizione che le modifiche siano state inviate a Git Remote Repository.
In Azure DevOps, fare clic su Push sulla barra di navigazione a sinistra per vedere le modifiche storiche del database.
Vai a Commit per visualizzare l'ordine delle modifiche al database sotto forma di commit.
Fai clic sul primo impegno a99df4b5 per vedere la prima definizione del Libro tabella.
Torna indietro e fai clic sul commit successivo 6f863f0a per vedere le prossime modifiche al database.
Congratulazioni! Abbiamo tracciato con successo le modifiche al database utilizzando la cartella di lavoro con un controllo del codice sorgente secondario (Git).
Se lo desideri, possiamo tornare alla prima versione della tabella o continuare ad aggiungere altri oggetti di database.
Cose da fare
Ora puoi comodamente non solo mettere i tuoi oggetti di database sotto il controllo del codice sorgente di Cartella di lavoro, ma anche tenere traccia di tutte le modifiche al database lì mantenendo la cronologia del database.
- Prova a creare un altro database collegando il Libro tabella con il BookType tabella in modo tale che il BookTypeId chiave primaria del BookType la tabella viene passata come BookTypeId colonna chiave esterna nel Libro tabella e utilizzare il controllo del codice sorgente della cartella di lavoro per tenere traccia delle modifiche al database.
- Prova a creare gli Orologi database come mostrato nel primo diagramma dell'articolo e segui i passaggi mantenendo la cronologia delle modifiche del database utilizzando Cartella di lavoro con Git
- Prova a ripristinare le modifiche menzionate nel primo diagramma dell'articolo quando Dev2 elimina accidentalmente Guarda tabella creata da Dev1 utilizzando la cartella di lavoro per tenere traccia delle modifiche al database.
Strumento utile:
dbForge Source Control – potente componente aggiuntivo SSMS per la gestione delle modifiche al database di SQL Server nel controllo del codice sorgente.
