Logique conditionnelle en post-déploiement.script sql utilisant SQLCMD

Voici comment je gère le déploiement conditionnel dans le processus de post-déploiement pour déployer les données de test pour le débogage mais pas la configuration de publication.

Tout d'abord, dans l'Explorateur de solutions, ouvrez le dossier Propriétés du projet et cliquez avec le bouton droit pour ajouter un nouveau SqlCmd.fichier de variables.

Nommez le fichier Debug.sqlcmdvars.

Dans le fichier, ajoutez vos variables personnalisées, puis ajoutez une variable finale appelée $(BuildConfiguration), et définissez la valeur sur Debug.

Répétez le processus pour créer un Publier.sqlcmdvars, définir le $(BuildConfiguration) à libérer.

Maintenant, configurez vos configurations: Ouvrez la page Propriétés du projet dans L'onglet déployer. Dans la liste déroulante supérieure, définissez la configuration à déboguer. Dans la liste déroulante du bas, (variables de commande Sql), définissez le fichier sur Properties \ Debug.sqlcmdvars.

Répéter pour la Libération comme: Dans la liste déroulante supérieure, définissez la configuration à libérer. Dans la liste déroulante du bas, (variables de commande Sql), définissez le fichier sur Propriétés\Release.sqlcmdvars.

Maintenant, dans votre Script.Post-déploiement.fichier sql, vous pouvez spécifier une logique conditionnelle telle que:

IF 'Debug' = '$(BuildConfiguration)'
BEGIN
PRINT '***** Creating Test Data for Debug configuration *****';
:r .\TestData\TestData.sql
END

Dans l'Explorateur de solutions, faites un clic droit sur la solution de niveau supérieur et ouvrez Configuration Manager. Vous pouvez spécifier quelle configuration est active pour votre build. Vous pouvez également spécifier la configuration sur MSBUILD.Ligne de commande EXE.

Voilà - maintenant vos builds de développeur ont des données de test, mais pas votre version de version!

J'ai réussi à contourner le problème en utilisant le noexec méthode.

Donc, au lieu de ceci:

IF ('$(ConfigSetting)' = 'Configuration1')
 BEGIN
    print 'inserting specific configuration' 
    :r .\Configuration1\Data.sql
 END

J'ai inversé Le conditionnel et défini NOEXEC sur pour ignorer les instructions importées ainsi:

IF ('$(ConfigSetting)' <> 'Configuration1')
    SET NOEXEC ON

:r .\Configuration1\Data.sql

SET NOEXEC OFF

Assurez-vous de le désactiver si vous souhaitez exécuter des instructions ultérieures.

Comme Rob a travaillé, les instructions GO ne sont pas autorisées dans les scripts SQL liés car cela les imbriquerait dans les instructions BEGIN/END.

Cependant, j'ai une solution différente - si possible, supprimez toutes les instructions GO des scripts référencés, et mettez-en une seule après L'instruction END:

IF '$(DeployTestData)' = 'True'
BEGIN
    :r .\TestData\Data.sql
END
GO -- moved from Data.sql

Notez que j'ai également créé une nouvelle variable dans mon fichier sqlcmdvars appelé $(DeployTestData) qui me permet d'activer/désactiver le déploiement du script de test.

J'ai trouvé un hack d'un blog MSDN {[8] } qui a assez bien fonctionné. L'astuce consiste à écrire les commandes dans un fichier de script temporaire, puis à exécuter ce script à la place. Fondamentalement l'équivalent de SQL dynamique pour SQLCMD.

-- Helper newline variable
:setvar CRLF "CHAR(13) + CHAR(10)"
GO
-- Redirect output to the TempScript.sql file
:OUT $(TEMP)\TempScript.sql

IF ('$(ConfigSetting)' = 'Configuration1')
  BEGIN
    PRINT 'print ''inserting specific configuration'';' + $(CRLF)   
    PRINT ':r .\Configuration1\Data.sql' + $(CRLF)
  END
ELSE
  BEGIN
    PRINT 'print ''inserting generic data'';' + $(CRLF) 
    PRINT ':r .\GenericConfiguration\Data.sql' + $(CRLF)
  END
GO
-- Change output to stdout
:OUT stdout

-- Now execute the generated script
:r $(TEMP)\TempScript.sql
GO

Le fichier TempScript.sql contiendra alors:

print 'inserting specific configuration';   
:r .\Configuration1\Data.sql

Ou

print 'inserting generic data';
:r .\GenericConfiguration\Data.sql

En Fonction de la valeur de $(ConfigSetting) et il n'y aura pas de problèmes avec GO déclarations etc. quand il est exécuté.

J'ai été inspiré par la solution de Rob Bird. Cependant, j'utilise simplement les événements de construction pour remplacer les scripts de déploiement post basés sur la configuration de construction sélectionnée.

1. j'ai un script de post-déploiement "factice" vide.
2. j'ai configuré un événement de pré-construction pour remplacer ce fichier "factice" en fonction de la configuration de construction sélectionnée (voir l'image ci-jointe).
3. j'ai configuré un événement post-build pour replacer le fichier" factice " une fois la construction terminée (voir l'image ci-jointe). Le la raison en est que je ne veux pas générer de changements dans le contrôle des modifications après la construction.