SQL Server & Git Lifecycle

Guía técnica detallada para la gestión profesional de esquemas de bases de datos como código respaldado en GIT.

1. Configuración del Entorno SSDT

Para tratar una base de datos como código fuente, Visual Studio requiere el componente SQL Server Data Tools (SSDT). Este conjunto de herramientas transforma el SQL imperativo en un modelo declarativo que Git puede entender.

  • Visual Studio Installer: Seleccione "Modificar" y en la pestaña de Cargas de Trabajo, habilite Data storage and processing.
  • Capacidades: Instala el motor de MSBuild específico para SQL, permitiendo validar la integridad referencial (claves foráneas, dependencias de vistas) sin necesidad de una base de datos activa.
📖 Documentación: Instalación y Requisitos de SSDT

2. Estructura del Proyecto de Base de Datos

El SQL Server Database Project define el "estado deseado" de la base de datos. A diferencia de un script .sql plano, el proyecto organiza los objetos jerárquicamente.

  • Target Platform: Es vital definirla en Properties > Project Settings. Esto instruye al compilador sobre qué sintaxis de T-SQL es válida (ej. SQL Server 2022 vs Azure SQL).
  • Ubicación: Debe residir dentro de un repositorio Git para rastrear el historial de cambios en tablas, procedimientos y funciones.
📖 Documentación: Creación de Proyectos de DB

3. Importación de DB (Import Schema)

Este proceso convierte una base de datos física existente en un conjunto de archivos .sql individuales. VS analiza el catálogo del sistema y genera un archivo por cada objeto.

  • Proceso: Click derecho en Proyecto > Import > Database. Al conectarse, VS extrae la definición de tablas, triggers, vistas y permisos.
  • Resultado: Una estructura de carpetas organizada por esquemas (ej. dbo/Tables/), lo cual facilita la revisión de cambios en Git al evitar archivos gigantes de miles de líneas.

4. Desarrollo y Validación (Build)

El desarrollo profesional se divide en dos flujos que deben converger en el proyecto:

💻 Offline First (Seguro)

Se modifica el archivo .sql directamente en VS. El beneficio principal es la validación estática: el Build fallará si eliminas una columna que una vista está utilizando.

Dirección: En este caso el proyecto local debe ser el Source y la DB el Target Vea punto 5. Schema Comparison

⚡ Live DB First (Rápido)

Se edita en SSMS. Útil para depurar procedimientos en tiempo real. Este flujo requiere obligatoriamente una sincronización posterior con el proyecto mediante Schema Compare.

Dirección: En este caso la DB debe ser el Source y el proyecto local el Target Vea punto 5. Schema Comparison

Importante: Siempre ejecute Build Solution. Si el proyecto no compila, no debe realizarse el Commit a Git.

5. Sincronización (Schema Compare)

Es la herramienta de "diff" entre el mundo físico y el mundo del código. Compara el modelo del proyecto contra la base de datos viva.

  • Source vs Target:
    • Si modificó la DB en SSMS, el Source es la DB y el Target es el Proyecto. Tras comparar, presione Update para que los cambios se escriban en sus archivos locales.
    • Si modificó la DB en el Proyecto, el Source es el Proyecto y el Target es la DB. Tras comparar, presione Update para que los cambios se escriban en la DB.
  • Detección de Deriva: Permite identificar cambios no autorizados realizados directamente en el servidor que no están reflejados en el control de versiones.
Importante: Debe asegurar que el Source y Target sean los indicados para la actualización que está aplicando. De lo contrario, podría perder cambios o aplicar cambios incorrectos en la DB.
📖 Documentación: Uso Avanzado de Schema Compare

6. Control de Versiones (Git Lifecycle)

Una vez que los archivos .sql del proyecto están actualizados, Git entra en juego para proporcionar auditoría y colaboración.

  • Git Changes: VS muestra los archivos modificados. Es vital realizar un Double-Click para ver el Diff visual y confirmar que no se están subiendo cambios accidentales.
  • Atomicidad: Realice Commits descriptivos (ej. "refactor: normalización de tabla Clientes") para que el historial del esquema sea legible.
📖 Documentación: Git en Visual Studio

7. Estrategias de Despliegue (Publishing)

El despliegue en SSDT es una sincronización basada en estado. El motor utiliza el archivo .dacpac (modelo compilado del proyecto) y lo compara con la base de datos de destino para calcular las diferencias.

7.1 Métodos de Publicación

🚀 Publicación Directa

Ideal para Desarrollo o QA. VS genera el plan de actualización en memoria y lo ejecuta inmediatamente contra el servidor.
Riesgo: No hay revisión previa de los scripts generados.

📜 Generación de Script

Estándar para Producción. VS crea un archivo .sql con los comandos ALTER, CREATE o DROP necesarios. Permite una revisión manual antes de la ejecución.

7.2 Automatización con SqlPackage.exe

Para entornos de CI/CD, se utiliza la línea de comandos para automatizar el despliegue del artefacto .dacpac:

SqlPackage.exe /Action:Publish /SourceFile:"C:\Repo\DB.dacpac" /TargetConnectionString:"Server=Prod;Database=DB_Client;..."

7.3 Opciones Críticas (Advanced Settings)

Opción Descripción Técnica Recomendación
Block publish on data loss Detiene el despliegue si una operación puede causar pérdida de datos. Activado en PROD.
Drop objects in target not in source Elimina de la DB física objetos que no existen en el proyecto VS. Usar con precaución.
Exclude Object Types Ignora tipos de objetos específicos (ej. Permisos o Usuarios). Útil para mantener roles locales.
📖 Documentación: Publicación y Despliegue de Esquemas