Este artículo habla sobre un nuevo método para controlar la versión de una base de datos utilizando una carpeta de trabajo para que se puedan rastrear los cambios históricos realizados en la base de datos.
Resumen
Dado que este artículo se basa en el nuevo enfoque para controlar la fuente de una base de datos al superar la limitación de la carpeta de trabajo, es mejor obtener una comprensión básica de la carpeta de trabajo y cosas relacionadas.
Antecedentes
La carpeta de trabajo, cuando se usa como control de código fuente, tiene la limitación de que no puede mantener el historial de cambios en la base de datos. Pero en este artículo, nos vamos a centrar en el método de usar un control de fuente secundario (detrás de escena) con una carpeta de trabajo que puede superar la limitación.
Requisitos previos
Este artículo asume que los lectores están familiarizados con los conceptos básicos del control de versiones de la base de datos usando Working Folder y Git junto con una comprensión de Visual Studio Team Services (VSTS), que ahora se llama Azure DevOps.
Se recomienda utilizar los siguientes conjuntos de herramientas para ejecutar todos los pasos mencionados en este artículo:
- dbForge para SQL Server
- Control de código fuente de dbForge
- Git para Windows (o cualquier cliente de Git)
- Azure DevOps (antes VSTS)
Este artículo también asume que se registró con Azure DevOps y ya obtuvo una cuenta, o puede registrarse y crear una nueva cuenta ahora si desea seguir todos los pasos de este artículo.
Alternativamente, cualquier control de código fuente que ofrezca la opción Carpeta de trabajo se puede usar con SSMS (SQL Server Management Studio), siempre que tenga las habilidades necesarias para adoptar el enfoque conceptual de este artículo y ponerlo en práctica.
Referencia
Para desarrollar una comprensión básica del uso de la carpeta de trabajo para la base de datos de control de código fuente, consulte mi artículo anterior haciendo clic en el siguiente enlace:
Uso de la carpeta de trabajo para la base de datos de control de fuente en pasos simples
Limitación de la carpeta de trabajo
Primero debemos comprender la limitación de usar la Carpeta de trabajo para controlar la fuente de una base de datos. Si ha leído mi artículo anterior, ya conoce la limitación.
Escenario de carpeta de trabajo
Si observamos de cerca los siguientes pasos, podemos entender fácilmente cómo la opción de control de fuente de la carpeta de trabajo está limitada cuando se trata de versiones de la base de datos:
- Dev1 crea una nueva base de datos sobre relojes de pulsera y la llama Relojes según el requisito.
- Dev1 además crea una nueva tabla y la llama Watch con Id de reloj y Nombre del reloj columnas según el requisito.
- No se le ha pedido a Dev1 que use ningún control de fuente en particular y el proyecto en sí está en la fase de prueba de desarrollo, por lo que decide usar el control de fuente Carpeta de trabajo.
- Se le ha pedido a Dev2 que cree una nueva tabla DigitalWatch con ID de reloj digital columna para que elimine el Reloj mesa pensando que con el DigitalWatch mesa el Reloj la tabla ya no es necesaria.
- No hay forma de revertir los cambios realizados por Dev2 y crear el Watch usando el control de fuente de la carpeta de trabajo una vez más porque la carpeta de trabajo acaba de obtener la última versión del código de la base de datos.
Esto se ilustra de la siguiente manera:
Uso de la carpeta de trabajo para realizar un seguimiento de los cambios en la base de datos
Hay una manera de hacer cumplir la Carpeta de trabajo para realizar un seguimiento de los cambios en la base de datos que puede ayudarnos a restaurar los objetos perdidos de la base de datos, aunque el uso de la Carpeta de trabajo de forma predeterminada no mantiene el historial de cambios en la base de datos.
Uso de control de código fuente secundario (Git)
Esto se puede lograr mediante el uso de un control de código fuente secundario junto con la opción Carpeta de trabajo, que es un poco complicada de administrar pero funciona bien.
Vamos a utilizar Git como el control de código fuente secundario con la carpeta de trabajo en este artículo.
Git es un sistema de control de versiones distribuido y también uno de los controles de código fuente más utilizados en la actualidad.
¿Por qué Git con la carpeta de trabajo?
Uno podría argumentar por qué necesitamos usar Git junto con Working Folder cuando podemos usar directamente Git con dbForge Studio para SQL Server para controlar la versión de nuestra base de datos.
La respuesta es comprender la naturaleza flexible de la opción de control de fuente de la carpeta de trabajo junto con explorar el potencial adicional para continuar con la carpeta de trabajo en lugar de usarla simplemente como una solución temporal.
Descargue cualquier cliente de control de código fuente de Git o Git para Windows
Antes de continuar, instale cualquier cliente de Git Source Control de su elección que nos ayudará a guardar los cambios en la base de datos con el tiempo.
El tutorial de este artículo utiliza Git para el cliente de Windows.
Instale Git para Windows con las opciones de su elección, hemos usado las opciones predeterminadas para instalar Git para Windows.
Crear un proyecto de Azure DevOps usando Git
Inicie sesión en su cuenta de Azure DevOps y cree un nuevo proyecto SQLBookShopV3-Using-Working-Folder-with-Git y elige el Git Opción de control de fuente para crear un repositorio privado de la siguiente manera.
Ir a Repos en la barra de navegación izquierda y copie el enlace Repo (repositorio Git) haciendo clic en el icono del portapapeles junto al enlace.
El plan es crear un repositorio local basado en el enlace Git Repo y luego potenciar la Carpeta de trabajo a través de esto.
Crear carpeta de trabajo en Git Local Repos
Si ya tiene la carpeta Git Local Repos, cree su carpeta de trabajo SQLBookShopV3-Working-Folder-with-Git allí:
C:\Users\
Alternativamente, cree los Repos carpeta en cualquier lugar de su elección y luego cree la subcarpeta SQLBookShopV3-Working-Folder-with-Git.
Crear nuevo repositorio local de Git
Ahora vamos a crear un repositorio Git local para que la carpeta de trabajo quepa en él.
Abra la GUI de Git que debería estar presente después de Git para Windows instalación.
Cree el repositorio local eligiendo Crear nuevo repositorio opción.
Crear Git Local Repo (Repositorio).
El repositorio Git local se ha creado correctamente.
Vincular el repositorio Git remoto con el repositorio local
Crear un repositorio local de Git no es suficiente, lo hemos vinculado con nuestro repositorio remoto de Git creado a través de Azure DevOps.
Vincule Remote Git Repo con Git Local Repo seleccionando Remote del menú principal y luego haciendo clic en Agregar nuevo control remoto y luego escriba la ubicación de su proyecto Azure DevOps.
Crear base de datos SQLBookShopV3
Abra dbForge Studio para SQL Server y cree una nueva base de datos SQLBookShopV3 .
Crear tabla de libros
Crear el Libro tabla con las columnas BookId, Title y Author de la siguiente manera.
CREATE TABLE SQLBookShopV3.dbo.Book ( BookId INT IDENTITY ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ,Title VARCHAR(100) ,Author VARCHAR(50) ) GO
Vincular base de datos con control de fuente de carpeta de trabajo
En el siguiente paso, vamos a vincular la base de datos al control de código fuente de la carpeta de trabajo.
Haga clic derecho en la base de datos (SQLBookShopV3) y seleccione Control de fuente y luego Vincular la base de datos al control de código fuente .
A continuación, busque la carpeta de trabajo creada anteriormente para vincularla con la base de datos.
Confirmar cambios en la carpeta de trabajo
Vaya a Administrador de control de código fuente y comprobar (Commit ) el Libro recién creado tabla en el control de fuente Carpeta de trabajo.
Revisa la Carpeta de Trabajo para ver el Libro mesa allí.
Insertar cambios en el control de código fuente de Git (tabla de libros)
Abra la GUI de Git nuevamente y haga clic en Volver a escanear botón que debería mostrar el objeto de la tabla ahora, agregue las siguientes confirmaciones iniciales:
Confirmación inicial (la tabla Libro creada la primera vez)
Luego siga los siguientes pasos:
- Cambios de etapa
- Confirmar cambios
- Empujar (Cambios)
Alternativamente, puede usar Git Bash para ejecutar Git desde la línea de comando.
Ver cambios comprometidos con Git Source Control
Vaya a Azure DevOps página web, siempre que ya haya firmado y el proyecto SQLBookShopV3-Using-Working-Folder-with-Git está activo.
Haga clic en Repos en la barra de navegación izquierda para ver los cambios que se acaban de enviar a Git Source Control.
A continuación, compruebe el guión de la tabla.
Agregar columnas de existencias y precios
Ahora agregue dos columnas más Stock y Precio al Libro tabla utilizando el siguiente 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 tabla debería verse como se muestra a continuación.
Confirmar cambios en la carpeta de trabajo
Guarde la definición más reciente de la tabla Libro, que ahora contiene dos columnas adicionales en el control de código fuente de la carpeta de trabajo, como se muestra a continuación.
Ubique la Carpeta de trabajo con el Explorador de Windows y abra dbo.table.sql en el bloc de notas para ver el código.
La carpeta de trabajo contiene la definición más reciente de la tabla y no proporciona ninguna información sobre la primera forma de la tabla.
Como se discutió, esta es la limitación de la Carpeta de trabajo de que solo podemos ver la última versión de la base de datos que se sobrescribe con versiones más nuevas, por lo que no deja espacio para rastrear el historial (de cambios en la base de datos).
Enviar cambios a Git Source Control (columnas de acciones y precios)
En el siguiente paso, enviaremos las columnas de la tabla recién agregadas al repositorio remoto de Git, como se muestra a continuación.
Rastrear los cambios de la base de datos con Git Source Control
Hasta ahora, hemos realizado dos cambios principales en la base de datos en el siguiente orden:
- El Libro la tabla se creó con las columnas BookId, Title y Author
- Las columnas Precio y Stock se agregaron al Libro mesa
No hay forma de ver el primer cambio cuando la tabla Libro se creó originalmente usando la Carpeta de trabajo.
Sin embargo, es posible ver todo el historial de cambios en la base de datos utilizando Git siempre que hayamos enviado esos cambios al repositorio remoto de Git.
En Azure DevOps, haga clic en Inserciones. en la barra de navegación izquierda para ver los cambios históricos de la base de datos.
Vaya a Confirmaciones para ver el orden de los cambios en la base de datos en forma de confirmaciones.
Haga clic en el primer Confirmar a99df4b5 para ver la primera definición del Libro mesa.
Regrese y haga clic en la siguiente confirmación 6f863f0a para ver los próximos cambios en la base de datos.
¡Felicidades! Hemos rastreado con éxito los cambios en la base de datos utilizando la carpeta de trabajo con un control de código fuente secundario (Git).
Ahora podemos volver a la primera versión de la tabla si lo deseamos o continuar agregando más objetos de la base de datos.
Cosas que hacer
Ahora puede colocar cómodamente no solo los objetos de su base de datos bajo el control de origen de la carpeta de trabajo, sino también realizar un seguimiento de todos los cambios de la base de datos mediante el mantenimiento del historial de la base de datos.
- Intente crear otra base de datos vinculando el Libro tabla con el BookType tabla de tal manera que el BookTypeId clave principal del BookType la tabla se pasa como BookTypeId columna de clave externa en el Libro tabla y use el control de origen de la carpeta de trabajo para realizar un seguimiento de los cambios en la base de datos.
- Intente crear los Relojes base de datos como se ve en el primer diagrama del artículo y siga los pasos manteniendo el historial de cambios de la base de datos usando Carpeta de trabajo con Git
- Intente revertir los cambios mencionados en el primer diagrama del artículo cuando Dev2 elimine accidentalmente el Reloj. tabla creada por Dev1 utilizando Carpeta de trabajo para realizar un seguimiento de los cambios en la base de datos.
Herramienta útil:
dbForge Source Control:potente complemento de SSMS para administrar los cambios de la base de datos de SQL Server en el control de fuente.
