dacpac ou bacpac ? telle est la question

DACPAC

Ce fichier est un format ouvert sur le principe d'un fichier zip contenant principalement un fichier xml. Il représente les objets de la base de données, l'origine etc. Il existe un utilitaire DacUnpack.exe qui peut-être utilisé pour inspecter ces fichiers si vous êtes curieux.

 

BACPAC

Ce fichier encapsule en plus du schéma les données également. Comme le dacpac, le fichier est un format ouvert. Le contenu du schéma est stocké en xml. L'utilisation est utile pour capturer schéma et données. C'est la plupart du temps utilisé comme une archive.

 

Différence entre DACPAC et BACPAC

Les deux fichiers sont similaires. Mais chacun est adapté à des scénarios spécifiques. Notamment, le dacpac est utile pour capturer et déployer uniquement le schéma, cela inclut la création d'une nouvelle base de données ou la mise à jour d'une base de données existante. Il est possible d'inclure des données, mais ces données seront réappliqués à chaque publication, de ce fait manipuler des données n'est pas une tâche aisée. Un des usages est de l'utiliser pour mettre en place un schéma de test sur un environnement de test ou de développement, ou alors faire la migration d'un schéma d'un environnement de dev à un environnement de production.

 

Le fichier de bacpac est utile pour capturer le schéma avec ses données. C'est la plupart du temps utilisé pour l'import et l'export des bases de données, c'est similaire au backup mais cela fonctionne avec d'autres outils. Toutefois ce n'est pas compatible avec la fonctionnalité du filestream, dans ce cas vous devrez forcément utiliser les procédures de backup / restore classique.

 

REX ou retour d'expérience

Maintenant que vous connaissez la différence entre les deux, je vais décrire mon retour d'expérience dans l'utilisation de ces fichiers. Les deux sont utiles, ils se ressemblent mais pas tout à fait comme cela a été évoqué ci-dessus. Ils est nécessaire d'y faire attention car lors de vos expérimentations il est facile d'abandonner la solution ou de perdre beaucoup de temps car le sujet n'a pas été abordé par "le bon côté du prisme".

 

Dans le contexte d'une plateforme low code, nous avons une base de données qui évolue par flux métier. Cette dernière change en fonction des besoins des équipes métiers. Lors de la création d'un nouveau flux métier, il est nécessaire de créer une nouvelle base qui aura donc un schéma et des données de départ.

Cela peut-être abordé comme un "template" de base de données. Ce template est amené à évoluer en fonction des développements, mais c'est peu fréquent (quelques fois par an). Ainsi, nous avons défini un projet sql avec visual studio qui permet de définir de manière très lisible la structure et les objets de la base de données, et nous y avons joint un script pour déployer les données initiales. De ce projet, il est très simple de créer un fichier dacpac. Nous avons donc inclut cela dans un processus CI qui permet de créer ce package. Ensuite dans le processus CD, il est simple de déployer ce package sur la cible désiré (nouvel environnement ou un environnement existant). Ce mécanisme fonctionne à merveille pour la création de base de données. Ici sur ce principe, je ne reviendrai clairement pas en arrière car c'est très confortable à l'usage (Maintenance, Intégration, Facilité d'exploitation, etc.)

 

Toutefois, pour une utilisation dans le contexte de migrations cette utilisation n'est pas adaptée. Car ce choix impose que les données incluses soient rejoués à chaque "déploiement" ou migrations. C'est donc un point qui peut être délicat à l'usage lorsque l'on souhaite également gérer les données. Sauf que mettre en place un système qui n'est pas idempotent pour des bases de données est vite inutilisable selon les différentes expériences que j'ai pu avoir, et dans ce contexte la maintenance de ce type de scripts inscrit dans cette démarche n'est pas au cours du temps le plus efficace. 

 

Pour résumer, pour template une base à créer ou recréer à volonté une base : c'est le concept idéal. Pour de la migration, oui mais uniquement sans manipulation de données sinon vous allez vite devoir créer une usine à gaz pour pallier les faiblesses des scripts post ou pré déploiement.

 

Maintenant, Voyons le retour d'expérience sur le bacpac. Toujours en lien avec cette plateforme, nous avons mis en place des tests utilisateurs automatisés avec testcafé. En faisant cela, nous avons eu besoin de recréer la base avec un jeu de données précis et avec un schéma bien précis à volonté. Toutefois, à chaque développement cela nécessite de reprendre les jeux de données ou les schémas. De ce fait, lorsque j'ai mis en place le dacpac, j'ai réalisé que c'était inutilisable. La maintenance du projet SQL était trop couteuse et n'avait que peu de valeur ajoutée.

Nous avons donc opté pour une autre stratégie, l'utilisation du bacpac. Ce package s'apparente à un backup en version "light". Il est facile à générer avec l'outil sqlpackage, ce qui permet de créer un script en ligne de commande ou PowerShell à partager facilement au sein de l'équipe pour regénérer le bacpac. Et il se retrouve pousser dans le code source. Ce n'est pas élégant, car cela nécessite une synchronisation pour modifier la base de données et éviter de créer un conflit sur ces fichiers qui n'est pas gérable. Mais pour une petite équipe c'est suffisant et plutôt efficace.

D'autant que dans le processus de CD lié à l'environnement de tests automatisés nous supprimons la base de données avant puis nous la restaurons à partir de ce fichier qui est bien plus light qu'un backup sql et plus facile à manipuler car il ne nécessite pas de faire sql à proprement parler. Toutefois, il faut faire attention au fait que la base ne dois pas exister au préalable. Donc dans un scénario ou on veut supprimer et recommencer "proprement" c'est l'idéal. Cela permet vraiment de s'assurer du contexte de départ avant le lancement des tests et d'obtenir des jeux de résultats plutôt fiable.

 

Dès les premiers sessions de développement suite à la mise en place de ces tests nous avons vu les bienfaits. Après avoir gouté à cela, cela me sera difficile de revenir en arrière à cause d'autres projets qui n'ont pas cette intégration… Si ce sujet des tests vous intéresse, je peux faire un billet. Il suffit de me le signaler dans les commentaires, et j'en tiendrai compte.

 

J'espère que ce petit REX vous servira, et si vous avez des envies particulières n'hésitez pas en me les signalant dans les commentaires.


Rejoindre la conversation