SQL Server Data Tools – una descarga autónoma o/y un complemento para Visual Studio, viene en diferentes sabores y versiones. Aunque este artículo usa Visual Studio 2012 y SSDT autónomo, los principios expuestos son también válidos en Visual Studio 2013.
Como sabe, SSDT son herramientas de desarrollo Microsoft para trabajar con bases de datos SQL Server en el mismo recinto o en la nube. Reemplaza a Management Studio en funcionalidad de desarrollo añadiendo el poderoso IDE Visual Studio para beneficio de los desarrolladores que, por muchos años, estuvieron estancados con SQL Server Management Studio.
Cuando SQL Server 2012 fue lanzando, SSDT también fue lanzado y desde entonces muchas versiones han sido publicadas, no necesariamente siguiendo el patrón de lanzamientos de SQL Server.
Para cada lanzamiento, algunas nuevas características son añadidas. Algunas aún faltan pero probablemente llegarán en un lanzamiento posterior.
Por otro lado, Team Foundation Server ha estado presente por bastante tiempo. Team Foundation Server es la plataforma de colaboración en el núcleo de la solución de administración del ciclo de vida de la aplicación (application lifecycle management, ALM) de Microsoft. TFS soporta prácticas de desarrollo ágiles, múltiples IDEs y plataformas localmente o en la nube y le da las herramientas que usted necesita para administrar efectivamente los proyectos de desarrollo de software a través del ciclo de vida de IT.
Recuerde: Para SSDT en Visual Studio 2012 necesitará TFS Express 2012. Si usted tiene SSDT 2013 usted necesitará TFS Express 2013. ¡Las versiones no se pueden mezclar!
En este artículo, vamos a enfocarnos en la interacción entre SSDT y TFS. Desarrollar localmente y publicar los cambios a una instancia en el mismo recinto de SQL Server. Veremos cómo podemos hacer integración continua entre desarrollo y otros ambientes enviando los cambios de esquema y actualizando los números de versión en una manera apropiada luego de la construcción exitosa de la solución.
Para más información acerca de TFS, por favor lea lo siguiente: TFS overview
Yo estoy usando la versión gratis de TFS llamada TFS Express, la cual puede ser instalada localmente. Es apropiada sólo para proyectos pequeños y está limitada a cinco usuarios concurrentes. Descárguela aquí.
Para crear una solución Visual Studio Online y más información acerca de Visual Studio Online, haga clic aquí
En y fuera del recinto
Al momento de escribir, no es posible tener Visual Studio Online (VSO) desplegado en una instancia local de SQL Server ya que VSO no puede “ver” sus SQL Servers en el mismo recinto. Incluso con un Hosted Build Controller.
El escenario
Yo soy un desarrollador de bases de datos y estoy trabajando en una base de datos Azure SQL existente que necesita algunos cambios. Tengo algunas tablas simples y necesito añadir un procedimiento almacenado para crear el ranquin de clientes y una tabla para mantener el ranquin de clientes. El ranquin debería ser calculado de acuerdo a cuándo ha comprado el cliente.
| Nombre de Rango | Descripción |
| Inactive | Sin órdenes |
| Bronze | Órdenes debajo de $100 |
| Silver | Órdenes entre $100 y $999 |
| Gold | Órdenes entre $1000 y $9999 |
| Platinum | Órdenes de $10000 o más |
Procedimiento Almacenado:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
CREATE PROCEDURE [dbo].[uspRankCustomers] AS DECLARE @CustomerId int DECLARE @OrderTotal money DECLARE @RankingId int DECLARE curCustomer CURSOR FOR SELECT c.CustomerID, ISNULL(SUM(oh.OrderTotal), 0) AS OrderTotal FROM dbo.Customer AS c LEFT OUTER JOIN dbo.OrderHeader AS oh ON c.CustomerID = oh.CustomerID Group BY c.CustomerId OPEN curCustomer FETCH NEXT FROM curCustomer INTO @CustomerId, @OrderTotal WHILE @@FETCH_STATUS = 0 BEGIN IF @OrderTotal = 0 SET @RankingId = 1 ELSE IF @OrderTotal < 100 SET @RankingId = 2 ELSE IF @OrderTotal < 1000 SET @RankingId = 3 ELSE IF @OrderTotal < 10000 SET @RankingId = 4 ELSE SET @RankingId = 5 UPDATE Customer SET RankingId = @RankingId WHERE CustomerId = @CustomerId FETCH NEXT FROM curCustomer INTO @CustomerId, @OrderTotal END CLOSE curCustomer DEALLOCATE curCustomer GO |
Creando el proyecto
Crear un proyecto desde una base de datos existente en SSDT es fácil.
En otro artículo mostraré detalladamente las diferentes maneras de trabajar con bases de datos nuevas y existentes pero ahora importemos una base de datos existente en nuestro proyecto.
- Cree un nuevo proyecto SQL Server Database
- Haga clic derecho en el nombre del proyecto -> Import -> Import database
- Cree una nueva conexión al servidor (o use una existente, si existe)
- Elija la base de datos a importar
- Deje las demás configuraciones como están
Después de unos pocos segundos, la importación debería estar completa
Figura 2: Importación de base de datos completa
Lo primero que siempre hago cuando trabajo con una base de datos existente es tomar una línea de base para la solución. Así que tengo un estado inicial de la base de datos al que puedo eventualmente volver cuando trabaje en ella. Esto es hecho haciendo clic derecho en la base de datos y eligiendo snapshot project. Se generará un archivo dacpac conteniendo el esquema de la base de datos recién importada. Usualmente llamo al archivo “baseline” y dejo el timestamp de manera que sepa cuándo fue creado.
Añadiendo la solución a Visual Studio Online
Ahora necesito añadir la base de datos al proveedor de Control de Versiones, en este caso Visual Studio Online.
- Elijo Team -> Connect to Team foundation Server and connect to my Visual Studio online project folder
- Ahora puedo elegir Choose File -> Source Control -> Add to source control
- Y todos mis elementos deberían ser añadidos (pero no protegidos)
- Proteja su contribución ahora para grabar todos los elementos en el repositorio de control de versiones
Implementando los cambios
Ahora que he terminado puedo implementar los cambios necesarios a la base de datos, añadiendo la tabla de ranquin, el procedimiento almacenado y efectuando los cambios a la tabla de clientes de modo que referencie a la tabla de ranquin.
|
1 |
CONSTRAINT [FK_Customer_customerRanking] FOREIGN KEY (RankingID) REFERENCES [customerRanking]([Id]) |
También añado datos a la tabla CustomerRanking como se describe en el escenario anterior.
También hay otra tabla que creo que es importante añadir: Deployment. La idea detrás de esta tabla es dar seguimiento a todos los despliegues que he hecho, usando un script posterior al despliegue que siempre es ejecutado cuando realizo mi integración continua.
|
1 2 3 4 5 6 |
CREATE TABLE [dbo].[Deployment] ( [Id] INT NOT NULL IDENTITY(1,1), [DeploymentDate] DATETIME NOT NULL, CONSTRAINT [PK_Deployment] PRIMARY KEY ([Id]) ) |
Ahora que he hecho mis cambios puedo compilar mi proyecto (necesariamente antes de tomar una instantánea), tomar una instantánea de mi base de datos, llamarla “change_complete” y dejar el timestamp como está.
Crear un perfil de despliegue
Antes de que pueda desplegar necesito crear un perfil que le diga a Visual Studio dónde desplegar luego de la compilación exitosa.
- Haga clic derecho en el proyecto y elija Publish
- Escriba el nombre del servidor y el nombre de la base de datos donde debería desplegarse (en mi ejemplo ContinuousIntegrationINT), pero también puede ser en Azure u otros lugares
- No publique, sino grabe el perfil y dele un nombre significativo
- Cierre el diálogo sin publicar
Si usted está conectado usando un nombre de usuario y contraseña usted necesita editar manualmente el archivo de perfil de publicación después, ya que la contraseña no es grabada
Figura 3: Crear un perfil de despliegue
Implementando la integración continua
La idea es tener la base de datos desplegada cada vez que protejo el código fuente. Al mismo tiempo quiero que la tabla de despliegue haga seguimiento de los despliegues.
Para lograr eso, inicio creando un script de post despliegue:
- Clic derecho en el proyecto -> Add -> New ítem -> Post-deployment script (en la categoría User script)
Añada algo de SQL para incrementar la versión de despliegue y también para popular la tabla CustomerRanking y toda otra tabla que necesite datos.
12345678910insert into Deployment (DeploymentDate) values (getdate())if(select count(*) from CustomerRanking) = 0beginINSERT INTO [dbo].[CustomerRanking] ([Id], [Name], [Description]) VALUES (1, N'Inactive ', N'No orders ')INSERT INTO [dbo].[CustomerRanking] ([Id], [Name], [Description]) VALUES (2, N'Bronze ', N'Orders under $100 ')INSERT INTO [dbo].[CustomerRanking] ([Id], [Name], [Description]) VALUES (3, N'Silver ', N'Orders $100 to $999 ')INSERT INTO [dbo].[CustomerRanking] ([Id], [Name], [Description]) VALUES (4, N'Gold ', N'Orders $1,000 to $9,999 ')INSERT INTO [dbo].[CustomerRanking] ([Id], [Name], [Description]) VALUES (5, N'Platinum ', N'Orders $10,000 and more ')EndListado 4: Script post despliegue
Para modificar las opciones de despliegue vaya a la pestaña Source Control explorer y añada una nueva definición de build.
Esta es la página donde usted puede controlar qué pasa durante la compilación.
Lo que queremos aquí es decirle a Visual Studio que use msbuild para desplegar la base de datos en builds exitosos. Esto se hace así:
En la página Trigger, elija Continuous Integration
Figura 5: opción Continuous Integration - En la página de proceso asegúrese de que el proyecto es listado en la propiedad Items to Build
En la página de proceso yo añado los argumentos de compilación necesarios
Figura 6: Página de proceso
Los argumentos necesarios para este argumento son:
- /t:build (compila el código)
- /t:publish (publica el código usando el archivo de publicación)
- /p:SqlPublishProfilePath (la ruta del archivo de publicación – relativa al proyecto)
Así que en mi caso los argumentos (separados por espacios) serían:
/t:build /t:publish /p:SqlPublishProfilePath=ContinuousIntegrationINT.publish.xml
¡Ya está listo!
Grabe la configuración del nuevo build. Cada vez que se proteja el código se debería desencadenar una compilación y una publicación a la base de datos especificada en el archivo de publicación.
La próxima vez que proteja su código, su definición de build debería compilar el proyecto:
El menú Build en Team Explorer debería mostrar el build actual:
Y finalmente el registro del Build debería mostrar el progreso y el estado:
Finalmente la base de datos especificada en su archivo de Publicación (ContinuousIntegrationINT) debería ser creado cuando usted lo especifique y el esquema copiado y su script post despliegue ejecutado de modo que la tabla Deployment debería mostrar los datos del despliegue.
En el siguiente artículo mostraré cómo hacer pruebas de unidad a su proyecto de base de datos SSDT. Mientras tanto: ¡Feliz despliegue!
Traductor: Daniel Calbimonte
Sus antecedentes y experiencia de trabajo mezclan tecnología y negocios, proveyéndole una ventaja única para contribuir a proyectos de almacenes de datosy SharePoint, pudiendo interactuar efectivamente con tomadores de decisiones técnicos y de negocios.
Régis es un expositor frecuente en conferencias de SQL Server y es un miembro de Danish SQL Server User Group y el fundador del evento comunitarioSQL Saturday Denmark.
En abril de 2014 Régis recibió el galardón de MVP para SQL Server por su involucramiento en el producto y la comunidad.
View all posts by Régis Baccaro
- Pruebas de unidad con SQL Server Data Tools - December 24, 2016
- Integración Continua con SQL Server Data Tools y Team Foundation Server - December 4, 2015