Codificar automáticamente los datos de una tabla SQL Server y el esquema del objeto directamente al control de versiones

Imagine un escenario donde usted desea enviar sus bases de datos al control de versiones rápida y fácilmente, incluyendo todos los objetos del esquema y los datos desde ciertas tablas de código que no cambiarán, también conocidas como datos Estáticos. Luego, una vez que haya trasladado su base de datos exitosamente al control de versiones, puede actualizar el repositorio en las noches con cualquiera o todos los objetos cambiados. De esta manera, usted ha añadido automáticamente su base de datos al control de versiones, sin tener que preocuparse acerca de la integración directa, las entradas, salidas, etc., esencialmente proveyendo mucho de las “ganancias” de la integración de la base de datos con el control de versiones, con poco del “costo”. Este artículo describirá cómo construir este sistema de integración de bases de datos SQL al control de versiones usando una herramienta de terceros, ApexSQL Script.

ApexSQL Script es una herramienta de codificación para bases de datos SQL que soporta los sistemas de control de versiones Subversion, Git, Team Foundation Server, Mercurial y Perforce.

ApexSQL Script provee la habilidad de codificar datos y estructuras de tablas SQL Server, o sólo unos pocos objetos deseados desde ahí, a cualquier sistema de control de versiones.

Idealmente, sólo los cambios deberían ser codificados y enviados al repositorio. La buena noticia es que ApexSQL Script es completamente capaz de enviar sólo los cambios (versus todos los objetos) así como objetos recién creados. De todos modos, los objetos borrados en la base de datos no serán automáticamente removidos desde el repositorio, y deberían ser removidos manualmente.

Nota: Para implementar un sistema que también remueve los objetos eliminados, sugerimos usar ApexSQL Diff.

Independientemente de la falta de soporte para objetos eliminados, ApexSQL Script aún puede ser usado para completar este caso de uso, y este artículo ayudará a ilustrar algunas de las funcionalidades de esta herramienta, tanto en la interfaz gráfica como en la línea de comandos.

En este ejemplo, vamos a codificar una base de datos a un control de versiones incluyendo:

1. Todos los objetos del esquema.
2. Datos para tablas estáticas como códigos zip, países, etc., que no cambiarán en el tiempo.

El sistema de control de versions que usaremos es Mercurial. Particularmente, usaremos un repositorio Mercurial hospedado en Bitbucket

Luego, mostraremos cómo automatizar la codificación al control de versiones, de modo que este trabajo pueda ser corrido de forma desatendida siguiendo un programa para actualizar periódicamente los objetos del esquema y añadir nuevos, pero dejando los datos estáticos sin cambios.

Descripción

1. Una vez que la aplicación haya iniciado, en el formulario New project , conéctese al servidor y seleccione la base de datos de la lista presentada en la conexión al servidor. Haga clic en el botónOpen :

   

2. Cambiando la vista de View a Structure, verifique los objetos deseados del esquema y sólo estos serán sujetos al proceso de enviarlos al control de versiones:

   

3. Cambiando la vista de View a Data, elija las tablas con datos que no cambiarán, también llamados Datos Estáticos:

   

4. Grabe el proyecto usando el comando Save desde la barra de herramientas principal. Para propósitos de este artículo, grabaremos el proyecto como MyDatabase.axsc:

   

5. Cuando los objetos deseados sean seleccionados, haga clic en el botón Script en la pestaña Home el formulario principal. Esto iniciará el asistente Scripting :

   

6. En el paso Scripting mode, establezca el modo de codificación y el tipo de salida que se necesita. Proceda haciendo clic en el botón Next :

   

7. En el siguiente paso, deseleccione la casilla Include dependent database objects si no desea incluir los objetos dependientes en el proceso de codificación:

   

8. En el último paso del asistente de codificación, en el paso Output file , los ajustes del control de versiones son presentados eligiendo la opción Create and commit to source control desde el menú desplegable Action , y haciendo clic en el botón Edit :

   

9. La configuración de dos pasos del Control de Versiones se presentará. En el primer paso, el sistema deseado de control de versiones debería ser seleccionado y, en el segundo paso, las credenciales del control de versiones, así como del repositorio y la carpeta de control necesitan ser provistas para proceder:

   

   

10. Una vez que todos los campos son llenados con la información requerida, establezca la aplicación para codificar cada objeto en un archivo individual Script each object into an individual file cambiando la opción Granularity debajo de la pestaña Script file:

    

11. En el paso final, haga clic en Create para iniciar el proceso de envío:

    

    Configurando la tarea de línea de comandos

    Para automatizar esto para que corra de manera desatendida siguiendo un programa, crearemos un archivo .BAT. El objetivo de esta automatización es actualizar los esquemas existentes de los objetos, que pueden haber cambiado, y también añadir nuevos objetos.

    Nota: Los objetos que pueden haber sido borrados tendrán que ser removidos desde el repositorio del control de versiones manualmente.

    Cuando sea hora de automatizar, vamos a hacer algunos cambios importantes:

    1. En lugar de codificar sólo los objetos seleccionados, configuraremos el archivo de lotes para codificar todos los objetos. De esa forma, nos aseguramos de que cualquier objeto nuevo participe en el trabajo y sea codificado automáticamente al control de versiones.
    2. No recodificaremos datos de tablas SQL Server, por ejemplo, datos estáticos, dado que estos datos son por definición estáticos, y no cambiarán.
    3. Suministraremos un comentario dinámicamente generado para cada carga con una marca de tiempo.
    4. Suministraremos una etiqueta dinámicamente generada para cada carga con marca de tiempo.

    Primero, para simplemente volver a correr este proyecto vía línea de comandos, usted puede usar este script:

    ApexSQLScript.com
    /pf:MyDatabase.axsc	# cargar un archivo de proyecto
    /v	# habilitar registro detallado
    /m:structure	# seleccionar solo estructura para codificación
    /sctype:mercurial	# especifica el sistema de control de versiones
    /scsrv:”https:user@bitbucket.org /user/mydatabase”	# especifica la ruta al repositorio
    /scusr:user	# especifica el nombre del usuario para el control de versiones
    /scpwd:#####	# especifica la contraseña para el control de versiones
    /scprj:$	# especifica la ruta al proyecto
    /sccmt:”Committed using ApexSQL Script %DATE% %TIME%”	# añade comentarios con marca de tiempo para archives enviados

    Después de correr el siguiente comando, el resultado es como sigue:
    
    ApexSQL Script 2016.01, (C)2016 ApexSQL LLC
    Loading project…
    Loading project MyDatabase.axsc
    Set scripting mode:both
    Script each object to an individual file
    …
    Creating script for Tables: Culture
    Creating script for Tables: AddressType
    Scripting data for Table: Culture
    Scripting data for Table: AddressType
    Script processing to source control…
    File(s) checked in to Mercurial
    Labeling ‘ApexSQLSCriptLabel_Wed_03/23/2016_12_57_24.01’…OK

    En el caso de que todo haya finalizado sin errors, el mensaje Files checked in to Mercurial será mostrado en la última línea de descripción detallada junto con el nombre de la etiqueta (incluyendo la marca de tiempo) especificada en el comando de línea de comandos.

12. Los resultados de la codificación pueden ser revisados directamente en el repositorio.

    

    Note que cualquier dato de tabla SQL Server codificado en este proceso será enviado como Dato Estático. También, los comentarios incluyen la fecha y la marca de tiempo como se especifica en el comando de la línea de comandos. La etiqueta estará disponible en el repositorio:

    

    Para correr este script para tomar sólo objetos cambiados, incluyendo cualquiera nuevo que haya sido añadido, pero evitando recodificar datos estáticos, use este ejemplo:

    ApexSQLScript.com
    /pf:MyDatabase.axsc	# Cargar un archivo de proyecto
    /v	# Salida detallada de consola
    /m:both	# incluye estructura y datos para codificar
    /sctype:mercurial	# especifica el sistema de control de versiones
    /scsrv:”https:u@bitbucket.org /u/mydatabase”	# especifica la ruta al repositorio
    /scusr:user	# especifica el nombre de usuario para el control de versiones
    /scpwd:#####	# especifica la contraseña para el control de versiones
    /scprj:$	# especifica la ruta del proyecto ($ es la raíz del repositorio)
    /scwfd:C:\WF	# carpeta de trabajo en la máquina local
    /in	# codificar cada objeto como un archivo separado
    /sclbl:”ApexSQLSCriptLabel_ %DATE: =_%_%TIME::=_%»	# especifica una eqtiqueta, incluyendo la marca de tiempo
    /sccmt:”ApexSQL Script commit %DATE% %TIME%”	# Mensaje de envoi con marca de tiempo
    /nfsh	# excluye las cabeceras de objetos de la codificación

    Note que el comentario dinámicamente marcado con la fecha (/sccmt:”Committed using ApexSQL Script %DATE% %TIME%”) y la etiqueta (/sclbl:”ApexSQLSCriptLabel_%DATE: =_%%TIME::=_%») son suministrados y que estas variables son mostradas como parte del resultado.

    También note que /nfsh (también llamado /no_format_scr_header) necesitará ser usado para suprimir la cabecera, lo cual causará que todos los objetos sean codificados, sin importar si fueron cambiados o no. Este problema será resuelto en la siguiente versión.

Haga clic aquí para ver la documentación completa de ApexSQL Script CLI.

Para recrear luego los objetos del esquema y los datos estáticos desde el control de versiones de vuelta a una base de datos existente, recomendamos que use ApexSQL Build.

Preguntas Frecuentes

P: ¿Se creará una nueva versión del objeto a ser creado en el control de versiones cada vez, incluso si no lo cambié, o el sistema de control de versiones será suficientemente inteligente para detectar sólo los objetos cambiados?

R: No, una nueva versión de un objeto no será creada si no hay cambios. Esto es hecho añadiendo el interruptor /nfsh.

P: ¿Qué pasa si vuelvo a correr el proyecto con la misma etiqueta? ¿Causará esto un error desde el sistema de control de versiones?

R: La tarea no finalizará exitosamente y el siguiente error aparecerá en la descripción detallada:

Script processing to source control…
Labeling ‘Label1’…Error:
There was an error when labeling scripts folder. Source control error: Label ‘Label1’ already exists. Specify other name