Share via


Vue d'ensemble de la génération et du déploiement d'une base de données

Pour créer une base de données ou publier des mises à jour apportées à une base de données existante depuis votre projet de base de données sur un serveur de base de données, vous devez générer le projet de base de données, puis le déployer sur ce serveur.

L'étape de génération compile votre projet de base de données dans les fichiers utilisés pour le déploiement. Ces fichiers contiennent le fichier .dbschema, le fichier .deploymentmanifest et les scripts de post-déploiement et de prédéploiement. Aucune comparaison avec une base de données cible n'est effectuée lorsque vous générez le projet de base de données. Lorsque vous déployez le projet de base de données, la sortie de l'action de génération est comparée à la base de données cible, si la base de données cible existe, et les actions nécessaires pour mettre à jour la cible afin qu'elle corresponde au projet de base de données sont identifiées. Ces mises à jour sont déployées dans la base de données cible, selon vos paramètres.

Vous pouvez éventuellement générer le script de déploiement (un fichier SQL), puis le modifier avant de le déployer sur un serveur de transit ou de production, à l'aide de l'éditeur Transact-SQL ou d'un autre outil tel que SQL Server Management Studio. L'action Build propre supprime tous les artefacts de build existants, tels que les scripts, les manifestes de déploiement et les fichiers .dbschema.

Scripts de déploiement

Vous pouvez créer des scripts qui s'exécutent avant ou après les scripts qui créent ou mettent à jour la cible. Vous ne pouvez avoir qu'un seul script de prédéploiement et qu'un seul script de post-déploiement, mais vous pouvez inclure d'autres scripts depuis ces scripts. Pour plus d'informations, consultez Création et modification de scripts de base de données.

Deployment Manifest

Lorsque vous générez votre projet de base de données, un manifeste de déploiement est généré. Ce manifeste contient toutes les informations de configuration au niveau du projet dont vous avez besoin pour le déploiement, sans utiliser le fichier projet de base de données (.dbproj).

Un fichier manifeste de déploiement (.deploymanifest) est un fichier XML dont la structure est très semblable à celle d'un fichier projet MSBuild. Le fichier .deploymanifest est créé dans le dossier sql\Configuration du dossier de projet de base de données, où Configuration est la configuration de build, par exemple le débogage ou la version finale.

L'exemple suivant illustre le fichier .deploymanifest pour un projet de base de données SQL Server 2008 vide, nommé 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>

Le fichier manifeste de déploiement contient un ou plusieurs nœuds PropertyGroup qui définissent la configuration par défaut utilisée lors du déploiement. Le fichier manifeste de déploiement inclut également des nœuds ItemGroup contenant des nœuds DeploymentExtensionConfiguration et Reference.

Les nœuds DeploymentExtensionConfiguration définissent des fichiers de configuration transmis aux extensions de déploiement lors du déploiement. Ces fichiers de configuration contiennent les scripts de post-déploiement et de prédéploiement, ainsi que le journal de refactorisation utilisé pour conserver l'intention lors du déploiement.

Les nœuds Reference définissent des artefacts référencés par le projet et copiés dans le dossier de sortie, lorsque vous générez le projet. Les fichiers référencés sont traités lors du déploiement, de manière à garantir que le modèle de la base de données est recréé correctement.

Transactions contenues dans le script de déploiement

La plupart des modifications de la base de données présentes dans le script de déploiement se produisent à l'intérieur d'une transaction, de sorte qu'elles puissent être restaurées si le déploiement échoue. Toutefois, les objets suivants sont créés, mis à jour ou supprimés en dehors de la transaction de déploiement.

Version de SQL Server

Objets situés hors de la transaction de déploiement

SQL Server 2008 

Appartenance du rôle du serveur

Points de terminaison

Index en texte intégral

Catalogues de texte intégral

Serveurs liés

Noms de connexion des serveurs liés

Sessions d'événement

Spécifications de l'audit du serveur

Listes de mots vides en texte intégral

SQL Server 2005

Appartenance du rôle du serveur

Points de terminaison

Index en texte intégral

Catalogues de texte intégral

Serveurs liés

Noms de connexion des serveurs liés

Étant gérés à l'aide des procédures stockées du système, ces objets doivent en principe se situer en dehors de la transaction de déploiement.

Considérations relatives au déploiement de modifications apportées à une base de données existante

Lorsque vous déployez des modifications apportées à une base de données existante, certaines peuvent entraîner une perte de données. Si une modification est susceptible de provoquer la perte de données dans une table, le déploiement est annulé à condition que la case à cocher Bloquer le déploiement incrémentiel si une perte de données peut se produire est activée. Cette case à cocher est activée par défaut, mais vous pouvez le rechercher dans la fenêtre Propriétés de votre projet. Pour plus d'informations, consultez Vue d'ensemble des paramètres de projet de base de données.

Voici des exemples de modifications qui entraîneront la perte de données : si une table est supprimée puis recréée, si vous modifiez la taille d'une colonne (char(100) en char(50) ou nchar(100) en char(100)) ou si vous modifiez le classement d'une colonne de type caractère.

Notes

Lorsque vous utilisez la refactorisation pour renommer un objet de base de données ou déplacer un objet de base de données vers un autre schéma, le fichier journal de refactorisation enregistre cette action. Au moment du déploiement, les informations du fichier journal permettent de conserver l'intention de vos modifications. Par exemple, vous risquez de perdre des données si vous renommez une table, car la table en question serait supprimée, et une autre serait créée avec le nouveau nom. Avec le fichier journal de refactorisation, le script de déploiement peut renommer la table, en conservant votre intention et vos données.

Récupération de déploiements non réussis

Vous pouvez perdre vos données si votre déploiement échoue en dehors des sections traitées du script de déploiement. Pour cette raison, pensez à mettre en mode mono-utilisateur une base de données partagée et à la sauvegarder d'avant de la déployer.

Fichiers exclus

Si vous excluez des fichiers de votre projet de base de données, les objets de base de données qui sont définis dans ces fichiers ne seront pas inclus dans le fichier .dbschema créé lors de la création du projet de base de données. Ces objets ne sont pas déployés car ils ne sont pas inclus dans le fichier .dbschema. Si vous travaillez toujours sur un ou plusieurs objets mais souhaitez déployer un travail qui est déjà terminé, vous pouvez exclure des fichiers de la génération de manière à ce qu'uniquement les objets qui sont prêts soient inclus dans le fichier .dbschema et déployés vers la base de données cible. Vous pouvez inclure ultérieurement les fichiers lorsqu'ils sont prêts à être déployés. Le déploiement mettra alors à jour la base de données avec les nouveaux objets sans modifier les objets existants (s'ils n'ont pas été modifiés dans votre projet). Pour plus d'informations, consultez Comment : exclure des fichiers d'un projet de base de données.

Important

Vous pouvez perdre des données si vous excluez des objets du projet de base de données présents dans la base de données cible, puis déployez le projet. Ces objets sont supprimés de la base de données cible si la case à cocher Générer des instructions DROP pour les objets qui se trouvent dans la base de données cible mais pas dans le projet de base de données est activée dans la configuration du déploiement.

Projets serveur

Les projets serveur contiennent des définitions pour les objets présents dans la base de données MASTER. Le nom de la base de données cible pour un projet serveur est toujours « MASTER ». Pour chaque paramètre de serveur, vous pouvez indiquer si vous souhaitez vérifier sa valeur lorsque vous déployez le projet de serveur. Les paramètres que vous ne vérifiez pas sont ignorés. Si la valeur d'un paramètre de serveur ne correspond pas à la celle d'un paramètre que vous souhaitez vérifier, le déploiement échoue en générant un message d'erreur.

Générations à partir de la ligne de commande

Les actions de génération, de déploiement et de nettoyage sont disponibles dans l'interface utilisateur Visual Studio, mais aussi depuis l'invite de commandes accessible à l'aide de MSBuild.exe. Vous pouvez spécifier les cibles des actions de génération, déploiement, régénération et nettoyage. Par défaut, les processus de génération et de déploiement utilisent les propriétés de projet qui sont définies dans le projet de base de données (dans le fichier .dbproj ou .dbproj.user). Toutefois, vous pouvez substituer ces propriétés à l'aide d'une invite de commandes ou à partir d'un fichier réponse.

Important

Vous devez fermer Visual Studio avant d'exécuter une génération à partir de la ligne de commande. Si vous exécutez une génération à partir de la ligne de commande pendant que Visual Studio est en cours d'exécution, certaines erreurs risquent de ne pas être détectées.

Vous pouvez également utiliser VSDBCMD.EXE pour déployer un fichier .dbschema à partir d'une invite de commandes. Vous pouvez utiliser VSDBCMD sur un ordinateur sur lequel Visual Studio n'est pas installé. Pour plus d'informations, consultez Comment : préparer une base de données pour un déploiement à partir d'une invite de commandes à l'aide de VSDBCMD.EXE. Lorsque vous déployez dans un environnement de production, vous pouvez utiliser VSDBCMD ou vous pouvez générer un script de déploiement, puis manuellement déployer ce script à l'aide de l'éditeur Transact-SQL ou d'un autre outil tel que SQL Server Management Studio.

Syntaxe de ligne de commande

Vous pouvez générer le projet de base de données à l'aide d'une invite de commandes, en suivant les exemples de syntaxe ci-après :

  • MSBuild /target:Build NomMaSolution.sln
    Cet exemple exécute l'action de génération sur la solution nommée NomMaSolution.sln en utilisant les propriétés de projet qui sont spécifiées dans les fichiers projet contenus dans la solution. Si la solution contient un ou plusieurs projets de base de données, ils sont générés ensemble avec tous les autres éléments de la solution. Vous pouvez également générer un projet de base de données spécifique. La cible Build inclut des scripts de prédéploiement et de post-déploiement dans le script de compilation généré.

  • MSBuild /target:Deploy /p:UseSandboxSettings=false /p:TargetDatabase=UpdatedTargetDatabase;TargetConnectionString="Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False" NomMonProjet.dbproj
    Cet exemple montre comment déployer le projet de base de données, en substituant le nom de la base de données cible et la chaîne de connexion.

  • MSBuild /target:Deploy /p:UseSandboxSettings=false /p:DeploymentConfiguration=CheminDéploiement\AutreConfigurationDéploiement.deploymentconfig /p:SqlCommandVarsFile=CheminVar\AutresVariables.sqlcmdvars /p:TargetDatabase=UpdatedTargetDatabase;TargetConnectionString="Data Source=(local)\SQLEXPRESS;Integrated Security=True;Pooling=False" NomMonProjet.dbproj
    Cet exemple montre comment déployer le projet de base de données en définissant une autre base de données cible et une autre chaîne de connexion, et en substituant les variables de déploiement et de configuration du déploiement.

  • MSBuild /target:Deploy /p:UseSandboxSettings=false /p:BuildScriptName=NomMonScript.sql /p:outdir=CheminScriptGénération /p:TargetDatabase=BaseDeDonnéesCibleActualisée;TargetConnectionString="Data Source=NomInstance\NomBasededonnées;Integrated Security=True;Pooling=False" CheminProjet\NomMonProjet.dbproj
    Cet exemple montre comment déployer une base de données à partir d'un ordinateur autre que celui sur lequel la génération a eu lieu. Par exemple, vous pouvez utiliser cette syntaxe si vous avez un ordinateur de génération central qui crée un script de compilation chaque nuit. Vous devez spécifier le nom du script de compilation, le chemin d'accès de ce script (outdir), la base de données cible, ainsi que le chemin d'accès et le nom de fichier du projet de base de données.

  • MSBuild @dbbuild.arf NomMonProjet.dbproj
    Cet exemple montre comment utiliser un fichier réponse pour fournir des arguments de ligne de commande. Le fichier, dbbuild.arf, peut contenir tous les arguments valides pour MSBuild, notamment ceux qui substituent les propriétés de projet.

  • MSBuild /target:Rebuild NomMonProjet.dbproj
    Cet exemple régénère le projet ou la solution spécifiés, même s'ils n'ont pas changé depuis leur dernière génération.

  • MSBuild /target:Clean NomMonProjet.dbproj
    Cet exemple montre comment supprimer tout script de compilation existant. Dans la plupart des cas, vous effectueriez cette action avec une autre action de génération ou de déploiement.

Notes

Vous pouvez abréger /target: en /t: et /property: en /p:.

Pour plus d'informations, consultez Référence de la ligne de commande MSBuild.

Pour plus d'informations sur les fichiers réponse, consultez cette rubrique sur le site Web Microsoft : Fichiers réponse MSBuild.

Notes

Pour exécuter MSBuild.exe, vous devez ou utiliser l'invite de commandes de Visual Studio ou exécuter le fichier de commandes vsvars32.bat. Vous trouverez ce fichier de commandes dans le dossier qui le variable d'environnement % VS80COMNTOOLS% spécifie.

Logiciels obligatoires sur l'ordinateur de build

Visual Studio Team Foundation Server 2010 bénéficie d'une prise en charge native pour la génération, le déploiement, le test unitaire et la génération de données pour un projet de base de données. Vous n'avez pas à installer Visual Studio sur votre ordinateur de build. Si vous n'utilisez pas Visual Studio Team Foundation Server 2010 sur votre ordinateur de build, vous devez installer Visual Studio 2010 Professional, Visual Studio 2010 Premiumou Visual Studio 2010 Ultimate sur votre ordinateur de build.

De plus, si vous souhaitez déployer une base de données à partit d'un Team Foundation Build autre que dans le cadre d'un test unitaire de base de données, vous devez effectuer une installation supplémentaire. Vous devez copier le dossier %PROGRAM FILES%\Microsoft Visual Studio 10.0\VSTSDB\Deploy et son contenu, notamment les sous-dossiers, à partir d'une installation Visual Studio 2010 sur votre ordinateur de build. Pour plus d'informations, consultez Comment : déployer des modifications à l'aide de Team Foundation Build et Procédure pas à pas : définir un flux de travail personnalisé pour déployer une base de données à partir de Team Foundation Build.

Propriétés du projet

Certaines propriétés de base de données et certains projets serveur influent sur la façon dont ces projets sont générés et déployés. Ces propriétés sont stockées dans le fichier projet et le fichier .user, mais vous pouvez les substituer, depuis une invite de commandes ou dans un fichier réponse. Pour plus d'informations, consultez Comment : configurer les paramètres de génération pour des projets de base de données et serveur et Comment : configurer les paramètres de déploiement pour des projets de base de données et serveur.

Substitution des propriétés d'un manifeste de déploiement

Vous pouvez substituer les propriétés de déploiement par défaut (par exemple, configuration du déploiement, chaîne de connexion ou variables SQLCMD) lorsque vous déployez le projet à partir de la ligne de commande. Vous pouvez choisir de le faire si vous souhaitez déployer un fichier .dbschema dans plusieurs environnements.

Par exemple, pour déployer un schéma défini dans EnterpriseDB.dbproj dans les environnements de développement, de test et de production, vous pourriez utiliser les lignes de commande suivantes :

Environnement de déploiement

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"

Environnement de test

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"

Environnement de production

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"

Dans chaque environnement, vous fournissez un fichier de configuration de déploiement différent, un fichier de variables SQLCMD différent et une chaîne de connexion différente.

Voir aussi

Tâches

Comment : générer un projet de base de données pour générer un fichier de schéma compilé (.dbschema)

Comment : déployer des modifications vers des bases de données nouvelles ou existantes

Procédure pas à pas : création et déploiement d'une nouvelle base de données sous contrôle de version

Procédure pas à pas : déploiement de modifications vers une base de données sous contrôle de version existante

Concepts

Générer et déployer des bases de données dans un environnement de développement isolé

Générer et déployer des bases de données dans un environnement de pré-production ou de production

Historique des modifications

Date

Historique

Motif

Juillet 2010

Désignation plus claire des logiciels obligatoires sur l'ordinateur de build pour dissiper la confusion signalée sur les forums MSDN.

Commentaires client.