Database
 sql >> Base de données >  >> RDS >> Database

Suivi des modifications de la base de données à l'aide du contrôle de code source du dossier de travail

Cet article parle d'une nouvelle méthode pour contrôler la version d'une base de données à l'aide d'un dossier de travail afin que les modifications historiques apportées à la base de données puissent être retracées.

Aperçu

Étant donné que cet article est basé sur la nouvelle approche du contrôle de source d'une base de données en surmontant la limitation du dossier de travail, il est préférable d'acquérir une compréhension de base du dossier de travail et des éléments connexes.

Contexte

Le dossier de travail, lorsqu'il est utilisé comme contrôle de code source, a une limitation selon laquelle il ne peut pas conserver l'historique des modifications de la base de données. Mais dans cet article, nous allons nous concentrer sur la méthode d'utilisation d'un contrôle de source secondaire (en coulisses) avec un dossier de travail qui peut surmonter la limitation.

Prérequis

Cet article suppose que les lecteurs connaissent les bases du contrôle de version de base de données à l'aide de Working Folder et Git, ainsi qu'une compréhension de Visual Studio Team Services (VSTS), désormais appelé Azure DevOps.

Il est recommandé d'utiliser les ensembles d'outils suivants pour exécuter toutes les étapes mentionnées dans cet article :

  1. dbForge pour SQL Server
  2. Contrôle des sources dbForge
  3. Git pour Windows (ou n'importe quel client Git)
  4. Azure DevOps (anciennement VSTS)

Cet article suppose également que vous vous êtes inscrit auprès d'Azure DevOps et que vous avez déjà un compte, ou vous pouvez vous inscrire et créer un nouveau compte maintenant si vous souhaitez suivre toutes les étapes de cet article.

Alternativement, tout contrôle de source qui offre l'option Dossier de travail peut être utilisé avec SSMS (SQL Server Management Studio) à condition que vous ayez les compétences requises pour adopter l'approche conceptuelle de cet article et la mettre en action.

Référence

Afin de développer une compréhension de base de l'utilisation du dossier de travail pour la base de données de contrôle des sources, veuillez parcourir mon article précédent en cliquant sur le lien ci-dessous :

Utilisation du dossier de travail pour la base de données de contrôle source en quelques étapes simples

Limitation du dossier de travail

Nous devons d'abord comprendre la limitation de l'utilisation du dossier de travail pour contrôler la source d'une base de données. Si vous avez lu mon article précédent, vous connaissez déjà la limitation.

Scénario de dossier de travail

Si nous observons attentivement les étapes suivantes, nous pouvons facilement comprendre comment l'option de contrôle de source du dossier de travail est limitée en ce qui concerne la gestion des versions de la base de données :

  1. Dev1 crée une nouvelle base de données sur les montres-bracelets et l'appelle Watches selon les besoins.
  2. Dev1 crée ensuite une nouvelle table et l'appelle Watch avec WatchId et WatchName colonnes selon les besoins.
  3. Dev1 n'a pas été invité à utiliser un contrôle de source particulier et le projet lui-même est en phase de test de développement, il décide donc d'utiliser le contrôle de source du dossier de travail.
  4. Dev2 a été invité à créer une nouvelle table DigitalWatch avec DigitalWatchId colonne afin qu'il supprime la Watch table en pensant qu'avec la DigitalWatch déposer la surveillance table n'est plus nécessaire.
  5. Il n'y a aucun moyen d'annuler les modifications apportées par Dev2 et de créer la Watch table en utilisant à nouveau le contrôle de source du dossier de travail, car le dossier de travail vient de recevoir la dernière version du code de la base de données.

Ceci est illustré comme suit :

Utiliser le dossier de travail pour suivre les modifications de la base de données

Il existe un moyen d'appliquer le dossier de travail pour suivre les modifications de la base de données, ce qui peut nous aider à restaurer les objets de base de données perdus, bien que l'utilisation du dossier de travail par défaut ne conserve pas l'historique des modifications de la base de données.

Utilisation du contrôle de source secondaire (Git)

Ceci peut être réalisé en utilisant un contrôle source secondaire parallèlement à l'utilisation de l'option Dossier de travail qui est un peu compliquée à gérer mais qui fonctionne bien.

Nous allons utiliser Git comme contrôle de source secondaire avec dossier de travail dans cet article.

Git est un système de contrôle de version distribué et également l'un des contrôles de source les plus couramment utilisés aujourd'hui.

Pourquoi Git avec un dossier de travail ?

On pourrait dire pourquoi nous devons utiliser Git côte à côte avec le dossier de travail alors que nous pouvons directement utiliser Git avec dbForge Studio pour SQL Server pour contrôler la version de notre base de données.

La réponse est de comprendre la nature flexible de l'option de contrôle source du dossier de travail tout en explorant le potentiel supplémentaire de continuer avec le dossier de travail plutôt que de l'utiliser simplement comme une solution temporaire.

Téléchargez n'importe quel client de contrôle de source Git ou Git pour Windows

Avant d'aller plus loin, veuillez installer n'importe quel client Git Source Control de votre choix qui nous aidera à enregistrer les modifications de la base de données au fil du temps.

Cette procédure pas à pas utilise Git pour le client Windows.

Installez Git pour Windows avec les options de votre choix, nous avons utilisé les options par défaut pour installer Git pour Windows.

Créer un projet Azure DevOps à l'aide de Git

Connectez-vous à votre compte Azure DevOps et créez un nouveau projet SQLBookShopV3-Using-Working-Folder-with-Git et choisissez le Git Option de contrôle de source pour créer un référentiel privé comme suit.

Accédez au dépôt dans la barre de navigation de gauche et copiez le lien Repo (référentiel Git) en cliquant sur l'icône du presse-papiers à côté du lien.

Le plan consiste à créer un référentiel local basé sur le lien Git Repo, puis à activer le dossier de travail via celui-ci.

Créer un dossier de travail sous Git Local Repos

Si vous avez déjà le dossier Git Local Repos, créez votre dossier de travail SQLBookShopV3-Working-Folder-with-Git là :

C:\Users\\Source\Repos\SQLBookShopV3-Working-Folder-with-Git

Vous pouvez également créer le dépôt dossier à l'endroit de votre choix, puis créez le sous-dossier SQLBookShopV3-Working-Folder-with-Git.

Créer un nouveau dépôt local Git

Nous allons maintenant créer un référentiel Git local afin que le dossier de travail puisse s'y intégrer.

Ouvrez l'interface graphique Git qui devrait être présent après Git pour Windows mise en place.

Créez le dépôt local en choisissant Créer un nouveau dépôt option.

Créer un dépôt local Git (dépôt).

Le référentiel Git local a été créé avec succès.

Lier le référentiel Git distant avec le référentiel local

Créer un référentiel local Git ne suffit pas, nous l'avons lié à notre référentiel distant Git créé via Azure DevOps.

Liez Remote Git Repo avec Git Local Repo en sélectionnant Remote dans le menu principal, puis en cliquant sur Ajouter une nouvelle télécommande puis saisissez l'emplacement de votre projet Azure DevOps.

Créer une base de données SQLBookShopV3

Ouvrez dbForge Studio pour SQL Server et créez une nouvelle base de données SQLBookShopV3 .

Créer un tableau de livres

Créer le livre tableau avec les colonnes BookId, Title et Author comme suit.

CREATE TABLE SQLBookShopV3.dbo.Book (
  BookId INT IDENTITY
 ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId)
 ,Title VARCHAR(100)
 ,Author VARCHAR(50)
)
GO

Lier la base de données avec le contrôle source du dossier de travail

Dans l'étape suivante, nous allons lier la base de données au contrôle source du dossier de travail.

Faites un clic droit sur la base de données (SQLBookShopV3) et sélectionnez Contrôle de source , puis Lier la base de données au contrôle de code source .

Ensuite, localisez le dossier de travail créé précédemment pour le lier à la base de données.

Valider les modifications dans le dossier de travail

Accédez à Gestionnaire de contrôle de code source et cochez (Commit ) le Livre nouvellement créé table dans le contrôle source du dossier de travail.

Vérifiez le dossier de travail pour voir le livre table ici.

Pousser les modifications au contrôle de source Git (Table du livre)

Ouvrez l'interface graphique Git à nouveau et cliquez sur Réanalyser bouton qui devrait maintenant afficher l'objet table, ajoutez les commits initiaux suivants :

Validation initiale (la table Book créée la première fois)

Effectuez ensuite les étapes suivantes :

  1. Changements d'étape
  2. Valider les modifications
  3. Pousser (Modifications)

Vous pouvez également utiliser Git Bash pour exécuter Git à partir de la ligne de commande.

Afficher les modifications validées pour le contrôle de source Git

Accédez à Azure DevOps page Web, à condition que vous soyez déjà signé et le projet SQLBookShopV3-Using-Working-Folder-with-Git est actif.

Cliquez sur Repos dans la barre de navigation de gauche pour afficher les modifications qui viennent d'être validées dans Git Source Control.

Ensuite, vérifiez le script de table.

Ajouter des colonnes Stock et Prix

Ajoutez maintenant deux colonnes supplémentaires Stock et Prix au Livre table en utilisant le script suivant.

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

Le tableau devrait ressembler à celui ci-dessous.

Valider les modifications dans le dossier de travail

Enregistrez la définition la plus récente de la table Livre qui contient désormais deux colonnes supplémentaires dans le contrôle de code source du dossier de travail, comme indiqué ci-dessous.

Localisez le dossier de travail à l'aide de l'Explorateur Windows et ouvrez dbo.table.sql dans le bloc-notes pour voir le code.

Le dossier de travail contient la définition la plus récente du tableau et ne fournit aucune information sur la première forme du tableau.

Comme indiqué, c'est la limitation du dossier de travail que nous ne pouvons voir que la dernière version de la base de données qui est écrasée par des versions plus récentes, ne laissant ainsi aucune place pour retracer l'historique (modification de la base de données).

Pousser les modifications au contrôle de source Git (colonnes de stock et de prix)

Dans l'étape suivante, nous allons pousser les colonnes nouvellement ajoutées de la table vers le référentiel distant Git, comme indiqué ci-dessous.

Tracer les modifications de la base de données avec Git Source Control

Jusqu'à présent, nous avons effectué deux modifications principales de la base de données dans l'ordre suivant :

  1. Le livre table a été créée avec les colonnes BookId, Title et Author
  2. Les colonnes Prix et Stock ont ​​été ajoutées au Livre tableau

Il n'y a aucun moyen de voir la première modification lorsque chaque table de livre a été créée à l'origine à l'aide du dossier de travail.

Cependant, il est possible de voir tout l'historique des modifications de la base de données à l'aide de Git tant que nous avons poussé ces modifications vers Git Remote Repository.

Sur Azure DevOps, veuillez cliquer sur Pushes dans la barre de navigation de gauche pour voir les modifications historiques de la base de données.

Accédez à Commits pour afficher l'ordre des modifications de la base de données sous la forme de commits.

Cliquez sur le premier Commit a99df4b5 pour voir la première définition du Livre tableau.

Revenez en arrière et cliquez sur le commit suivant 6f863f0a pour voir les prochaines modifications de la base de données.

Toutes nos félicitations! Nous avons suivi avec succès les modifications de la base de données à l'aide du dossier de travail avec un contrôle de code source secondaire (Git).

Nous pouvons maintenant revenir à la première version de la table si vous le souhaitez ou continuer à ajouter d'autres objets de base de données.

Choses à faire

Vous pouvez désormais non seulement placer confortablement vos objets de base de données sous le contrôle de source du dossier de travail, mais également suivre toutes les modifications de la base de données en conservant l'historique de la base de données.

  1. Veuillez essayer de créer une autre base de données en liant le livre tableau avec le BookType table de telle manière que le BookTypeId clé primaire du BookType table est transmise en tant que BookTypeId colonne de clé étrangère dans le livre table et utilisez le contrôle de source du dossier de travail pour suivre les modifications de la base de données.
  2. Veuillez essayer de créer les montres base de données comme indiqué dans le premier diagramme de l'article et suivez les étapes en conservant l'historique des modifications de la base de données à l'aide du dossier de travail avec Git
  3. Veuillez essayer d'annuler les modifications mentionnées dans le premier diagramme de l'article lorsque Dev2 supprime accidentellement la Watch table créée par Dev1 à l'aide du dossier de travail pour suivre les modifications de la base de données.

Outil utile :

dbForge Source Control - puissant complément SSMS pour gérer les modifications de la base de données SQL Server dans le contrôle de source.