Archives de catégorie : ALM

Docker : Quels scénarios pour un éditeur de logiciels ?

Docker n’est pas réservé aux startups qui développent des applications Linux basées sur des micro-services, et scalables afin de supporter des millions d’utilisateurs à travers le monde !

En effet, si vous travaillez pour un éditeur de logiciels qui a une offre logicielle datant de plusieurs années, par exemple une bonne vieille application ASP.net et donc sous Windows, vous devriez jeter un petit coup d’oeil sur la nouvelle gestion des conteneurs proposée par Windows Server 2016 afin de voir si cette nouvelle technique vous permet de simplifier vos déploiements.

Voici quelques exemples de de scénarios pour lesquels vous pourriez utiliser Docker sous Windows :

  • Gestion de vos environnements de tests, pre-prod, prod simplifiée, plus légère et plus souple qu’avec des VM
  • Blue-Green deployment et rollback de déploiement en activant/désactivant des conteneurs de manière automatisé voire automatique
  • Le saint-graal : un déploiement simplifié, et surtout uniforme entre vos clients hébergés en SaaS et vos clients On-premise. Vous souhaitez réduire de manière drastique vos temps d’installations de vos solutions (dépendances du type SQL Server, Reporting Services, et autres inclues !!), installer de la même manière vos clients hébergés sur vos serveurs et ceux qui souhaitent héberger eux-même vos applications, et gérer les mises à jour de manière uniforme.
  • Proposer une réversibilité simple pour vos clients SaaS souhaitant passer On-Premise et vice-versa

Vous êtes intéressés par une de ces possibilités ? N’hésitez pas à regarder sérieusement Docker afin de voir si cela peut répondre à vos besoins.

En savoir plus sur Docker sous Windows sur ce blog :

Quoi de neuf dans Windows Server 2016 pour les développeurs ?

L’essentiel sur Docker et les conteneurs Windows

L’essentiel de Docker : Débuter par la pratique

Meetup .net Toulouse Episode 2, DevOps avec Docker sous Windows

Visual Studio 2017 et Docker : de réelles avancées !

Visual Studio 2017 et Docker : de réelles avancées !

Les Visual Studio Tools for Docker sont disponibles depuis plusieurs mois maintenant en version Preview.

Cette extension à Visual Studio 2015 propose un scénario Dév. en permettant d’automatiquement déployer et débugger une application au sein d’un conteneur.

Il est ainsi possible d’automatiquement créer une image, de déployer l’application en cours dans cette image, de lancer un conteneur basé sur cette image, de débugguer l’application ainsi déployée, et propose une expérience ‘’Edit & Refresh” qui permet de ne pas créer une image à chaque modification de code.

Seul problème : cette extension supporte seulement les applications ASP.net Core et déployées dans des conteneurs Linux uniquement !

Très bonne nouvelle : la RC de Visual Studio 2017 propose une intégration d’une nouvelle version des Visual Studio Tools for Docker bien plus évoluée que celle disponible pour Visual Studio 2015 !

image

Au programme : Support des applications ASP.net Webforms et ASP.net MVC, et donc support des conteneurs Windows ! Le déploiement et le débogage d’applications .net “non Core” sont ainsi enfin supportés !

image

Le fichier dockerfile créé par l’extension est des plus simple :

image

Et Visual Studio affiche de manière très transparente les différentes étapes de déploiement :

image

Et une fois déployée et démarrée, Visual Studio ouvrira votre navigateur sur l’adresse IP du conteneur créé et démarré et non comme habituellement sur votre localhost :

image

Autre grosse nouveauté de cette nouvelle version, il est également possible de débugger une application déployée au sein de plusieurs conteneurs !

Si votre application est composée de différents services hébergés au sein différents conteneurs, vous n’aurez pas de problème pour débugger l’ensemble de votre solution !

Vous l’aurez donc compris, si vous souhaitez développer avec des conteneurs Windows, téléchargez Visual Studio 2017 RC pour découvrir tout cela !

Meetup .net Toulouse Episode 2, DevOps avec Docker sous Windows

 

Le 2ème meetup .net de Toulouse a eu lieu hier soir avec comme thème : Mise en place d’une approche DevOps avec Docker sous Windows.

Malgré la pluie battante (nous n’avons pas l’habitude de cela à Toulouse Clignement d'œil), une 40 aine de participants sont venus découvrir les nouvelles fonctionnalités de conteneurisation proposées par Windows Server 2016.

Nous avons ainsu pu avoir un retour d’expérience sur la mise en place d’une démarche DevOps, et rentrer plus en détail dans la technique en découvrant le déploiement d’applications .net “classique” de type ASP.net webforms  ou ASP.net MVC sous Windows, et l’intégration possible au sein de VSTS.

Cx0JxOlW8AA8a_8Photo de Stéphane Raggazi

Vous trouverez les slides de ma présentation sur slideshare :

image

Vous n’étiez pas là et vous souhaitez nous rejoindre pour les prochains meetups ?

Rien de plus simple, rejoignez-nous dans le groupe (plus de 130 membres actuellement !), et inscrivez-vous pour les meetups dont les sujets vous plaisent !

A très bientôt pour un prochain meetup !

L’essentiel de Docker : Débuter par la pratique

Nous avons précédemment vu les concepts essentiels pour comprendre la conteneurisation, le fonctionnement de docker, et les différents niveaux d’isolation proposés par Windows Server 2016.

Passons à présent à la pratique afin de voir comment effectuer un tout premier déploiement.

Installation de Docker

Docker pour Windows peut être installé sur un poste développeur à partir de Windows 10 Anniversary Update (attention, en mode d’isolation Hyper-V uniquement) ou alors sur Windows Server 2016.

Je ne vais ici pas décrire cette étape d’installation très simple mais vous rediriger vers la documentation officielle de Docker : https://docs.docker.com/docker-for-windows/

Première étape : La récupération d’une image

Microsoft propose deux images de base des deux éditions de Windows qui supporte le fait d’être contenu dans un conteneur : l’édition Server Core, et l’édition Nano Server.

Ces deux images sont disponibles sur le hub de docker qui réunit un grand nombre d’images Docker mises à disposition par différents éditeurs :

image

Dans le cas de Microsoft, vous pouvez trouver l’ensemble de ses images à cette adresse : https://hub.docker.com/u/microsoft/

Vous pouvez y trouver les fameuses images de bases pour chacun de ces deux OS :

image

Pour récupérer une de ces deux images, c’est simple, si vous êtes sur Windows 10, prêtez bien attention à switcher sur la gestion des conteneurs Windows, et non des conteneurs Linux en utilisant le menu contextuel :

image

Une fois ce changement fait, vous pouvez lancer Powershell afin de lancer la commande suivante :

docker pull microsoft/windowsservercore

pour l’image de base de l’édition concernée, et microsoft/nanoserver pour l’autre édition.

Cette commande va télécharger l’ensemble des couches de cette image qui n’ont pas déjà été téléchargé.

Une fois téléchargées, vous pouvez constater que celles-ci sont disponibles via la commande  :

docker images

image

Vous pouvez à présent créer un container basé sur ces images, et lancer ces containers, mais cela n’a que peu d’intérêt puisque vous disposez uniquement d’un Windows “nu” sans votre application.

Voyons donc à présent comment créer une image Docker contenant une application ASP.net WebForms ou MVC.

2ème étape : Création d’une image et déploiement simple d’une application ASP.net

La création d’une image Docker se fait grâce à un fichier Dockerfile. Ce fichier vous permet d’exécuter différentes commandes qui vont toutes ajouter une couche à votre image.

La première étape va donc être d’indiquer l’image de base de votre image. Et il est important ici de bien comprendre que vous avez l’embarras du choix ! Vous pouvez en effet utiliser une image d’OS nue (dans notre cas impérativement microsoft/windowsservercore qui est la seule édition à supporter le framework .net) et installer toutes les dépendances nécessaires (IIS, le framework .net, etc.) via toute une série de commande dans votre Dockerfile, ou alors utiliser une image prête à l’emploi ayant déjà votre framework et l’essentiel de vos dépendances déjà installées.

Ainsi le plus simple pour déployer une application ASP.net, est d’utiliser l’image microsoft/aspnet qui est une image qui étend l’image microsoft/windowsservercore et ayant déjà IIS et le framework .net d’installé, et ASP.net correctement configuré !

Pour récupérer cette image vous connaissez déjà la procédure (cette étape est facultative car l’image sera téléchargée lors de la construction de l’image si absente) :

docker pull microsoft/aspnet

Attardons nous à présent à la création de notre fichier Dockerfile :

# The `FROM` instruction specifies the base image. You are
# extending the `microsoft/aspnet` image.

FROM microsoft/aspnet

# Next, this Dockerfile creates a directory for your application
RUN mkdir C:\Demo

# configure the new site in IIS.
RUN powershell -NoProfile -Command \
Import-module IISAdministration; \
New-IISSite -Name « ASPNET » -PhysicalPath C:\Demo -BindingInformation « *:8000: »

# This instruction tells the container to listen on port 8000.
EXPOSE 8000

# The final instruction copies the site you published earlier into the container.
ADD . /demo

Comme vous pouvez le voir, la première instruction du Dockerfile permet d’indiquer l’image de base que l’on souhaite étendre, puis nous créons le site dans IIS qui hébergera notre application, ouvrons le port 8000 sur le conteneur, et copions l’ensemble des fichiers de notre application web, dans un dossier auparavant créé.

L’application web correspond dans notre cas à l’application par défaut créé par Visual Studio lors de la création d’un projet ASP.net Webforms, et nous pouvons inclure le fichier Dockerfile dans le dossier de cette application si nous le souhaitons.

Il suffit donc de 5 instructions dans le Dockerfile pour créer notre image avec l’application déployée.

Maintenant que nous avons notre Dockerfile, passons à la création de notre image contenant notre application déployée :

docker build –t demo .

image

les arguments –t demo permettent de définir un tag pour notre image, et le . permet de spécifier le répertoire courant comme répertoire de travail.

Et si vous listez de nouveau vos images, vous pourrez découvrir un nouveau venu :

image

Créer un conteneur pour exécuter notre application

Nous avons votre image avec notre application déployée,  exécutons maintenant notre application !

Pour cela, rien de plus simple :

docker run –name demo –d –p 8000:8000 demo

La commande permet de lancer un container en exposant le port 8000 du conteneur sur le port 8000 de l’hôte.

Vous pouvez donc accéder à présent à votre site web hébergé dans votre conteneur en accédant directement au port 8000 de votre machine hôte.

Note : Windows ne permet pas d’y accéder directement via le localhost de la machine hôte, vous pouvez donc effectuer un test de fonctionnement en accédant directement au port 8000 du conteneur. Pour cela, déterminez l’adresse IP du conteneur avec la commande suivante :

docker inspect –format= »{{.NetworkSettings.Networks.nat.IPAddress}} » demo

image

image

RDV prochainement afin de rentrer un petit plus dans le détail !

L’essentiel sur Docker et les conteneurs Windows

Le support de Docker est une des principales nouveautés de Windows Server 2016, et maintenant qu’il est possible de conteneuriser nos bonnes vieilles applications ASP.net ainsi que toutes les nouvelles sous .net Core, je vous propose un petit tour de toutes les notions essentielles pour comprendre Docker et les conteneurs Windows.

windows-10-docker

Afin de ne pas se laisser distancer par Linux sur le marché des serveurs, Microsoft a conclu un partenariat avec Docker, leader de la conteneurisation sous Linux, afin d’implémenter la même possibilité sous Windows. 2 ans de développement en commun plus tard, nous pouvons enfin profiter de ceci afin d’héberger nos applications On-Premise, en IaaS, ou via services cloud d’hébergement de conteneurs.

Les conteneurs

image

On compare souvent les conteneurs à de la virtualisation d’OS. Ainsi au lieu de virtualiser tout le matériel d’une machine (CPU, RAM, Disques, carte réseau, etc.),  un conteneur permet de faire fonctionner une application au sein d’un environnement isolé où la couche hardware utilisée correspond à celle de la machine hôte du conteneur, mais également où le kernel de la machine hôte est partagé par tous les conteneurs en cours d’exécution.

L’idée est de proposer un environnement d’exécution isolé sans payer le coût lié à l’hébergement d’une VM, et ainsi  de parvenir à héberger un nombre beaucoup plus important d’applicatifs isolés au sein d’une machine hôte.

Les containers permettent également d’avoir une grande souplesse au sujet du type de déploiement que pouvez effectué. Déployer votre application sur un serveur physique, dans une VM, ou encore sur le Cloud se fait de manière extrêmement simple puisqu’il vous suffit de déployer votre conteneur où vous le souhaitez pour avoir une application fonctionnelle, sans réinstallation logicielle, ni paramétrage.

Différents niveaux d’isolations sont proposés sous Windows Server 2016.

Les conteneurs Windows

Avec ce niveau d’isolation, chaque conteneur partage le kernel de la machine hôte. Ainsi, il est uniquement possible de faire fonctionner des conteneurs Windows au sein d’un serveur fonctionnant lui-même sous Windows, et ayant la même version de kernel.

Les conteneurs Hyper-V

Un niveau d’isolation supplémentaire est possible grâce aux conteneurs Hyper-V. Les conteneurs Hyper-V nécessitent un hyperviseur Hyper-V, Une petite VM est automatiquement créé et démarrée lorsque vous souhaitez démarrer votre conteneur.

Le kernel n’est donc plus partagée entre conteneurs, mais reste propre à chaque conteneur.

Autre avantage, vous pouvez faire fonctionner un conteneur Linux sous Windows grâce à ce niveau d’isolation.

Les images Docker

image

Les conteneurs sont basés sur des images qui contiennent :

  • Une image de l’OS souhaité. Même si le conteneur partage le même kernel que la machine hôte, on s’assure ainsi d’utiliser une image “propre” indépendante de la machine hôte, et non polluée par les différents drivers et logiciel du constructeur de votre serveur
  • Le ou les frameworks applicatifs souhaités
  • Et bien évidemment votre application !

Les images sont construites grâce à un fichier Dockerfile qui permet de définir l’image de base utilisée, et qui permet d’exécuter différentes commandes pour installer votre application et ses dépendances, et effectuer différents paramétrages.

Les couches

Cela signifie-t-il qu’en plus de mon application web (par exemple packagée via un package webdeploy) je dois en plus uploader et télécharger toute une image de Windows ?

Au lieu d’avoir une application de 50Mo, je me donc retrouve avec une image de plusieurs Go ?

Oui, et non (et même surtout non). Il est certes nécessaire de packager l’application au sein d’une image Docker qui contient l’image de l’OS et qui pèse donc au total assez lourd, mais il n’est pas pourtant nécessaire de télécharger l’intégralité de tout cela pour déployer une application.

Les images Docker reposent en effet sur un principe de couches, chaque instruction d’un fichier dockerfile créé en effet une couche au dessus des modifications déjà effectuées.

docker-layers

Lorsque l’on souhaite récupérer une image, Docker va donc récupérer celle-ci, couche par couche en commençant par l’image de base de l’OS. Et bien évidemment si la ou les couches sous-jacentes à la dernière couche de votre image sont déjà disponibles sur votre ordinateur, Docker ne les récupèrera pas de nouveau.

Ainsi si vous avez différentes images basées sur l’image microsoft/windowservercore, vous n’aurez pas à récupérer les 4Go de celle-ci à chaque fois, vous récupèrerez uniquement les couches qui ne sont pas encore disponible sur la machine hôte.

Les images de base

D’un point de vue OS, Microsoft propose deux images de base de Windows Server, une pour Windows Server Core qui pèse 4 Go en compressé, et une autre pour la nouvelle version “ultra-light” de Windows nommée Windows Nano Server. Celle-ci pèse 300Mo compressée.

Windows Nano Server correspond à un important travail de refactoring de Windows et de suppression de différents services considérés comme étant inutiles pour ce type de serveur.

Vous pouvez apprécier avec le schéma ci-dessous le résultat de cet effort de réduction :

image

25 fois plus petit qu’un Windows Server classique,  et avec une image Docker 10 fois plus petite que Windows Server Core, Windows Nano Server est l’édition indispensable pour bénéficier d’une empreinte la plus petite possible.

Ces deux images sont disponibles comme beaucoup d’autres images sur le hub de docker. Docker Hub est une bibliothèque d’images Docker, les plus grandes sociétés et éditeurs mettent à disposition leurs images Docker directement sur ce service qui permet d’héberger des images publiques mais également privées.

Il est important de noter que des images de base contenant uniquement des OS sont disponibles mais également des images contenant des frameworks applicatifs déjà installés. Il n’est donc pas nécessaire de se baser sur une image “nue”, le plus simple est de partir sur l’image correspondant le plus à votre besoin.

Le choix entre Windows Server Core et Windows Nano Server va essentiellement se faire en fonction de l’applicatif que vous souhaitez conteneuriser. Les deux éditions sont effet loin d’être iso-fonctionnelles et vous devrez faire votre choix en fonction des dépendances de votre application.

Ainsi si vous souhaitez déployer une application ASP.net WebForms ou MVC et donc basée sur le framework .net classique, vous devrez impérativement utiliser Windows Server Core car le framework .net n’est pas supporté sur Nano Server.

A contrario, si vous déployez une application ASP.net Core, Windows Nano Server, plus léger sera probablement votre choix de prédilection.

D’un point de vue Licensing

D’un point de vue Licensing tout est décrit dans le tableau ci-dessous :

image

Comme vous pouvez le voir, il est important de noter la limitation à deux conteneurs Hyper-V en édition standard alors que les conteneurs Windows sont eux, illimités.

Du côté du cloud

Côté cloud, que cela soit sur Microsoft Azure ou sur le cloud d’Amazon, il est pour le moment nécessaire de passer par des offres IaaS et donc d’avoir un host sous forme de VM pour héberger des conteneurs Windows. Les deux fournisseurs fournissent le même type d’image Windows Server 2016 with Containers qui proposent une instance de Windows Server 2016 avec les fonctionnalités de conteneurisation déjà installées et fonctionnelles.

Les services d’hébergement de conteneurs ne peuvent héberger que des conteneurs Linux chez ces deux fournisseurs de cloud.

Une preview privée est en cours sur le service Azure Container Service, et Amazon à annoncé le support des conteneurs Windows d’ici la fin de l’année 2016.

Il va donc falloir patienter un petit peu pour profiter d’un service dédié probablement moins coûteux qu’un service d’IaaS.

 

Rendez-vous pour un prochain post sur Docker afin d’aborder le déploiement d’applications d’ASP.net par la pratique !

Meetup .net Toulouse : Docker sous Windows pour les dév .net le 21 Novembre

Vous êtes développeurs ASP.net WebForms, ASP.net MVC ou ASP.net Core et vous n’avez pas encore trop regardé Docker car vous n’êtes pas intéressé par l’hébergement de vos applications sous Linux ?

Et bien rejoignez-nous pour découvrir l’intégration de Docker au sein de Windows Server 2016 (et de Windows 10 Anniversary Update) !

Que cela soit pour vos applications on-premises ou pour le cloud, nous vous présenterons les containers Windows et les containers Hyper-V, et nous aborderons les avantages de ce type de déploiement : réversibilité, blue/green deployment, etc.

image

Nous verrons comment mettre en place une démarche DevOps avec Visual Studio Team Services.

Le tout sous entièrement sous Windows, avec les technos .net que vous utilisez !

S’inscrire au meetup du 21 Novembre sur Docker sous Windows : https://www.meetup.com/fr-FR/Meetup-NET-Toulouse/events/234939602/

S’inscrire au groupe meetup .net Toulouse (nous sommes déjà presque une 100 aine !) : https://www.meetup.com/fr-FR/Meetup-NET-Toulouse/

Dépasser les limites de planification de Team Build

Team Build permet de planifier le déclenchement de Builds via un scheduler assez basique :

image

Nous avons la possibilité de planifier à intervalles régulier le déclenchement d’une build selon deux critères : le jour et l’heure.

Impossible donc de planifier depuis cette interface une build afin qu’elle soit déclenchée toutes les deux heures, toutes les demi-journées ou selon des critères plus complexes.

Afin de pouvoir déclencher une build à sa guise il est donc nécessaire d’utiliser une technique. Il est par exemple possible de lancer un build grâce au SDK de TFS, grâce aux services web, ou aux API REST, mais encore plus simplement via l’outil en ligne de commande TFSBuild.exe.

Il est donc possible de programmer vos builds comme vous le souhaitez grâce aux tâches planifiées proposées par Windows !

Exemple de commande :

« C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\TFSBuild.exe » start https://moncompte.visualstudio.com/DefaultCollection TeamProject NomDefinitionBuild /queue

La solution la plus simple pour définir la version des assemblys générées

Que cela soit pour la maintenance technique ou même pour le support fonctionnel d’un produit, il est souvent important d’être capable d’identifier la version d’une application en cours d’exécution.

Ce numéro de version est souvent défini avec la structure suivante :

Major.Minor.Build.Revision

Pour ma part, j’ai opté pour le nommage suivant :

Année.Mois.Jour.Revision

D’un point de vue technique, il existe plusieurs techniques pour définir le numéro de version des assemblys :

  • Modification Manuelle des fichiers AssemblyInfo (il n’y a donc rien d’automatique)
  • Modification des fichiers AssemblyInfo via une activité MSBuild ou une Activité Workflow Foundation, et pourquoi pas checkin de la modification pour que le source control reflète bien le numéro de version
  • Modification des fichiers AssemblyInfo via un script en pre-build

Et sur cette dernière solution que je vais m’attarder aujourd’hui car elle est très simple à mettre en oeuvre ! Vous pouvez en effet appliquer un numéro de Version à toutes les assemblies que vous compilez en moins de 10 minutes de mise en oeuvre grâce à cette méthode.

L’idée est simple, comme la plupart des systèmes de builds, TFS vous permet d’appeler des scripts batch ou powershell en action pre-build ou post-build.

Dans notre cas, nous allons exécuter un script Powershell qui va effectuer la modification des fichiers AssemblyInfo récupéré via un Get par le processus de Build, fichiers qui une fois modifiés seront compilés de manière traditionnelle.

Afin de récupérer les informations du numéro de Version à injecter, ce script va récupérer quelques variables d’environnement fournis par TFS.

1ère Etape : Mise à disposition du script d’injection de numéro de Version

J’ai indiqué que cette solution était simple et rapide à mettre en oeuvre pour une raison simple : il existe un script Powershell d’injection du numéro de Version prêt à l’emploi et fourni par des MVPs ALM à cet emplacement : https://github.com/tfsbuildextensions/CustomActivities/blob/master/Source/Scripts/ApplyVersionToAssemblies.ps1

Télécharger ce fichier, et faites un checkin de ce fichier dans un dossier sur votre source control afin qu’il soit disponible par votre serveur de build.

2ème Etape : Paramétrage de votre définition de Build

Et enfin dernière étape, rendez vous dans le paramétrage de votre définition de build, et plus précisément dans le paramétrage du process, définissez votre script en pre-build et définissez le format de numéro de version souhaité.

image

Et c’est terminé, lors de votre prochaine Build vous pourrez constater que vos assemblys possèdent bien le numéro de version souhaité.

Siren of Shame reste bloqué sur “Attempting to connect to server”

Ou comment se laisser abuser par un message d’erreur…

Siren of Shame est un logiciel de suivi de Builds qui vous permet d’être notifié du démarrage des Builds, du bon déroulement ou des échecs de Builds directement depuis la SysTray.

De plus, bonus non négligeable, il permet de se connecter à une sirène USB afin de signaler de manière visuelle et sonore, qu’il y a un problème.

J’ai décrit plus longuement ce système via ce post : http://patricelamarche.net/the-siren-of-shame/ 

image

Depuis quelques jours, je restais bloqué sur une erreur de connection, SoS m’indiquant en continu “Attempting to connect to server”.

Après désinstallation/réinstallation, session de sniff via Fiddler afin de déterminer la source du problème de connectivité, la solution a été beaucoup plus simple : Aucune des builds enregistrées n’était valable car je les avais renommés quelques jours auparavant. Au lieu d’indiquer un problème avec les définitions de Build, SoS me dirigeait donc vers une mauvaise direction.

image

Comment fonctionne le versionning de base de données ?

J’ai récemment décrit comment mettre en place de l’intégration continue afin d’intégrer automatiquement les modifications de schéma de bases de données sur des bases de données de test par exemple.

On m’a à cette occasion très justement indiqué que j’aurais pu décrire comment fonctionne le versionning de base de données.

Je vais donc décrire via ce post comment gérer dans un SCM une base de données, et je vais l’illustrer via l’utilisation de RedGate SQL Source Control. Les principes fondamentaux restent identiques pour les autres outils de la catégorie.

Cet outil peut être utilisé avec différents SCM : SVN, Git, Mercurial et bien évidemment avec TFS.

Une fois installé, vous disposez d’un nouvel onglet dans SQL Server Management Studio, celui-ci vous permet d’effectuer les principales tâches de gestion de version d’une base de données :

  • Définition du lien avec le SCM de votre choix
  • Opérations Get Latest et Commit

Première étape à réaliser donc, établir le lien entre une base de données et votre SCM :

image

A noter que ce lien étant stocké sur la machine où il est réalisé, il doit être réalisé sur chaque poste de développement.

Une fois le lien effectué, RedGate SQL Source Control va scruter en continu les modifications effectuées sur votre base de données. Il sera ainsi capable de vous indiquer les modifications effectuées lorsque vous souhaiterez faire un commit.

Le développeur peut donc effectuer les modifications qu’il souhaite sur sa base et va ensuite être capable de faire un commit dans le source control de ses modifications.

A noter qu’afin d’être capable de stocker les informations de schémas d’une base de données dans n’importe quel SCM il faut être capable de créer un ou plusieurs fichiers représentant ce schéma.

La plupart des outils de versionning de bases de données fonctionne de la même manière.

Un des objectifs de la mise en place de versionning étant la capacité de recréer from scratch une BDD propre, les outils crééent un script de création de chaque “objet” (Table, Vue, Procédure stockée, Trigger, etc.) et stockent ces fichiers dans le repository.

Ainsi le premier commit effectué depuis RedGate génère la structure suivante dans le source control :

image

Un petit tour dans le dossier de définition des tables et nous retrouvons notre table de test stockée sous forme de fichier .sql :

image

Ce fichier SQL contenant le script de création de la table avec l’ajout du champ et de la clé primaire :

image

A chaque modification de schéma, l’outil de versionning de BDD va ainsi générer le même script de création mis à jour en fonction des modifications de schéma effectuées. Ainsi un ajout de champ “nom_test” génère une nouvelle version du fichier Test.sql :

image

 

Vous retrouverez également ces scripts directement dans SQL Source Control lorsque vous effectuerez un GetLatest :

image

Bien évidemment, lorsque l’on effectue ce GetLatest, RedGate SQL Source Control ne vas pas bêtement remplacer la table en exécutant directement le script de création présent dans le source control mais il va générer un script de modification adéquat  afin de préserver les données présentes :

image

Cette génération de requête à partir du diff de deux requêtes de création est d’ailleurs la seule partie complexe de ce type de logiciels.