Descripción general de la generación e implementación de bases de datos

Para crear una base de datos o publicar las actualizaciones de una base de datos existente del proyecto de base de datos en un servidor de bases de datos, debe compilar el proyecto de base de datos y, a continuación, implementarlo en ese servidor.

El paso de compilación compila el proyecto de base de datos en los archivos que se usan para la implementación. Entre ellos, se encuentra el archivo .dbschema, el archivo .deploymentmanifest y los scripts anteriores y posteriores a la implementación. Cuando se compila el proyecto de base de datos, no se realiza ninguna comparación con la base de datos de destino. Al implementar el proyecto de base de datos, el resultado de la acción de compilación se compara con la base de datos de destino, si existe, y se identifican las acciones que se requieren para actualizar el destino de manera que coincida con el proyecto de base de datos. En función de los valores de configuración, las actualizaciones se implementan en la base de datos de destino.

Como alternativa, puede generar el script de implementación (un archivo .SQL) y modificarlo antes de implementarlo en un almacenamiento provisional o servidor de producción utilizando el Editor de Transact-SQL u otra herramienta como SQL Server Management Studio. La acción de limpieza de la compilación elimina los artefactos de compilación existentes, como los scripts, los manifiestos de implementación y los archivos .dbschema.

Scripts de implementación

Puede crear scripts que se ejecuten antes o después de los scripts que crean o actualizan el destino. Puede tener un solo script anterior a la implementación y un solo script posterior a la implementación, pero puede incluir otros scripts en estos. Para obtener más información, vea Crear y modificar scripts de base de datos.

Manifiesto de implementación

Cuando compila el proyecto de base de datos, se genera un manifiesto de implementación. Este manifiesto contiene toda la información de configuración del proyecto necesaria para poder realizar la implementación sin el archivo de proyecto de base de datos (.dbproj).

Un archivo de manifiesto de implementación (.deploymanifest) es un archivo XML cuya estructura es muy similar a la de un archivo de proyecto de MSBuild. El archivo .deploymanifest se crea en la carpeta sql\Configuración de la carpeta del proyecto de base de datos, donde Configuración es la configuración de la compilación, como depuración o lanzamiento.

En el ejemplo siguiente se muestra el archivo .deploymanifest de un proyecto de base de datos de SQL Server 2008 vacío denominado Empty2008DbProj:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <TargetConnectionString>Data Source=stevenpoauth\sql2k8;Integrated Security=True;Pooling=False</TargetConnectionString>
    <TargetDatabase>Empty2008DbProj</TargetDatabase>
    <DeployToDatabase>True</DeployToDatabase>
    <DeployToScript>True</DeployToScript>
    <SourceModel>Empty2008DbProj.dbschema</SourceModel>
    <DeployScriptFileName>Empty2008DbProj.sql</DeployScriptFileName>
    <DeploymentConfigurationFile>Empty2008DbProj_Database.sqldeployment</DeploymentConfigurationFile>
  </PropertyGroup>
  <PropertyGroup>
    <SqlCommandVariablesFile>Empty2008DbProj_Database.sqlcmdvars</SqlCommandVariablesFile>
  </PropertyGroup>
  <ItemGroup>
    <DeploymentExtensionConfiguration Include="Empty2008DbProj_Script.PostDeployment.sql">
      <__PostdeploymentMetadata>
      </__PostdeploymentMetadata>
    </DeploymentExtensionConfiguration>
    <DeploymentExtensionConfiguration Include="Empty2008DbProj_Script.PreDeployment.sql">
      <__PredeploymentMetadata>
      </__PredeploymentMetadata>
    </DeploymentExtensionConfiguration>
  </ItemGroup>
  <ItemGroup>
    <DeploymentExtension Include="Microsoft.Data.Schema.Sql.Build.SqlPlanOrderModifier">
      <Assembly>Microsoft.Data.Schema.Sql</Assembly>
      <Version>10.0.0.0</Version>
      <Token>sD9ffxHVCjo=</Token>
    </DeploymentExtension>
    <DeploymentExtension Include="Microsoft.Data.Schema.Sql.Build.SqlPrePostDeploymentModifier">
      <Assembly>Microsoft.Data.Schema.Sql</Assembly>
      <Version>10.0.0.0</Version>
      <Token>sD9ffxHVCjo=</Token>
    </DeploymentExtension>
    <DeploymentExtension Include="Microsoft.Data.Schema.Sql.Refactoring.SqlRefactoringDeploymentContributor">
      <Assembly>Microsoft.Data.Schema.Sql</Assembly>
      <Version>10.0.0.0</Version>
      <Token>sD9ffxHVCjo=</Token>
    </DeploymentExtension>
  </ItemGroup>
</Project>

El archivo de manifiesto de implementación contiene uno o varios nodos PropertyGroup que definen la configuración predeterminada que se usa al implementar. El archivo de manifiesto de implementación también incluye nodos ItemGroup que contienen nodos DeploymentExtensionConfiguration y nodos Reference.

Los nodos DeploymentExtensionConfiguration definen archivos de configuración que se pasan a las extensiones de implementación al implementar. Estos archivos de configuración incluyen scripts anteriores y posteriores a la implementación, así como el registro de refactorización que se usa para preservar la intención durante la compilación.

Los nodos Reference definen los artefactos a los que se hace referencia en el proyecto y que se copian en la carpeta de salida al compilar el proyecto. Los archivos a los que se hace referencia se procesan durante la implementación para garantizar que el modelo de la base de datos vuelve a crearse correctamente.

Transacciones del script de implementación

La mayoría de los cambios de base de datos que tienen lugar en el script de implementación se producen en el interior de una transacción, de modo que los cambios se pueden revertir si se produce un error en la implementación. Sin embargo, los siguientes objetos se crean, actualizan o eliminan fuera de la transacción de implementación.

Versión de SQL Server	Objetos que están fuera de la transacción de implementación
SQL Server 2008	Pertenencia a rol de servidor Extremos Índices de texto completo Catálogos de texto completo Servidores vinculados Inicios de sesión de servidores vinculados Sesiones de eventos Especificaciones de auditoría de servidor Listas de palabras irrelevantes de texto completo
SQL Server 2005	Pertenencia a rol de servidor Extremos Índices de texto completo Catálogos de texto completo Servidores vinculados Inicios de sesión de servidores vinculados

Normalmente, estos objetos deben estar fuera de la transacción de implementación porque se mantienen a través de los procedimiento almacenados del sistema.

Consideraciones para implementar cambios en una base de datos existente

Al implementar cambios en una base de datos existente, debe tener en cuenta que algunos cambios podrían causar pérdidas de datos. Si un cambio puede hacer que los datos de una tabla se pierdan, la implementación se cancelará en caso de que la casilla Bloquear implementación incremental si puede dar lugar a pérdida de datos esté activada. De forma predeterminada, esta casilla está activada, pero puede comprobarlo en la ventana Propiedades del proyecto. Para obtener más información, vea Información general acerca de la configuración del proyecto de base de datos.

Los tipos siguientes de cambios provocarán pérdidas de datos: quitar una tabla y volver a generarla, cambiar el tamaño de una columna (de char(100) a char(50) o de nchar(100) a char(100)) o cambiar la intercalación de una columna que tiene un tipo de carácter.

Nota

Cuando usa la refactorización para cambiar el nombre de un objeto de base de datos o mover un objeto de base de datos a otro esquema, el archivo de registro de refactorización registra la acción. En el momento de la implementación, la información del archivo de registro ayuda a conservar la intención de los cambios. Por ejemplo, es posible que se pierdan datos si ha cambiado el nombre de una tabla, ya que la tabla podría quitarse y volver a crearse con el nuevo nombre. Con el archivo de registro de refactorización, el script de implementación puede cambiar el nombre de la tabla y conservar la intención y los datos.

Recuperarse de las implementaciones con errores

Puede perder datos si se produce un error en la implementación fuera de las secciones con transacciones del script de implementación. Por esta razón, debe considerar detenidamente la posibilidad de poner una base de datos compartida en modo usuario único y hacer una copia de seguridad antes de implementarla.

Archivos excluidos

Si excluye archivos del proyecto de base de datos, los objetos de base de datos definidos en esos archivos no se incluirán en el archivo .dbschema que se crea al compilar el proyecto de base de datos. Esos objetos no se implementan porque no están incluidos en el archivo .dbschema. Si todavía está trabajando en uno o más objetos pero desea implementar el trabajo que ya está completado, puede excluir archivos de la compilación de manera que solo los objetos que están listos se incluyan en el archivo .dbschema y se implementen en la base de datos de destino. Podrá incluir posteriormente los archivos, cuando estén listos para ser implementados. La implementación actualizará la base de datos con los nuevos objetos sin modificar los objetos existentes (si no se han modificado en el proyecto). Para obtener más información, vea Cómo: Excluir archivos de un proyecto de base de datos.

Importante

Puede perder los datos si excluye del proyecto de base de datos los objetos que existen en la base de datos de destino y, a continuación, implementa el proyecto. Estos objetos se eliminarán de la base de datos de destino si la casilla Generar instrucciones DROP para objetos que están en la base de datos de destino pero no en el proyecto de base de datos está seleccionada en la configuración de implementación.

Proyectos de servidor

Los proyectos de servidor contienen definiciones de los objetos de la base de datos "maestra". El nombre de la base de datos de destino de un proyecto de servidor siempre es "maestra". Puede especificar si desea comprobar el valor de cada opción del servidor al implementar el proyecto de servidor. Los valores de configuración que no se comprueban se omiten. Si el valor de una opción del servidor no coincide con el valor de una opción que desea comprobar, se produce un error en la implementación y se genera un mensaje de error.

Compilaciones de línea de comandos

Además de realizar las operaciones de compilación, implementación o limpieza desde la interfaz de usuario de Visual Studio, también puede realizar estas operaciones en el símbolo del sistema mediante MSBuild.exe. Puede especificar los destinos de Build, Deploy, Rebuild y Clean. De manera predeterminada, los procesos de generación e implementación usan las propiedades del proyecto definidas en el proyecto de base de datos (en el archivo .dbproj o .dbproj.user). Sin embargo, puede reemplazar estas propiedades desde el símbolo del sistema o desde un archivo de respuesta.

Importante
Debe cerrar Visual Studio antes de compilar desde la línea de comandos. Si realiza una compilación desde la línea de comandos mientras se ejecuta Visual Studio, es posible que no se detecten algunos errores.

También puede utilizar VSDBCMD.EXE para implementar un archivo .dbschema desde un símbolo del sistema. Puede utilizar VSDBCMD en un equipo que no tenga Visual Studio instalado. Para obtener más información, vea Cómo: Preparar una base de datos para la implementación desde un símbolo del sistema mediante VSDBCMD.EXE. Cuando se lleva a cabo la implementación en un entorno de producción, puede utilizar VSDBCMD o generar una secuencia de comandos de distribución y, a continuación, implementar manualmente ese script utilizando el Editor de Transact-SQL u otra herramienta como SQL Server Management Studio.

Sintaxis de línea de comandos

Puede compilar el proyecto de base de datos en un símbolo del sistema, como muestran los siguientes ejemplos:

• MSBuild /target:Build miNombreDeSolución.sln
  En este ejemplo la acción de compilación se lleva a cabo en una solución denominada miNombreDeSolución.sln con las propiedades de proyecto especificadas en los archivos de proyecto de la solución. Si la solución contiene varios proyectos de base de datos, se compilarán con los demás componentes de la solución. También puede generar un proyecto de base de datos concreto. La base de datos de destino Build incluye los scripts anteriores o posteriores a la implementación en el script de compilación que se crea.

• MSBuild /target:Deploy /p:UseSandboxSettings=false /p:TargetDatabase=UpdatedTargetDatabase;TargetConnectionString="Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False" miNombreDeProyecto.dbproj
  En este ejemplo se muestra cómo se implementa el proyecto de base de datos mientras se reemplaza el nombre de la base de datos de destino y la cadena de conexión.

• MSBuild /target:Deploy /p:UseSandboxSettings=false /p:DeploymentConfiguration=rutaDeImplementación\configuraciónDeImplementaciónAlternativa.deploymentconfig /p:SqlCommandVarsFile=VarPath\variablesAlternativas.sqlcmdvars /p:TargetDatabase=UpdatedTargetDatabase;TargetConnectionString="Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False" miNombreDeProyecto.dbproj
  En este ejemplo se muestra cómo se implementa el proyecto de base de datos mientras se especifica una base de datos de destino y una cadena de conexión diferentes y se reemplaza la configuración y las variables de implementación.

• MSBuild /target:Deploy /p:UseSandboxSettings=false /p:BuildScriptName=miNombreDeScript.sql /p:outdir=rutaScriptCompilación /p:TargetDatabase=baseDeDatosDestinoActualizada;TargetConnectionString="Data Source=nombreInstancia\nombreBaseDeDatos;Integrated Security=True;Pooling=False" rutaDeProyecto\miNombreDeProyecto.dbproj
  En este ejemplo se muestra cómo se implementa una base de datos desde un equipo distinto de aquel en el que se produjo la compilación. Por ejemplo, puede usar esta sintaxis si tiene un equipo de compilación central que crea un script de compilación cada noche. Debe especificar el nombre del script de compilación, la ruta de acceso donde se encuentra (outdir) el script de compilación, la base de datos de destino y la ruta de acceso y el nombre del archivo de proyecto de base de datos.

• MSBuild @dbbuild.arf miNombreDeProyecto.dbproj
  En este ejemplo se muestra cómo se usa un archivo de respuesta para proporcionar argumentos de línea de comandos. El archivo, dbbuild.arf, puede contener argumentos válidos de MSBuild, incluidos los que reemplazan las propiedades del proyecto.

• MSBuild /target:Rebuild miNombreDeProyecto.dbproj
  Este ejemplo vuelve a generar un proyecto o una solución aunque no se haya modificado desde la última vez que se generó.

• MSBuild /target:Clean miNombreDeProyecto.dbproj
  Este ejemplo muestra la forma de eliminar cualquier script de compilación existente. En la mayoría de los casos, esta acción se usa con otra acción de compilación o implementación.

Nota

Puede abreviar /target: como /t: y /property: como /p:.

Para obtener más información, vea Referencia de la línea de comandos de MSBuild.

Para obtener más información sobre los archivos de respuesta, consulte este tema en el sitio web de Microsoft: MSBuild Response Files.

Nota

Para ejecutar MSBuild.exe, debe usar el símbolo del sistema de Visual Studio o debe ejecutar el archivo por lotes vsvars32.bat. Puede encontrar este archivo por lotes en la carpeta especificada en la variable de entorno %VS80COMNTOOLS%.

Software necesario en el equipo de compilación

Visual Studio Team Foundation Server 2010 tiene compatibilidad nativa para compilar, implementar, hacer pruebas unitarias y generar datos para un proyecto de base de datos. No necesita tener instalado Visual Studio en el equipo de compilación. Si no utiliza Visual Studio Team Foundation Server 2010 en el equipo de compilación, debe instalar Visual Studio 2010 Professional, Visual Studio 2010 Premium o Visual Studio 2010 Ultimate.

Además, si desea implementar una base de datos de Team Foundation Build de otra manera que no sea como parte de una prueba unitaria de base de datos, debe realizar una instalación adicional. Debe copiar la carpeta %PROGRAMA FILES%\Microsoft Visual Studio 10.0\VSTSDB\Deploy y su contenido, incluidas las subcarpetas, de una instalación Visual Studio 2010 en el equipo de compilación. Para obtener más información, vea Cómo: Implementar cambios con Team Foundation Build y Tutorial: Definir un flujo de trabajo personalizado que implemente una base de datos a partir de Team Foundation Build.

Propiedades del proyecto

Algunas propiedades de los proyectos de base de datos y de servidor afectan al modo en que se van a compilar e implementar estos proyectos. Estas propiedades se almacenan en el archivo de proyecto y en el archivo .user, y se pueden reemplazar en el símbolo del sistema o en un archivo de respuesta. Para obtener más información, vea Cómo: Configurar valores de compilación para proyectos de base de datos y de servidor y Cómo: Configurar valores de implementación para proyectos de base de datos y de servidor.

Reemplazar las propiedades del manifiesto de implementación

Puede reemplazar las propiedades de implementación predeterminadas (como la configuración de implementación, la cadena de conexión o las variables SQLCMD) al realizar la implementación desde la línea de comandos. Puede decidir hacerlo si desea implementar un archivo .dbschema en varios entornos.

Por ejemplo, si desea implementar un esquema definido en EnterpriseDB.dbproj en entornos de desarrollo, de prueba y de producción, puede usar las siguientes líneas de comandos:

Entorno de implementación

MSBuild EnterpriseDB.dbproj /t:Deploy /p:UseSandboxSettings=false /p:DeploymentConfigurationFile=sql\debug\Development.sqldeployment /p:SqlCommandVariablesFile=sql\debug\Development.sqlcmdvars /p:TargetConnectionString="Data Source=DEV\sql2008;Integrated Security=true;Pooling=false"

Entorno de prueba

MSBuild EnterpriseDB.dbproj /t:Deploy /p:UseSandboxSettings=false /p:DeploymentConfigurationFile=sql\debug\UserTest.sqldeployment /p:SqlCommandVariablesFile=sql\debug\UserTest.sqlcmdvars /p:TargetConnectionString="Data Source=USERTEST\sql2008;Integrated Security=true;Pooling=false"

Entorno de producción

MSBuild EnterpriseDB.dbproj /t:Deploy /p:UseSandboxSettings=false /p:DeploymentConfigurationFile=sql\debug\Production.sqldeployment /p:SqlCommandVariablesFile=sql\debug\Production.sqlcmdvars /p:TargetConnectionString="Data Source=PRODUCTION\sql2008;Integrated Security=true;Pooling=false"

En cada entorno, debe proporcionar un archivo de configuración de implementación diferente, un archivo de variables SQLCMD diferente y una cadena de conexión diferente.

Vea también

Tareas

Cómo: Compilar un proyecto de base de datos para generar un archivo de esquema (.dbschema) compilado

Cómo: Implementar cambios en bases de datos nuevas o existentes

Tutorial: Crear e implementar una nueva base de datos con control de versiones

Tutorial: Implementar cambios en una base de datos existente con control de versiones

Conceptos

Compilar e implementar bases de datos en un entorno de desarrollo aislado

Generar e implementar bases de datos en un entorno de ensayo o de producción

Historial de cambios

Fecha	Historial	Motivo
Julio de 2010	Detallado el software que se requiere en el equipo de compilación para solucionar la confusión manifestada en los foros de MSDN.	Comentarios de los clientes.