Cet article explique comment utiliser l'option de dossier de travail du contrôle de code source pour gérer les bases de données SQL Server.
Dans cet article, je souligne également certains des avantages et des limites de l'utilisation d'un dossier de travail par rapport aux autres options disponibles à utiliser avec le contrôle de code source.
Discutons de quelques concepts clés avant de plonger dans les détails techniques de cet article.
Concepts clés
Qu'est-ce que le contrôle des sources ?
Le contrôle de source est un système ou (une partie des meilleures pratiques logicielles) qui garde une trace de toutes les modifications apportées au code par les développeurs.
Pourquoi le contrôle des sources est-il nécessaire ?
Le code d'application écrit par les développeurs doit être sauvegardé de temps en temps de manière à ce que toutes les modifications apportées par un développeur puissent non seulement être retracées, mais également annulées si nécessaire.
Pour cette raison, le code de l'application est placé sous contrôle de code source pour s'assurer que l'historique de toutes les modifications ainsi que les commentaires sont bien conservés. De plus, l'utilisation du contrôle de code source présente de nombreux autres avantages, qui dépassent le cadre de cet article.
Contrôle de source contre contrôle de version
Il n'y a aucune différence entre le contrôle de code source et le contrôle de version et la plupart du temps ces deux termes sont utilisés librement de manière interchangeable.
Mettons-nous les bases de données sous contrôle de code source
Tout comme le code d'application, les objets de la base de données tels que les tables, les vues, les procédures stockées, etc. doivent également être contrôlés en version. Cependant, la méthode de mise sous contrôle de source des objets de base de données est légèrement et dans certains cas entièrement différente de celle utilisée pour placer le code de l'application sous contrôle de source.
Exemple de base de données de contrôle de version
Supposons que vous créez un exemple de base de données appelée "Voitures" selon les besoins de l'entreprise.
Ensuite, vous créez une table appelée "Car" avec le CarId et CarName colonnes pour répondre à une autre exigence.
En votre absence, un autre développeur est chargé d'ajouter le CarType colonne à la table "Voiture".
Il décide de supprimer le CarName pensant que ce n'est pas nécessaire et remplacez-le par le CarType colonne.
Vous revenez après un long moment et êtes surpris de voir que votre CarName non seulement la colonne est manquante, mais elle est également remplacée par le CarType colonne.
Maintenant, vous ne vous souvenez plus du type de données et de la longueur d'origine que vous avez choisis pour CarName sauf si vous passez par l'ensemble des exigences de l'entreprise.
Attendez une minute! Ce problème peut facilement être résolu si vous avez envisagé d'utiliser le contrôle de source pour votre base de données en premier lieu. Ensuite, vous pouvez facilement voir la première modification que vous avez apportée, qui contient la définition de la colonne, puis la deuxième modification effectuée par un autre développeur.
Ainsi, vous et l'autre développeur vous asseyez ensemble et parcourez les modifications historiques apportées à la base de données (objet) à l'aide du contrôle de code source qui garde une trace de chaque modification apportée par n'importe quel développeur sur la base de données.
Ceci est illustré comme suit :
Utilisation la plus importante du contrôle de code source
L'une des principales raisons d'utiliser le contrôle de code source est de pouvoir gérer plusieurs versions du code en même temps en créant les branches de code suivantes :
- Dev (branche développement)
- Test (branche Test)
- QA (branche QA)
- Prod (Branche Production)
Les détails techniques de la création des branches Dev, Test, QA et Production à partir du contrôle des sources dépassent le cadre de cet article.
Prérequis
Cet article est particulièrement adapté aux lecteurs qui remplissent les conditions suivantes :
Connaissance de base de T-SQL
Vous devez avoir des connaissances de base en T-SQL pour créer, interroger et modifier des objets de base de données tels que des tables, des vues et des procédures stockées.
Outils de développement de base de données
Vous devez avoir SSMS (SQL Server Management Studio) ou dbForge Studio pour SQL Server installé sur votre machine pour créer et gérer des bases de données et leurs objets.
Disponibilité de la source de données du dossier de travail
Bien que tout contrôle de source offrant l'option de dossier de travail convienne, il est recommandé d'utiliser dbForge Source Control pour suivre toutes les étapes de la procédure pas à pas de cet article.
Contrôle de la source du dossier de travail
Le dossier de travail avec des fonctionnalités limitées pour les objets de base de données de contrôle de version peut être utilisé comme d'autres systèmes de contrôle de source tels que TFS, Git, etc.
Un dossier de travail contient simplement des fichiers de script SQL utilisés pour créer et gérer des objets de base de données.
Quand utiliser le dossier de travail
Supposons que vous souhaitiez créer une base de données et ses objets associés à partir de zéro, mais que vous ne sachiez pas encore quel contrôle de source votre équipe utilisera finalement. Dans ce cas, il est préférable de commencer par l'option de contrôle de la source du dossier de travail.
Une autre raison peut être lorsque vous souhaitez simplement stocker l'état actuel de la base de données et que vous n'êtes pas intéressé par le suivi des modifications historiques, le dossier de travail est alors un bon candidat pour être utilisé comme contrôle de source.
Limitation du dossier de travail
Le dossier de travail vers les objets de la base de données de contrôle de version est limité en termes de conservation de la version la plus récente de la base de données et de ses objets et il n'y a aucun moyen de retracer les modifications ou de les annuler.
Par conséquent, vous devez être prudent lorsque vous utilisez le dossier de travail comme option de contrôle de source, car il ne peut pas vous montrer toutes les modifications apportées à la base de données et à ses objets de temps à autre.
Procédure :lier la base de données au dossier de travail
Passons en revue les étapes pour lier votre base de données à un dossier de travail à l'aide du contrôle de code source.
Conditions requises pour ajouter un livre et un type de livre
Vous avez reçu des exigences internes pour créer une base de données de test appelée "SQLBookShopV2" qui contient les deux tables suivantes :
- Réserver
- Type de livre
La base de données ne nécessite pas nécessairement un contrôle de source à ce stade et il n'est pas important de garder une trace de toutes les modifications apportées.
Vérifiez les exigences
Il est souvent recommandé de revérifier les exigences avant d'utiliser un dossier de travail. Un dossier de travail est plus adapté si on vous demande de créer une base de données avec les exigences suivantes :
- Une base de données de test ou un prototype de base de données est requis
- L'historique des modifications de la base de données n'est pas obligatoire
- La décision concernant le contrôle de code source qui sera finalement utilisé n'a pas encore été prise
Configurer le dossier de travail
La première étape consiste à réserver un dossier dans lequel résideront vos scripts de base de données de test après avoir commencé à vérifier le code de votre base de données dans le dossier de travail.
Créez un nouveau dossier appelé "Scripts SQLBookShopV2" sous le lecteur C.
Configurer la base de données exemple SQLBookShopV2
Ouvrez dbForge Studio pour SQL Server et dans le menu Base de données, cliquez sur "Nouvelle base de données":
Tapez "SQLBookShopV2" dans le nom de la base de données et cliquez sur le bouton "Appliquer les modifications" en bas de la fenêtre :
Lier la base de données au dossier de travail
Il est préférable de lier la base de données au contrôle de code source juste après sa création.
Faites un clic droit sur la base de données (SQLBookShopV2) et sélectionnez Source Control → Link Database to Source Control élément de menu :
Localisez le dossier de travail créé précédemment pour le lier à la base de données :
Vous pouvez choisir votre modèle de développement de base de données souhaité. Nous choisissons le modèle de développement de la base de données partagée :
Vérifiez la petite icône de contrôle de source à côté de la base de données qui confirme que la base de données a été correctement liée au contrôle de source du dossier de travail :
Créer un tableau de livres
Cliquez avec le bouton droit sur Tableaux puis cliquez sur Nouveau tableau et créez une table de livres en utilisant le code suivant et appliquez les modifications :
CREATE TABLE SQLBookShopV2.dbo.Book ( BookId INT IDENTITY ,BookTitle VARCHAR(50) NOT NULL ,Notes VARCHAR(200) ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ) GO
Valider les modifications du code de la base de données
Puisque nous avons créé une nouvelle table dans la base de données, ces modifications locales doivent être récupérées par le contrôle de code source pour être enregistrées.
Ouvrez le gestionnaire de contrôle des sources (qui affiche les dernières modifications à enregistrer) en cliquant avec le bouton droit sur la base de données, puis cliquez sur Source à Afficher le gestionnaire de contrôle de code source
Cliquez sur Valider pour archiver dans le contrôle source du dossier de travail :
Vérification du dossier de travail
Accédez à votre dossier de travail et consultez l'objet de table qui y est enregistré à la suite du dernier commit :
Créer une table BookType
Créez une autre table BookType en utilisant le code suivant :
CREATE TABLE SQLBookShopV2.dbo.BooKType ( BookTypeId INT IDENTITY ,Name VARCHAR(50) NULL ,Detail VARCHAR(200) NULL ,CONSTRAINT PK_BooKType_BookTypeId PRIMARY KEY CLUSTERED (BookTypeId) ) GO
Ajouter une table au contrôle de code source
Ajoutez la table nouvellement créée au contrôle de source en utilisant la même méthode que celle mentionnée précédemment, puis vérifiez le dossier de travail pour voir que les deux tables sont là :
Toutes nos félicitations! Vous avez lié avec succès votre base de données au contrôle de code source du dossier de travail.
Précautions pour le dossier de travail
N'oubliez pas qu'un dossier de travail dans sa forme pure en tant que contrôle de source est comme un dossier Windows ordinaire et s'il est modifié de l'extérieur, il ne peut plus se souvenir de son dernier état.
Par exemple, si nous supprimons le code Book.sql du dossier de travail, puis vérifions les modifications à l'aide de Source Control Manager, nous devrons ajouter à nouveau le code de la table Book dans le dossier de travail.
La responsabilité de sécuriser le dossier de travail repose sur les épaules des développeurs plutôt que sur le code source (dans sa forme originale) à moins que vous ne suiviez strictement la solution de contournement qui s'est avérée efficace.
Choses à faire
Vous pouvez désormais placer facilement vos objets de base de données à l'aide de l'option de contrôle de source du dossier de travail :
- 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 après avoir utilisé le contrôle de source du dossier de travail.
- Veuillez essayer de créer une procédure stockée appelée AddBook pour ajouter un nouveau livre au Livre table après avoir lié votre base de données avec le contrôle de source du dossier de travail.
- Veuillez essayer de créer une vue de base de données Livres pour voir la liste de tous les livres avec leurs types et vérifier toutes les modifications dans le contrôle source du dossier de travail.
Pour en savoir plus :
Suivi des modifications de la base de données à l'aide du contrôle de code source du dossier de travail
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.
