[SSIS] Déploiement des Packages et Configurations en production


Ah… vaste et grand sujet que les déploiements. Pour SSIS, c’est surtout le manque d’infos cohérentes qui trouble. Alors reprenons tout depuis le début.

1) Rappels

Alors SSIS principalement ce sont des lots ou packages c’est à dire des fichiers XML, exécutables via un utilitaire appellé DtExec.exe (vous pouvez chercher toutes les manières possibles, au final c’est bien DtExec qui est exécuté). On cherche donc à:

  • déployer des fichiers .dtsx (xml) dans une base de données ou un dossier
  • les éxécuter en production avec DtExec.exe (ou affilié) via un ordonnanceur

La subtilité supplémentaire, existant depuis 2005, ce sont les configurations. Un ou plusieurs packages peuvent pointer sur une configuration, qui peut être de divers types (fichier, base, on y reviendra).
Cette configuration comprend les valeurs devant être modifiées entre le dev et la prod. On peut par exemple stocker les chaines de connexion des serveur de dev dans un fichier, et de prod dans un autre. Concrètement:

DTEXEC /FILE MonPackage.dtsx /CONFIGFILE Dev.dtsConfig
exécutera le lot en tapant sur les bases SQL de dev.

DTEXEC /FILE MonPackage.dtsx /CONFIGFILE Prod.dtsConfig
exécutera le lot en tapant sur les bases SQL de prod.

J’ai donc 3 étapes à suivre pour le déploiement.

1) Déployer les packages
2) Déployer leurs configurations
3) Planifier leur exécution

2) Type de déploiement, en base ou en fichier?

Le package peut être stocké en base MSDB ou en fichier. En base MSDB il est stocké sous forme de varbinary dans la table sysssispackages (sysdtspackages90 en 2005). Les dossiers de packages sont eu gérés de manière logique et arborescente dans la table syssispackagefolders (sysdtspackagefolders90 en 2005). On les consulte ensuite via le service SSIS (oui c’est à cela qu’il sert principalement!).

Alors que choisir? Personnellement je préfère MSDB, ça doit avoir un côté psychologique. J’aime bien l’idée que les choses soient dans une base de données et la gestion de sécurité et des backups m’apparait plus rassurante. En revanche je les mets volontiers en FileSystem si on me le demande et je comprends parfaitement les gens qui préfèrent « voir » les fichiers.

3) Déploiement, manifeste ou DTUtil?

Le manifeste de déploiement est lui aussi un fichier XML. De type SSISDeploymentManifest (oui c’est long) il est en fait exécuté par DTSInstall.exe pour faire croire à l’utilisateur qu’il est en présence d’un beau MSI. On le crée en activant CreateDeploymentUtility dans les propriétés du projet (cf image)


Comment marche cette joyeuseté? Et bien il importe les packages, au choix en base ou en fichier dans l’emplacement demandé. Puis il copie les éventuelles configurations dans le dossier demandé. Ca a l’air idyllique comme ça mais en fait je déconseille.

Pourquoi? Au hasard:
– On ne peut pas déployer le package dans un dossier spécifique en MSDB
– On ne peut pas déployer un lot particulier
– …

En bref je le trouve limité pour notre utilisation de développeurs, et même pas donnable à un administrateur car trop complexe. Le genre d’outils à mon sens inutile si le projet à une volumétrie élevée et n’est pas le seul utiliser le serveur. Rajoutez à ça que si vous êtes à plusieurs c’est un enfer.

Donc je conseille DtUtil, très bien expliqué ici sur MSDN. Pour le déploiement vous pouvez vous créer un petit batch un double clic dessus et vous gérez vos arborescences, vos encryptions spécifiques et… vos configurations.

NB: BIDS Helper (merci Darren Gosbell et Greg Galloway) fournit la possibilité de déployer les packages depuis BIDS en cliquant droit lot par lot, ou sur tout le projet. Ils utilisent… DtUtil.

3) L’enfer des configurations

La dispute commence déjà par le type de configurations. Il en existe 4:

  • XML configuration file
  • Environment variable
  • Registry entry
  • SQL Server

NB: ParentPackageVariable existe aussi mais sert uniquement à récupérer une valeur depuis un package parent, on ne l’abordera pas. Il en reste donc 4 principales.

Sachant qu’éditer une variable d’environnement ou une clé de registre pour trouver une chaine de connexion n’est pas des plus userfriendly les deux principales sont donc SQL et XML.

En XML on dispose d’un fichier, dtsConfig, qui contient autant de nodes (des configurations) que de valeurs à modifier dans le package. Une configuration pour une chaine de connexion apparait schématiquement comme cela:

[Configuration ValueType= »String » Path= »\Package.Connections[MonConnectionManager].Properties[ConnectionString] »]
[ConfiguredValue]
Data Source=localhost;
[/ConfiguredValue]
[/Configuration]

Pour modifier le fichier, un notepad suffit. C’est donc la configuration la plus employée.
L’alternative en SQL est la création d’une table de configuration. Cette table aura cette structure:

CREATE TABLE [dbo].[MaConfig]
(
ConfigurationFilter NVARCHAR(255) NOT NULL,
ConfiguredValue NVARCHAR(255) NULL,
PackagePath NVARCHAR(255) NOT NULL,
ConfiguredValueType NVARCHAR(20) NOT NULL
)


ConfigurationFilter est un « namespace » de configurations, pour pouvoir stocker plusieurs projets dans la même table par exemple. Les autres colonnes sont les valeurs du fichier XML.
Alors que choisir? L’un et l’autres se valent. Cela dépend du profil de la personne qui va éditer ponctuellement ces configurations.
Un DBA préfèrera une base, un utilisateur classique préfèrera sûrement un bête fichier XML car il n’a pas de client SQL sur son poste. Bref cela varie.

Mais où est le problème alors?

Le problème est que le package enregistre en Dtsx l’emplacement de sa configuration. Quand on va le déplacer, cette référence (chemin de fichier, chaîne de connexion) ne sera sûrement plus valide. Il faudrait éditer le lot au déploiement mais ça DtUtil ne permet pas de le faire. Le seul capable de faire ça est le manifeste mais il n’est pas automatisable…

Si on ne se sert pas du manifeste la première solution est d’avoir les mêmes noms de serveur, mêmes arborescences en dev et en prod. Comme nous ne vivons pas au paradis cela arrive plus que rarement.
La seconde est d’avoir Visual Studio sur le serveur et d’éditer les lots à la main… nous n’aborderons pas cette solution.

Il y a donc 3 paradigmes pour gérer le problème dans un cas réel.

a) Spécifier /CONFIGFILE à la ligne DtExec

La solution la plus simple et la plus rencontrée. Si un package ne trouve pas une des configurations stockées (path invalide ou ce genre de choses), il ne va pas échouer et prendre ses valeurs par défaut, celles de conception. (Vous verrez juste une information dans le log « Attempting to configure from file … » non suivi d’un « Success »). Ajoutez à cela que vous pouvez lui spécifier une configuration depuis la ligne de commande et vous avez la solution la plus utilisée. Mais avouez que c’est dommage de ne jamais utiliser la possibilité de pointer directement sur la bonne configuration…

[Edit du 20 Août 2009] Attention ceci dit! Si la configuration de développement est joignable (atteignable) cela ne change rien en 2005 mais en 2008 la configuration de développement est réappliquée et CONFIGFILE n’a pas d’effet.
Merci à Romuald (Coutaud) pour cette précision de taille🙂
Le lien vers le blog de Douglas Laudenschlager qui explique très bien cette différence ici.

b) Utiliser une Configuration Indirecte par Variables d’Environnement

Dans le concepteur de configuration, pour tous les types de configurations, on peut la spécifier comme indirecte. C’est à dire que l’emplacement de la configuration (chemin de fichier, chaine de connexion et table de configuration…) est stockée dans une VE figée. Jamie Thomson (qui tient un blog de référence sur SSIS) est fan, et il me l’a communiqué. Voyez son billet sur le sujet. Vous avez juste à créer sur chaque serveur une VE contenant la configuration indirecte.

Exemple vous avez un serveur ETL de prod, vous voulez modifier les bases de dev à prod? Une édition de la VE et c’est terminé. C’est très souple et beaucoup utilisé dans les gros projets. Le tester c’est l’adopter.

c) Déployer en FileSystem et référencer les configurations par des chemins relatifs

Ceci dit beaucoup d’admin n’aiment pas que l’on touche à leurs sacro-saintes VE. Ils exigent parfois que l’on s’en passe. Alors comment faire? Et bien il est possible de référencer un dtsConfig par son nom relatif. Dire que le package n’utilise pas C:\MonDossier\MaConfig.dtsConfig mais .\MaConfig.dtsConfig. Du coup un simple XCOPY et c’est terminé. La simple contrainte et de bien faire un cd sur le répertoire à l’éxécution. Greg Galloway l’explique très bien.

4) Conclusion

Beaucoup de choix dépendent de votre environnement de travail, il existe cependant quelques astuces qui peuvent rendre ce déploiement aisé, et éviter les peurs parfois justifiées de certains à ce moment crucial d’un projet.

J’espère que tout cela vous a rassuré sur la facilité de mise en oeuvre de ce genre de projets.

A bientôt!

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s